Being a pilot is for people who are independently wealthy (e.g. trust fund, or has a spouse willing to support them), or for people who love it so much they're willing to sacrifice everything just to have that job.
Or for people who are willing to do a stint in the military. That's the best route to becoming a commercial pilot: Join the Air Force and let Uncle Sam pay for your training and flight hours. If you're smart, go for cargo jets rather than fighters, because after an eight year hitch as a C-5 pilot (for example), you'll have lots of heavy multi-engine hours which are very expensive to buy.
I'm sincerely curious about the caliber of people they turn out. I'm perhaps a bit curmudgeonly on this; I think that to be a competent software developer you need to have a pretty thorough grounding in math and science, as well as some native talent... which seems to be far more common in people drawn to math and science. But I'm willing to be proven wrong.
What I'd really like to see is a proper study of boot camp graduates that uses good sampling methods and some decent objective measurement of skill/ability, at a few points in time (fresh grads, grads after two years in industry, grads after five years in industry, for example) and compares them to graduates from the "traditional" sources, controlling for extraneous variables. In the absence of that, I'd like to hear anecdotes, especially from people who worked with boot camp grads they thought were pretty good.
In practice, you probably wouldn't put PV on the sides unless you have PV panels that are considerably more durable than the ones we have today. Still, just the panels on top could do quite a bit. Also, trailers often end up parked outside of warehouses (there tend to be a lot more trailers than tractors, for all sorts of logistical reasons), which means that with a little planning depots could arrange to generate a large percentage of the power they use to charge the tractors.
It seems to me that what they should do is put a significant amount of battery capacity in the trailers. Then there would be no need to connect cables to parked trailers to take advantage of the PV energy they're generating. Also, it would make battery "swaps" trivial, and in many cases almost eliminate tractor charge time: semi pulls into the depot or delivery location, drops the trailer to be unloaded, picks up another -- which has a full battery, perhaps largely self-charged depending on how long it was sitting there and what the weather has been like -- and heads out.
See, you're doing it again - spinning and trying to deflect the issue.
No, I'm trying to get at the core issue, trying to get you to think about what actually matters, and why.
Invading somebody's privacy is bad in itself, period.
And now you're using loaded language to try to shape the discussion. There's no "invasion" here. You interact voluntarily with Google's services, and in exchange you get targeted ads.
To begin with, your blanket assertion that no users were harmed is contradicted by the links I posted, which show Google settling class actions brought by users who felt they were harmed.
You didn't read the links, and didn't read my response to them. That lawsuit is ridiculous, it has nothing to do with Google, it's just how the web works. Google isn't even the one getting the allegedly "private" information in the referer header. If you're not familiar with how HTTP headers in general and the referer header in particular work, here's some information: https://en.wikipedia.org/wiki/...
even if no users have been harmed yet, how can you guarantee they won't harmed in the future?
Ah, this is the first valid argument you've made. I agree that concentration of data about people poses significant potential risk. That's something we can discuss in more detail if you'd like.
the insidiousness of some of Google's actions (for example, providing "free" tools for web sites to use, but sneaking extra user tracking in them)
Again with the loaded language. There's no "sneaking" or "insidiousness" here. It's a straight-up, open transaction between web site operators and Google. The web site operators know what they're paying for what they're getting.
Even outside of the web your shopping is not private, since Google will suck in your credit card transactions data anyway and store it forever.
Google has no access to credit card transaction records, unless retailers provide them. You should read the link you posted to see the effort that Google invested to maintain privacy, to avoid getting any information about the real-world identity of the user from the transactions, and to avoid giving any information to the retailers. Also, note that the matching is done on credit card number. I assume that you don't have a credit card number in your Google account (or even have a Google account), so none of this applies to you.
I'm much more willing to ride in a fully self-driving car, assuming the maker is confident enough to accept full liability, than a semi-autonomous system whose designers think they can rely on a human driver to retake control at a moment's notice. Either the driver is in control or the computer is in control. Sharing is a recipe for disaster.
A country of more than 1 BILLION people just had their highest court rule that people's privacy is a BASIC HUMAN RIGHT; SCOTUS, I AM LOOKING AT YOU RIGHT NOW.
Why are you looking at SCOTUS? Look at Congress. Courts really aren't supposed to make the law, just apply it. The fact that SCOTUS has overreached in the past -- and sometimes done good things by overreaching -- doesn't mean it's not overreaching and a violation of the Constitutional separation of powers.
The distributed ledger is the opposite of anonymous- everyone has a full copy of all transactions.
No, the use of a single ledger (distributed or not), is orthogonal to anonymity. It is totally possible to design a single distributed ledger, blockchain-based cryptocurrency which has anonymity guarantees. Bitcoin is simply not such a design; anonymity wasn't a design goal.
What Bitcoin is, is a ledger full of pseudonymous transactions. Pseudonymity is not anonymity, though with sufficient care it is possible to ensure that a pseudonym is not tied to any real-world identity, achieving anonymity, but that's all outside the scope of what Bitcoin does.
The problem here is that people want to think by analogy, rather than understanding the actual properties of the thing. If you use the mental shorthand that "Bitcoin is a digital form of cash", you'll expect it to be anonymous, and you'll be wrong. This is similar to the way people insist on analogizing biometric authentication with password authentication and then try to figure out whether the biometric is the password part or the username part, when in fact it's neither because it has entirely different properties.
Seriously, can you cite some examples of Google leaking private information, or someone being damaged by information stolen from Google?
Easy - here's one that got settled only yesterday. And here's EPIC's take on it (PDF)
Neither of those links tells me what it's actually about. I did some searching and it appears that the complaint is that web browsers send a the Referer header to sites when users click links. So, when a user searches for terms on Google and clicks a result link, the operator of the linked site gets the Referer containing the search terms.
I understand from another post that you work for Google, so I can see why you're motivated to spin things to make the company look better.
I do work for Google, but I have no interest in spinning anything.
However, your post is quite dishonest. The GP criticizes Google as an invader of everybody's privacy. Your reply tries to re-frame the question, by making it whether Google unintentionally gives the data they gather to others.
Intentionally or unintentionally, either way. I did reframe the question, not in terms of intentionality, but in terms of harm. So let me be clearer: Can you give me any examples of users being harmed? I can give you extensive examples of users being helped.
What's the point of source material that doesn't include a list of the apps?
According to the Ars Technica article, the researchers say they didn't publish a list of the apps to avoid punishing app developers who didn't realize that the Igexin SDK could download and execute plugins which could potentially exfiltrate user data that the app had permission to see.
I'm sorry but hasn't Peapod been around forever. O let me see it was founded in 1989 and had been delivering groceries you buy online since the 90's. So please tell me how amazon is going to revolutionize grocery shopping with the internet again.
Well, for one thing Amazon will probably serve my region.
Heh. Depends where you live. Where I live bartering livestock for various goods and services is pretty common. I have a neighbor who just paid some number of cows to have a well drilled (to water his cattle).
This sort of thing is where prepaid credit cards really shine. Use them, and only load them with the amount of money needed for the purchase. Worst case, your losses would be limited to just that amount.
Even better, use a real credit card and your losses are limited to $0. Okay, technically, $50 is what the law says, but the credit card issuance industry is extremely competitive and I haven't heard of any issuer that holds their customers liable for the legally-allowed $50 in decades.
Are you saying that potentially some Oreo devices will not actually have Treble deployed?
No, it's not some devices will/won't, it's that there's more work to be done beyond O to fully achieve the broadest version of the goals. I can see how I worded that statement badly. Sorry about that.
Hmm... not completely unrelated, but still different. ActiveX controls were just components that run inside other containers -- in practice, always IE. Instant apps are full apps. You may get to them from a web link, but you can get to them lots of other ways, and they run independently of however you got to them. Also, ActiveX made all sorts of really stupid security mistakes, which is not the case with Instant apps.
Everything old is new again.
Welcome to Computer Science.
The fact that old ideas are instantiated in new systems doesn't make them useless. Not even if the old ideas didn't work well before; they can be done better.
Wi-Fi Aware (Neighborhood Aware Networking -- NAN): Android Oreo has added support for a new connectivity feature called Wi-Fi Aware, also known as Neighborhood Aware Networking (NAN), which allows apps and devices to automatically find, connect to, and share data with each other directly without any internet access point or cellular data.
This sounds really creepy. And ripe for misuse.
It doesn't happen without user approval and participation. There's a pairing step involved. Think of this as Bluetooth on steroids. It provides easy, wireless, infrastructure-less inter-device communications just like Bluetooth, but at Wifi ranges and speeds. And with Wifi power consumption, but since this should only be used for data communications that move a lot of data, that should be okay. If you draw 10X the current but complete the job in 1/100th the time, you've used 1/10th the power.
Problem is this will never make it into the Mainstream kernel.
Treble has nothing to do with the kernel.
(Disclosure/disclaimer: I'm a Google Android engineer. I own two hardware abstraction layers in Android, meaning I define their requirements, write the specifications, create the interfaces, write the client code in the Android system that uses them, write the reference implementations and work with vendors to validate their implementations. So.... I know this shit:-). On the other hand, I'm not part of the Treble team, don't participate in long-term OS-level planning, and what I'm giving you is my worm's-eye view of the goals. You can trust the stuff I tell you about how it works. Take my comments about long-term goals and ecosystem effects with a pound of salt.)
Android has a set of Hardware Abstraction Layer (HAL) interfaces that mediate between the Android system services and the kernel. Traditionally, this layer has been fuzzy. Google has always created and published the HAL interfaces in AOSP, and written client software that uses them, but device makers have been free to modify all of it. They add new HALs, modify the existing HALs and change the code above the HAL interface to use their changes. Android has long had the Compliance Test Suite (CTS) that validates that the app-visible behavior is consistent across devices, so that apps will run everywhere, but everything below that has been mutable.
Treble is about making the HAL interface solid and closing it off to modification by device makers. Treble introduced a new HAL communications infrastructure that uses a modified form of Binder (Android's long-used IPC mechanism) for communications between system components and HALs. It also adds a Vendor Test Suite (VTS) that device makers will have to pass to be able to call their devices "Android", and VTS runs directly against the HAL interface. This ensures that vendors can't change the hardware interfaces. They can still create their own HALs, but they cannot add to, subtract from, or modify the semantics of the methods of the standard HALs.
Treble also creates a hard separation between the/system and/vendor partitions, and sets a firm requirement that nothing in/vendor can depend on anything in/system. All of the HAL implementations live in/vendor, and all of Android lives in/system. The kernel isn't in either, of course, and stuff in/vendor can and does depend on kernel version-specific features... but/system does not and cannot directly depend on kernel features.
This means that once the Treble vision is fully realized (and it's going to be a process; this is a huge change which may take device makers a couple of years to get fully up to speed on), it will be possible to flash a standard AOSP build onto any device with an unlockable bootloader, with confidence that it will be able to use the HALs in/vendor correctly. In theory, the device maker should even be able to continue updating/vendor and the kernel even though the system is AOSP. Any custom HALs provided by the device maker will not be loaded or used by a vanilla AOSP build, of course.
What's even better is that this and some other changes to verified boot infrastructure move us toward a world where it will be feasible for device makers to turn updating of/system over to Google. Not that they'll have to, but especially for smaller players it will be hugely attractive to be able to push the burden of managing updates off on Google. They'll still be responsible for maintaining/vendor and the boot image (kernel), of course. There's still a lot more work to be done before that can actually happen (i.e. the work in Oreo isn't enough), and the carriers are going to have to figure out how they're going to handle their testing processes, but Treble makes it possible.
would be finding Oreo on a sub $400 phone. I am done paying $600+ for a phone that stops getting updates after 3 months.
Get a refurbished Pixel. I just got one for my son for $400. It will get Oreo, and will get P, and will get security updates until around the time Q is released. I think this is a good strategy that walks the line between budget and features: Buy last year's device and keep it for two years. For ~$200 per year this keeps you on relatively new hardware, running the latest OS and getting monthly security updates.
That's gonna be interesting watching a 96x54 pixel YouTube video while you read your report 3 words at a time.
I've been using Oreo for quite a while now, and I really like the PiP feature. Even more than YT, I like the way Google Maps works with it. Of course, my screen's resolution is 1440 x 2560, so there's plenty of room to see other stuff.
-- Note to ACs: I don't read AC replies. If you want to talk to me, log in.
Instant apps are normal Android apps, with some additional modularization and some additional security constraints. The user-observable difference is that you don't have to go through an install process. Just click a link and up pops the app. The modularization makes it possible for the app to begin functioning before it's all downloaded, and the security constraints mitigate risks created by the lower install/run effort.
Note that it's also not true that instant apps were introduced in Oreo. They first appeared in Nougat, but they were restricted to a specific set of trusted app developers, for security reasons. Based on that experience and more work on the security model, they're being opened up for any app developer -- though I believe they can still only be delivered through Google Play, because the scanning done by the Play store is a key part of the security model. They can run on M+ devices, and there's work ongoing to enable them on Lollipop as well.
Slashdot Mirror
Being a pilot is for people who are independently wealthy (e.g. trust fund, or has a spouse willing to support them), or for people who love it so much they're willing to sacrifice everything just to have that job.
Or for people who are willing to do a stint in the military. That's the best route to becoming a commercial pilot: Join the Air Force and let Uncle Sam pay for your training and flight hours. If you're smart, go for cargo jets rather than fighters, because after an eight year hitch as a C-5 pilot (for example), you'll have lots of heavy multi-engine hours which are very expensive to buy.
Has anyone worked with boot camp graduates?
I'm sincerely curious about the caliber of people they turn out. I'm perhaps a bit curmudgeonly on this; I think that to be a competent software developer you need to have a pretty thorough grounding in math and science, as well as some native talent... which seems to be far more common in people drawn to math and science. But I'm willing to be proven wrong.
What I'd really like to see is a proper study of boot camp graduates that uses good sampling methods and some decent objective measurement of skill/ability, at a few points in time (fresh grads, grads after two years in industry, grads after five years in industry, for example) and compares them to graduates from the "traditional" sources, controlling for extraneous variables. In the absence of that, I'd like to hear anecdotes, especially from people who worked with boot camp grads they thought were pretty good.
In practice, you probably wouldn't put PV on the sides unless you have PV panels that are considerably more durable than the ones we have today. Still, just the panels on top could do quite a bit. Also, trailers often end up parked outside of warehouses (there tend to be a lot more trailers than tractors, for all sorts of logistical reasons), which means that with a little planning depots could arrange to generate a large percentage of the power they use to charge the tractors.
It seems to me that what they should do is put a significant amount of battery capacity in the trailers. Then there would be no need to connect cables to parked trailers to take advantage of the PV energy they're generating. Also, it would make battery "swaps" trivial, and in many cases almost eliminate tractor charge time: semi pulls into the depot or delivery location, drops the trailer to be unloaded, picks up another -- which has a full battery, perhaps largely self-charged depending on how long it was sitting there and what the weather has been like -- and heads out.
See, you're doing it again - spinning and trying to deflect the issue.
No, I'm trying to get at the core issue, trying to get you to think about what actually matters, and why.
Invading somebody's privacy is bad in itself, period.
And now you're using loaded language to try to shape the discussion. There's no "invasion" here. You interact voluntarily with Google's services, and in exchange you get targeted ads.
To begin with, your blanket assertion that no users were harmed is contradicted by the links I posted, which show Google settling class actions brought by users who felt they were harmed.
You didn't read the links, and didn't read my response to them. That lawsuit is ridiculous, it has nothing to do with Google, it's just how the web works. Google isn't even the one getting the allegedly "private" information in the referer header. If you're not familiar with how HTTP headers in general and the referer header in particular work, here's some information: https://en.wikipedia.org/wiki/...
even if no users have been harmed yet, how can you guarantee they won't harmed in the future?
Ah, this is the first valid argument you've made. I agree that concentration of data about people poses significant potential risk. That's something we can discuss in more detail if you'd like.
the insidiousness of some of Google's actions (for example, providing "free" tools for web sites to use, but sneaking extra user tracking in them)
Again with the loaded language. There's no "sneaking" or "insidiousness" here. It's a straight-up, open transaction between web site operators and Google. The web site operators know what they're paying for what they're getting.
Even outside of the web your shopping is not private, since Google will suck in your credit card transactions data anyway and store it forever.
Google has no access to credit card transaction records, unless retailers provide them. You should read the link you posted to see the effort that Google invested to maintain privacy, to avoid getting any information about the real-world identity of the user from the transactions, and to avoid giving any information to the retailers. Also, note that the matching is done on credit card number. I assume that you don't have a credit card number in your Google account (or even have a Google account), so none of this applies to you.
I'm much more willing to ride in a fully self-driving car, assuming the maker is confident enough to accept full liability, than a semi-autonomous system whose designers think they can rely on a human driver to retake control at a moment's notice. Either the driver is in control or the computer is in control. Sharing is a recipe for disaster.
A country of more than 1 BILLION people just had their highest court rule that people's privacy is a BASIC HUMAN RIGHT; SCOTUS, I AM LOOKING AT YOU RIGHT NOW.
Why are you looking at SCOTUS? Look at Congress. Courts really aren't supposed to make the law, just apply it. The fact that SCOTUS has overreached in the past -- and sometimes done good things by overreaching -- doesn't mean it's not overreaching and a violation of the Constitutional separation of powers.
The distributed ledger is the opposite of anonymous- everyone has a full copy of all transactions.
No, the use of a single ledger (distributed or not), is orthogonal to anonymity. It is totally possible to design a single distributed ledger, blockchain-based cryptocurrency which has anonymity guarantees. Bitcoin is simply not such a design; anonymity wasn't a design goal.
What Bitcoin is, is a ledger full of pseudonymous transactions. Pseudonymity is not anonymity, though with sufficient care it is possible to ensure that a pseudonym is not tied to any real-world identity, achieving anonymity, but that's all outside the scope of what Bitcoin does.
The problem here is that people want to think by analogy, rather than understanding the actual properties of the thing. If you use the mental shorthand that "Bitcoin is a digital form of cash", you'll expect it to be anonymous, and you'll be wrong. This is similar to the way people insist on analogizing biometric authentication with password authentication and then try to figure out whether the biometric is the password part or the username part, when in fact it's neither because it has entirely different properties.
Seriously, can you cite some examples of Google leaking private information, or someone being damaged by information stolen from Google?
Easy - here's one that got settled only yesterday. And here's EPIC's take on it (PDF)
Neither of those links tells me what it's actually about. I did some searching and it appears that the complaint is that web browsers send a the Referer header to sites when users click links. So, when a user searches for terms on Google and clicks a result link, the operator of the linked site gets the Referer containing the search terms.
I understand from another post that you work for Google, so I can see why you're motivated to spin things to make the company look better.
I do work for Google, but I have no interest in spinning anything.
However, your post is quite dishonest. The GP criticizes Google as an invader of everybody's privacy. Your reply tries to re-frame the question, by making it whether Google unintentionally gives the data they gather to others.
Intentionally or unintentionally, either way. I did reframe the question, not in terms of intentionality, but in terms of harm. So let me be clearer: Can you give me any examples of users being harmed? I can give you extensive examples of users being helped.
in this case it's being done for a very positive reason, which is that it's known to reduce the transmission of AIDS
Nope, the preponderance of evidence say the transmission of AIDS is either unaffected or enhanced by circumcision.
The UN health organization disagrees with you.
I didn't claim that one example comprises "common". I said it's common in my area... and gave one example that comes to mind.
Valid point.
What's the point of source material that doesn't include a list of the apps?
According to the Ars Technica article, the researchers say they didn't publish a list of the apps to avoid punishing app developers who didn't realize that the Igexin SDK could download and execute plugins which could potentially exfiltrate user data that the app had permission to see.
I'm sorry but hasn't Peapod been around forever. O let me see it was founded in 1989 and had been delivering groceries you buy online since the 90's. So please tell me how amazon is going to revolutionize grocery shopping with the internet again.
Well, for one thing Amazon will probably serve my region.
nobody barters in livestock anymore
Heh. Depends where you live. Where I live bartering livestock for various goods and services is pretty common. I have a neighbor who just paid some number of cows to have a well drilled (to water his cattle).
Google, probably the worst company in terms of user privacy
Cite?
Seriously, can you cite some examples of Google leaking private information, or someone being damaged by information stolen from Google?
The only one I know of was that Google carelessly opted Buzz users in to sharing the names of their email contacts, in 2010.
This sort of thing is where prepaid credit cards really shine. Use them, and only load them with the amount of money needed for the purchase. Worst case, your losses would be limited to just that amount.
Even better, use a real credit card and your losses are limited to $0. Okay, technically, $50 is what the law says, but the credit card issuance industry is extremely competitive and I haven't heard of any issuer that holds their customers liable for the legally-allowed $50 in decades.
Are you saying that potentially some Oreo devices will not actually have Treble deployed?
No, it's not some devices will/won't, it's that there's more work to be done beyond O to fully achieve the broadest version of the goals. I can see how I worded that statement badly. Sorry about that.
So then it's ActiveX.
Hmm... not completely unrelated, but still different. ActiveX controls were just components that run inside other containers -- in practice, always IE. Instant apps are full apps. You may get to them from a web link, but you can get to them lots of other ways, and they run independently of however you got to them. Also, ActiveX made all sorts of really stupid security mistakes, which is not the case with Instant apps.
Everything old is new again.
Welcome to Computer Science.
The fact that old ideas are instantiated in new systems doesn't make them useless. Not even if the old ideas didn't work well before; they can be done better.
Isn't this how my phone already works when it connects to my camera.
Assuming your camera is setting up a Wifi access point and you phone is connecting to that, then yes, like that. Except a lot easier to set up.
My camera does that, too. It works, but it's a little fiddly.
Wi-Fi Aware (Neighborhood Aware Networking -- NAN): Android Oreo has added support for a new connectivity feature called Wi-Fi Aware, also known as Neighborhood Aware Networking (NAN), which allows apps and devices to automatically find, connect to, and share data with each other directly without any internet access point or cellular data.
This sounds really creepy. And ripe for misuse.
It doesn't happen without user approval and participation. There's a pairing step involved. Think of this as Bluetooth on steroids. It provides easy, wireless, infrastructure-less inter-device communications just like Bluetooth, but at Wifi ranges and speeds. And with Wifi power consumption, but since this should only be used for data communications that move a lot of data, that should be okay. If you draw 10X the current but complete the job in 1/100th the time, you've used 1/10th the power.
Problem is this will never make it into the Mainstream kernel.
Treble has nothing to do with the kernel.
(Disclosure/disclaimer: I'm a Google Android engineer. I own two hardware abstraction layers in Android, meaning I define their requirements, write the specifications, create the interfaces, write the client code in the Android system that uses them, write the reference implementations and work with vendors to validate their implementations. So.... I know this shit :-). On the other hand, I'm not part of the Treble team, don't participate in long-term OS-level planning, and what I'm giving you is my worm's-eye view of the goals. You can trust the stuff I tell you about how it works. Take my comments about long-term goals and ecosystem effects with a pound of salt.)
Android has a set of Hardware Abstraction Layer (HAL) interfaces that mediate between the Android system services and the kernel. Traditionally, this layer has been fuzzy. Google has always created and published the HAL interfaces in AOSP, and written client software that uses them, but device makers have been free to modify all of it. They add new HALs, modify the existing HALs and change the code above the HAL interface to use their changes. Android has long had the Compliance Test Suite (CTS) that validates that the app-visible behavior is consistent across devices, so that apps will run everywhere, but everything below that has been mutable.
Treble is about making the HAL interface solid and closing it off to modification by device makers. Treble introduced a new HAL communications infrastructure that uses a modified form of Binder (Android's long-used IPC mechanism) for communications between system components and HALs. It also adds a Vendor Test Suite (VTS) that device makers will have to pass to be able to call their devices "Android", and VTS runs directly against the HAL interface. This ensures that vendors can't change the hardware interfaces. They can still create their own HALs, but they cannot add to, subtract from, or modify the semantics of the methods of the standard HALs.
Treble also creates a hard separation between the /system and /vendor partitions, and sets a firm requirement that nothing in /vendor can depend on anything in /system. All of the HAL implementations live in /vendor, and all of Android lives in /system. The kernel isn't in either, of course, and stuff in /vendor can and does depend on kernel version-specific features... but /system does not and cannot directly depend on kernel features.
This means that once the Treble vision is fully realized (and it's going to be a process; this is a huge change which may take device makers a couple of years to get fully up to speed on), it will be possible to flash a standard AOSP build onto any device with an unlockable bootloader, with confidence that it will be able to use the HALs in /vendor correctly. In theory, the device maker should even be able to continue updating /vendor and the kernel even though the system is AOSP. Any custom HALs provided by the device maker will not be loaded or used by a vanilla AOSP build, of course.
What's even better is that this and some other changes to verified boot infrastructure move us toward a world where it will be feasible for device makers to turn updating of /system over to Google. Not that they'll have to, but especially for smaller players it will be hugely attractive to be able to push the burden of managing updates off on Google. They'll still be responsible for maintaining /vendor and the boot image (kernel), of course. There's still a lot more work to be done before that can actually happen (i.e. the work in Oreo isn't enough), and the carriers are going to have to figure out how they're going to handle their testing processes, but Treble makes it possible.
would be finding Oreo on a sub $400 phone. I am done paying $600+ for a phone that stops getting updates after 3 months.
Get a refurbished Pixel. I just got one for my son for $400. It will get Oreo, and will get P, and will get security updates until around the time Q is released. I think this is a good strategy that walks the line between budget and features: Buy last year's device and keep it for two years. For ~$200 per year this keeps you on relatively new hardware, running the latest OS and getting monthly security updates.
That's gonna be interesting watching a 96x54 pixel YouTube video while you read your report 3 words at a time.
I've been using Oreo for quite a while now, and I really like the PiP feature. Even more than YT, I like the way Google Maps works with it. Of course, my screen's resolution is 1440 x 2560, so there's plenty of room to see other stuff.
--
Note to ACs: I don't read AC replies. If you want to talk to me, log in.
It runs in the browser/webkit.
No, it doesn't.
Instant apps are normal Android apps, with some additional modularization and some additional security constraints. The user-observable difference is that you don't have to go through an install process. Just click a link and up pops the app. The modularization makes it possible for the app to begin functioning before it's all downloaded, and the security constraints mitigate risks created by the lower install/run effort.
Note that it's also not true that instant apps were introduced in Oreo. They first appeared in Nougat, but they were restricted to a specific set of trusted app developers, for security reasons. Based on that experience and more work on the security model, they're being opened up for any app developer -- though I believe they can still only be delivered through Google Play, because the scanning done by the Play store is a key part of the security model. They can run on M+ devices, and there's work ongoing to enable them on Lollipop as well.
https://developer.android.com/topic/instant-apps/index.html
--
Note to ACs: I don't read AC replies. If you want to talk to me, log in.
I'd be happy with a feature where the phone makes a phone call and both parties actually sound intelligible. High quality, even!
Does your phone and carrier support HD voice? Mine does, and it's a significant improvement, when I call people whose phone/carrier also support it.