If this were actually about providing access to the poor Angolans, rather than basically being facebook's marketing effort with wikipedia thrown in to look altruistic, the easy solution would just be to subsidize cell data by quantity, rather than confronting the basically hopeless task of attempting to classify by type against users with a strong incentive to disguise one type of activity as another.
If you have X megabytes or gigabytes to play with, rather than 'unlimited wikipedia', you no longer have the incentive to squeeze random stuff into assorted hidden crevices of wikipedia; just the much more reasonable set of incentives provided by the fact that some things are more data intensive than others.
This is another classic example of why, although it is very tempting, subsidizing things by type, rather than by quantity, usually doesn't end well.
People providing subsidies really like attaching strings to them, it feels much better than just handing over cash(whether, as in this case, it's because the subsidy is mostly there to support facebook's business interests with wikipedia thrown in to make the process look vaguely altruistic; or because Senator Somebody heard that WIC was being used to buy junk food and doesn't approve); but this means that the people receiving the subsidy have a strong incentive to shoehorn whatever it is that actually want or need into a form allowed by the subsidy, even if doing so isn't very efficient.
If this zero-rating stuff were actually about the interests of the users, rather than basically being facebook's pet project, the obvious solution would be to drop the site-by-site classification nonsense and just subsidize the first x GBs of data use and let the user decide what to do with it.
The one nice thing about the 'cashless economy' is that(unlike a great many awful ideas) both its backers and its detractors actually largely agree on the reasons for why it will be awesome/awful; they just phrase them slightly differently. More commonly you have to deal with one or both sides fundamentally disagreeing on what the effects of the plan will be, which requires you to sort out the fact of the matter, rather than just disagreeing on whether the effects are good or not.
The enthusiasts say "Hooray, saving the un-banked from their precarious existence and enabling access to financial services!" The detractors say "feeding the last holdouts and previously inaccessible markets into the maw of the financial service industry." They aren't actually disagreeing. The enthusiasts talk about the glorious transparency and ability to crack down on bribery, embezzlement, slush funds, and various similar things. The pessimists note the relentless and inescapable scrutiny and the ability to crack down on basically any flavor of transaction you don't much approve of. Again, not really a dispute over what the plan will do. Optimists extol the ease and convenience of frictionless electronic transacting without tedious stacks of paper. The less sanguine note that that's pretty much exactly what team Behavioral Econ says is the recipe to maximize impulse spending and consumer debt accumulation.
I'm not entirely sure if it's enough of a nerd site that anything approaching levity is out of the question on this topic; or whether it is no longer enough of a nerd site for people to remember that Grove made the saying "Only the paranoid survive" famous.
Isn't being an Apple "partner" at least as dangerous as being a Windows platform developer whose product strikes Microsoft as a nice addition to their lineup?
Apple is atypically enthusiastic about doing things in house; and even the stuff they have no interest in doing internally, they really don't like being beholden to anyone. Would they like Nintendo titles for their app store? Sure. Would they leave Nintendo to wallow in the morass of underpromoted app-store-slurry if they thought Nintendo was getting too optimistic about its leverage in the relationship? Oh yeah.
So does this just amount to an announcement that CrossOver has been made to work with bionic as well as the usual gnu libc, or is there something else involved?
I'm having trouble locating the exact requirements the device had to fulfill to satisfy the SME PED program; but depending on what levels of physical tamper resistance and software quality assurance were involved, $4,750/unit for a fairly low volume device might actually be a pretty decent price.
Mainstream winCE devices were pretty much extinct, or in the later stages of twitching and gasping, by 2009; but as a point of comparison you could find yourself spending ~$500 for a high-end Pocket PC device back in the 2005ish period, sometimes without any sort of cellular connectivity and obviously without the SCIF mode and keyfill ports and stuff. Prices for equivalent hardware had certainly fallen in the mass market by 2009; but I'm guessing that this thing's development time left it with hardware much more akin to that of older models than to that of whatever cellphones were hot off the presses in 2009.
If the requirements were more about knowing how to land contracts and tick feature checkboxes, then the price is on the high side. If the "trusted" label on various parts of the device, and whatever modifications to stock WinCE were necessary to get safe coexistence of the high and low security sides of the device, imply a substantial amount of very exacting software development; then I'm actually more surprised that they cost that little.
Anyone know how these are supposed to stack up in EAL/CC/FIPS140-2 terms or any other measures that would be more helpful in drawing comparisons than membership in a group that only one other device was ever part of?
Chumby was one of Bunnie Huang's projects(of xbox hacking fame back in the day); and it was notably OSS-y and user accessible by the standards of consumer electronics. Best Buy briefly had their own chumby-based product("Insignia Infocast 8") and I picked one up a while back when they were on sale. The features weren't on by default; but you could poke a couple of menu items to start up SSH right out of the box; and the device used a microSD card for firmware, making experimentation with custom builds low-risk and fairly painless.
[i]However[/i] Sony's version, unlike all the other chumby variants, was markedly more closed because Sony included some video playback features that they didn't want people getting their filthy hands on. I think that, for that reason, their hardware was among the nicest/fastest of any of the chumby devices; but also the most hostile to user tinkering. That makes Sony terminating their support likely to sting even harder.
That said, I'm a bit surprised that the hammer didn't fall sooner: the chumby was a neat device; but it came out not too long before Android started showing up all over the place and at increasingly low price points, at which point the similar-role-but-vastly-tinier-ecosystem chumby really had no hope of survival or niche to occupy. I still use mine, it has served me well; but if I were buying today the combination of ubiquitous and cheap Android-things and the post-rPi crazy cheap dev boards would certainly rule it out. Dick move on Sony's part(non-Sony chumby units are still working fine); but not a total surprise.
Interesting, thanks. This would probably blow the BoM in a lot of cases; but now I'm curious to try a 'test point extender' to see if I could preserve the test points and us a conformal coating. I'm thinking a gold-plated copper cylinder, same diameter as the test point and slightly taller than the expected thickness of the conformal coating; possibly with a textured indentation located partway up the cylinder(similar to the indentation used in a pulley or belt drive to keep the rope/belt from leaving the center of the cylinder) to give the conformal coating plenty of room to form a good seal with the extender and keep it from being an area of infiltration; and an expendable plug on top of the extender to make re exposing it after applying the conformal coating easy. (I apologize if my explanation is unclear, Slashdot doesn't provide a back-of-the-envelope to sketch things on, which would make this a lot easier)
I suspect that you could get some wiggle room from the 'varying with pressure' aspect(eg. if you can find a working fluid that vaporizes at relatively low temperature, when at modest pressure, so that the system works for merely warm food; but its own vapor rapidly raises the pressure, and the boiling point, so that distinct evaporation and condensation zones still exist, rather than just a bunch of probably-insulative pockets of hot vapor, at higher temperatures); but yes, a heatpipe-type arrangement would probably have to be targeted at at least a rough temperature band.
Given the success and availability of phase-change-material based thermal storage(usually modified paraffins or salt hydrates for relatively low temperature applications), I suspect that it'd be hard to beat those for plates, pots, etc. designed to keep food warm for extended periods(one area that these actually do show up a lot is in pizza delivery bags, as they don't require charging or anything unlike active heaters; but outperform mere insulated bags considerably in terms of keeping the pizza nice and warm during delivery); but a heatpipe-style arrangement might be more compelling in frying applications where the ability to smooth out any hot or cold spots quickly as the user moves or flips the object being fried would be an advantage. The added cost would likely make it a niche product in any case, so you'd have to hope that people who buy expensive niche kitchenware are willing to have multiple special-purpose devices.
I realize that the law works differently for little people and all(though it's not as though Team Media have been shy about insisting that basically everyone who in some way facilitates internet use should have a responsibility to protect their precious 'content' for them, from ISPs to search engines); but I'm a trifle baffled by how it could even be a serious question whether somebody operating an internet-connected wifi AP is responsible for the actions of the users of that AP. More or less everyone accepts that ISPs, telcos, and the like can't possibly be held responsible for every last dumb or criminal thing that their customers do or we'd have to shut down basically everything; and isn't a public AP just a particularly small last-mile ISP with even less practical ability to keep tabs on its customers(since it may not have much info on them, compared to ISPs that know where you live or have your billing information; and is atypically likely to be operated as an amenity by technically unsophisticated proprietors of a coffee shop/hotel/etc. rather than by an ISP that may have clueless tier 1 reps; but can't stay in business without at least some hardcore NOC types in the background).
Yes, operating a hotspot for the benefit of your business off the cheapest 'home' internet plan may be a breach of your ISP's ToS; but that's a totally separate issue, to be taken up between you and them if they care so much, and not relevant to your culpability for what 3rd parties do on your hotspot.
Very interesting, thanks, I always appreciate stumbling across someone who actually knows what I'm speculating about.
Out of curiosity: since you doing arduous troubleshooting of a failed part is presumably not the ideal outcome, I imagine that the answer is 'no'; but are the various conformal coatings and adhesives/potting materials helpful against moisture? Less so than I imagine? Would be very helpful; but cause their own problems with thermal dissipation or wonky capacitance changes?
What I find rather unexpected about this paper's findings is that higher humidity caused more controller failure, rather than causing more mechanical issues. Yes, the mechanical bits are inside the enclosure with a filter to keep out dust; but they aren't fully sealed(unless new enough to be the helium filled ones) and water vapor will go right through a dust filter. The driver board is outside; but a bunch of solid-state components on a circuit board usually behave pretty well unless they are literally dripping or showing signs of corrosion. Am I just overestimating the reliability of PCBs?
I'm a bit surprised that I've never seen some sort of variation on the heatpipe concept(presumably with a different working fluid) in some sort of fancy cookware, now that you mention it. Plenty of designs that include a copper layer for its thermal properties, or use thicker-than-mechanically-necessary iron for the thermal mass; but PC cooling moved to heatpipes because those offer substantially better conductivity than even fairly alarming chunks of solid copper. Just too costly to be worth the marginal gains?
Yeah. If scope creep were actually a measurement problem it'd be solved in a dozen different ways, probably more elegant than mine, by now. Unfortunately, it's not primarily a measurement problem.
As the good Dr. Feynman noted: "The first principle is that you must not fool yourself – and you are the easiest person to fool."
That's the trouble with 'intuitive' solutions. Not only are they unreliable; unlike other lousy sources of data, they are unreliable and emotionally compelling.
Out of curiosity, what aspects of Tegra are expected to be mainlined/have Nvidia play nice on? If their PC stuff is anything to go by, I'd assume that Nvidia will just provide a shim for the GPU and CUDA stuff; but it's hard to imagine what benefit they would derive from being uncooperative about the basic 'ARM cores and assorted non-GPU peripherals' stuff, since keeping those stuck in some awful BSP is a pain for their customers and those components aren't nearly as interesting and distinguishing as the Nvidia-specific GPU stuff.
One can obviously debate the value of this; but my impression is that, while in an ideal world they'd like to be able to support more hardware, when it comes down to it the Linux project really isn't interested in just providing a cheap OS for people to put on top of their giant heap of binary blobs. They certainly aren't as hardline as the FSF; but even the 'engineer-pragmatist' types see binary blobs as an impediment to their work(that's why the kernel taint flag exists: if your system crashes, you have a potentially interesting bug report; but if it was 30% Nvidia blackbox by weight at the time, they don't want to waste their time shooting in the dark).
Linux does support(and, at least outside of the smaller embedded systems, is typically configured to use) kernel modules that are loaded as needed for driver support and the like; but those modules are treated as part of 'the kernel' when talking about kernel development(for devices that have in-tree drivers, there is nothing stopping you from using modules from other sources, if available).
As with Windows drivers, a Linux system will typically only load kernel modules based on what is actually present on the system it is running on(so an Intel GPU-based system wouldn't ever load AMD power management stuff, though a Linux distribution might include those modules on the disk somewhere in order to support as many different hardware configurations as possible). If the module is developed by the kernel team, in sync with the kernel, it is still treated as part of 'the X.Y kernel', even though actually using it is optional.
It isn't quite as ghastly as it used to be(if more because of increased integration of peripherals than because of any philosophical shift); but it still seems to be the case that the PC OEMs will only assure specific components if you purchase from their 'business' lines, since IT departments like image stability; while the consumer offerings will only offer 'something gigabit' or 'something 802.11ac'(though in practice you often get lucky, since chipset-churn can eat up much of the savings provided by perpetually hunting the cheapest chipsets, so you'll often see a reasonably long period of identical hardware between the silent revisions).
It's worth noting, in terms of 'difficulty of dealing with undocumented binary blobs and ACPI in general', that Microsoft's own designed, developed, and blessed Surface Pro and Surface Book products have been dogged by power management issues; and that's with hardware hand picked by Microsoft, an OS built by Microsoft, and drivers and firmware either written by Microsoft or written for Microsoft by vendors who do most of their driver development work to support Microsoft OSes.
Obviously "but look at the other guy!" isn't an argument against the fact that Linux on laptops indeed has issues; it just provides some perspective on what a ghastly mess PC power management is. If Microsoft's own "Our OEMs are making us look bad, so here's a kick in the ass and a reminder of what kind of products we want in the PC space" product can't power-manage properly, that doesn't imply positive things about the difficulty for the Linux kernel team of getting power management to work correctly on some random vendor's apathetic attempt to shove a laptop out the door for as little money as possible.
I suspect that some of them are largely blind to this stuff: it's not as though hackers and FOSS idealists don't exist; but to the degree that people are hired by interested parties to work on the kernel, it is substantially about servers/HPC and assorted embedded systems. In these cases, the hardware you are working on supporting may or may not even include ACPI(on the embedded side) and won't be miserable consumer crap subjected to some of the hairier suspend/resume/unexpected user behavior stuff(on the server/HPC side); and the hardware you are doing your work on can be basically whatever you like, since SSH-ing in to a remote system or running a bunch of VMs, or using whatever debug interface some ARM dev board provides don't tend to require running Linux even if you are working on making Linux run.
Even those who aren't blind(Linus certainly swears enthusiastically when ACPI comes up) I'd imagine that there is no terribly good solution to a problem that can come up in myriad different ways depending on the device, vendor, BIOS/UEFI version, peripherals, etc. Some sort of support for "Don't try to do ACPI correctly, just apply the ghastly-awful-hacks-I've-constructed-for-this-device" is really about all you could do at the kernel development level without committing to the Sisyphean task of trying to hunt down and reverse engineer as many dysfunctional ACPI implementations as you can find and include one-off quirks support for each one of them.
I'd be the first to agree that Linux on laptops, especially if you try the new or exotic ones, isn't so hot; but it's not clear how the kernel developers are well placed to do something about it.
Slashdot Mirror
If this were actually about providing access to the poor Angolans, rather than basically being facebook's marketing effort with wikipedia thrown in to look altruistic, the easy solution would just be to subsidize cell data by quantity, rather than confronting the basically hopeless task of attempting to classify by type against users with a strong incentive to disguise one type of activity as another.
If you have X megabytes or gigabytes to play with, rather than 'unlimited wikipedia', you no longer have the incentive to squeeze random stuff into assorted hidden crevices of wikipedia; just the much more reasonable set of incentives provided by the fact that some things are more data intensive than others.
This is another classic example of why, although it is very tempting, subsidizing things by type, rather than by quantity, usually doesn't end well.
People providing subsidies really like attaching strings to them, it feels much better than just handing over cash(whether, as in this case, it's because the subsidy is mostly there to support facebook's business interests with wikipedia thrown in to make the process look vaguely altruistic; or because Senator Somebody heard that WIC was being used to buy junk food and doesn't approve); but this means that the people receiving the subsidy have a strong incentive to shoehorn whatever it is that actually want or need into a form allowed by the subsidy, even if doing so isn't very efficient.
If this zero-rating stuff were actually about the interests of the users, rather than basically being facebook's pet project, the obvious solution would be to drop the site-by-site classification nonsense and just subsidize the first x GBs of data use and let the user decide what to do with it.
The one nice thing about the 'cashless economy' is that(unlike a great many awful ideas) both its backers and its detractors actually largely agree on the reasons for why it will be awesome/awful; they just phrase them slightly differently. More commonly you have to deal with one or both sides fundamentally disagreeing on what the effects of the plan will be, which requires you to sort out the fact of the matter, rather than just disagreeing on whether the effects are good or not.
The enthusiasts say "Hooray, saving the un-banked from their precarious existence and enabling access to financial services!" The detractors say "feeding the last holdouts and previously inaccessible markets into the maw of the financial service industry." They aren't actually disagreeing. The enthusiasts talk about the glorious transparency and ability to crack down on bribery, embezzlement, slush funds, and various similar things. The pessimists note the relentless and inescapable scrutiny and the ability to crack down on basically any flavor of transaction you don't much approve of. Again, not really a dispute over what the plan will do. Optimists extol the ease and convenience of frictionless electronic transacting without tedious stacks of paper. The less sanguine note that that's pretty much exactly what team Behavioral Econ says is the recipe to maximize impulse spending and consumer debt accumulation.
I'm not entirely sure if it's enough of a nerd site that anything approaching levity is out of the question on this topic; or whether it is no longer enough of a nerd site for people to remember that Grove made the saying "Only the paranoid survive" famous.
It could also be that I'm not very good at jokes.
Isn't being an Apple "partner" at least as dangerous as being a Windows platform developer whose product strikes Microsoft as a nice addition to their lineup?
Apple is atypically enthusiastic about doing things in house; and even the stuff they have no interest in doing internally, they really don't like being beholden to anyone. Would they like Nintendo titles for their app store? Sure. Would they leave Nintendo to wallow in the morass of underpromoted app-store-slurry if they thought Nintendo was getting too optimistic about its leverage in the relationship? Oh yeah.
Do they still send fingerprints of everything you display on them to the vendor for some sort of undesirable purpose, with an implementation lousy enough to be a network hazard?
So does this just amount to an announcement that CrossOver has been made to work with bionic as well as the usual gnu libc, or is there something else involved?
I take it that his paranoia finally ran out?
I'm having trouble locating the exact requirements the device had to fulfill to satisfy the SME PED program; but depending on what levels of physical tamper resistance and software quality assurance were involved, $4,750/unit for a fairly low volume device might actually be a pretty decent price.
Mainstream winCE devices were pretty much extinct, or in the later stages of twitching and gasping, by 2009; but as a point of comparison you could find yourself spending ~$500 for a high-end Pocket PC device back in the 2005ish period, sometimes without any sort of cellular connectivity and obviously without the SCIF mode and keyfill ports and stuff. Prices for equivalent hardware had certainly fallen in the mass market by 2009; but I'm guessing that this thing's development time left it with hardware much more akin to that of older models than to that of whatever cellphones were hot off the presses in 2009.
If the requirements were more about knowing how to land contracts and tick feature checkboxes, then the price is on the high side. If the "trusted" label on various parts of the device, and whatever modifications to stock WinCE were necessary to get safe coexistence of the high and low security sides of the device, imply a substantial amount of very exacting software development; then I'm actually more surprised that they cost that little.
Anyone know how these are supposed to stack up in EAL/CC/FIPS140-2 terms or any other measures that would be more helpful in drawing comparisons than membership in a group that only one other device was ever part of?
WOL?
Chumby was one of Bunnie Huang's projects(of xbox hacking fame back in the day); and it was notably OSS-y and user accessible by the standards of consumer electronics. Best Buy briefly had their own chumby-based product("Insignia Infocast 8") and I picked one up a while back when they were on sale. The features weren't on by default; but you could poke a couple of menu items to start up SSH right out of the box; and the device used a microSD card for firmware, making experimentation with custom builds low-risk and fairly painless.
[i]However[/i] Sony's version, unlike all the other chumby variants, was markedly more closed because Sony included some video playback features that they didn't want people getting their filthy hands on. I think that, for that reason, their hardware was among the nicest/fastest of any of the chumby devices; but also the most hostile to user tinkering. That makes Sony terminating their support likely to sting even harder.
That said, I'm a bit surprised that the hammer didn't fall sooner: the chumby was a neat device; but it came out not too long before Android started showing up all over the place and at increasingly low price points, at which point the similar-role-but-vastly-tinier-ecosystem chumby really had no hope of survival or niche to occupy. I still use mine, it has served me well; but if I were buying today the combination of ubiquitous and cheap Android-things and the post-rPi crazy cheap dev boards would certainly rule it out. Dick move on Sony's part(non-Sony chumby units are still working fine); but not a total surprise.
Interesting, thanks. This would probably blow the BoM in a lot of cases; but now I'm curious to try a 'test point extender' to see if I could preserve the test points and us a conformal coating. I'm thinking a gold-plated copper cylinder, same diameter as the test point and slightly taller than the expected thickness of the conformal coating; possibly with a textured indentation located partway up the cylinder(similar to the indentation used in a pulley or belt drive to keep the rope/belt from leaving the center of the cylinder) to give the conformal coating plenty of room to form a good seal with the extender and keep it from being an area of infiltration; and an expendable plug on top of the extender to make re exposing it after applying the conformal coating easy. (I apologize if my explanation is unclear, Slashdot doesn't provide a back-of-the-envelope to sketch things on, which would make this a lot easier)
I suspect that you could get some wiggle room from the 'varying with pressure' aspect(eg. if you can find a working fluid that vaporizes at relatively low temperature, when at modest pressure, so that the system works for merely warm food; but its own vapor rapidly raises the pressure, and the boiling point, so that distinct evaporation and condensation zones still exist, rather than just a bunch of probably-insulative pockets of hot vapor, at higher temperatures); but yes, a heatpipe-type arrangement would probably have to be targeted at at least a rough temperature band.
Given the success and availability of phase-change-material based thermal storage(usually modified paraffins or salt hydrates for relatively low temperature applications), I suspect that it'd be hard to beat those for plates, pots, etc. designed to keep food warm for extended periods(one area that these actually do show up a lot is in pizza delivery bags, as they don't require charging or anything unlike active heaters; but outperform mere insulated bags considerably in terms of keeping the pizza nice and warm during delivery); but a heatpipe-style arrangement might be more compelling in frying applications where the ability to smooth out any hot or cold spots quickly as the user moves or flips the object being fried would be an advantage. The added cost would likely make it a niche product in any case, so you'd have to hope that people who buy expensive niche kitchenware are willing to have multiple special-purpose devices.
I realize that the law works differently for little people and all(though it's not as though Team Media have been shy about insisting that basically everyone who in some way facilitates internet use should have a responsibility to protect their precious 'content' for them, from ISPs to search engines); but I'm a trifle baffled by how it could even be a serious question whether somebody operating an internet-connected wifi AP is responsible for the actions of the users of that AP. More or less everyone accepts that ISPs, telcos, and the like can't possibly be held responsible for every last dumb or criminal thing that their customers do or we'd have to shut down basically everything; and isn't a public AP just a particularly small last-mile ISP with even less practical ability to keep tabs on its customers(since it may not have much info on them, compared to ISPs that know where you live or have your billing information; and is atypically likely to be operated as an amenity by technically unsophisticated proprietors of a coffee shop/hotel/etc. rather than by an ISP that may have clueless tier 1 reps; but can't stay in business without at least some hardcore NOC types in the background).
Yes, operating a hotspot for the benefit of your business off the cheapest 'home' internet plan may be a breach of your ISP's ToS; but that's a totally separate issue, to be taken up between you and them if they care so much, and not relevant to your culpability for what 3rd parties do on your hotspot.
Very interesting, thanks, I always appreciate stumbling across someone who actually knows what I'm speculating about.
Out of curiosity: since you doing arduous troubleshooting of a failed part is presumably not the ideal outcome, I imagine that the answer is 'no'; but are the various conformal coatings and adhesives/potting materials helpful against moisture? Less so than I imagine? Would be very helpful; but cause their own problems with thermal dissipation or wonky capacitance changes?
What I find rather unexpected about this paper's findings is that higher humidity caused more controller failure, rather than causing more mechanical issues. Yes, the mechanical bits are inside the enclosure with a filter to keep out dust; but they aren't fully sealed(unless new enough to be the helium filled ones) and water vapor will go right through a dust filter. The driver board is outside; but a bunch of solid-state components on a circuit board usually behave pretty well unless they are literally dripping or showing signs of corrosion. Am I just overestimating the reliability of PCBs?
I'm a bit surprised that I've never seen some sort of variation on the heatpipe concept(presumably with a different working fluid) in some sort of fancy cookware, now that you mention it. Plenty of designs that include a copper layer for its thermal properties, or use thicker-than-mechanically-necessary iron for the thermal mass; but PC cooling moved to heatpipes because those offer substantially better conductivity than even fairly alarming chunks of solid copper. Just too costly to be worth the marginal gains?
Yeah. If scope creep were actually a measurement problem it'd be solved in a dozen different ways, probably more elegant than mine, by now. Unfortunately, it's not primarily a measurement problem.
As the good Dr. Feynman noted: "The first principle is that you must not fool yourself – and you are the easiest person to fool."
That's the trouble with 'intuitive' solutions. Not only are they unreliable; unlike other lousy sources of data, they are unreliable and emotionally compelling.
Out of curiosity, what aspects of Tegra are expected to be mainlined/have Nvidia play nice on? If their PC stuff is anything to go by, I'd assume that Nvidia will just provide a shim for the GPU and CUDA stuff; but it's hard to imagine what benefit they would derive from being uncooperative about the basic 'ARM cores and assorted non-GPU peripherals' stuff, since keeping those stuck in some awful BSP is a pain for their customers and those components aren't nearly as interesting and distinguishing as the Nvidia-specific GPU stuff.
One can obviously debate the value of this; but my impression is that, while in an ideal world they'd like to be able to support more hardware, when it comes down to it the Linux project really isn't interested in just providing a cheap OS for people to put on top of their giant heap of binary blobs. They certainly aren't as hardline as the FSF; but even the 'engineer-pragmatist' types see binary blobs as an impediment to their work(that's why the kernel taint flag exists: if your system crashes, you have a potentially interesting bug report; but if it was 30% Nvidia blackbox by weight at the time, they don't want to waste their time shooting in the dark).
Linux does support(and, at least outside of the smaller embedded systems, is typically configured to use) kernel modules that are loaded as needed for driver support and the like; but those modules are treated as part of 'the kernel' when talking about kernel development(for devices that have in-tree drivers, there is nothing stopping you from using modules from other sources, if available).
As with Windows drivers, a Linux system will typically only load kernel modules based on what is actually present on the system it is running on(so an Intel GPU-based system wouldn't ever load AMD power management stuff, though a Linux distribution might include those modules on the disk somewhere in order to support as many different hardware configurations as possible). If the module is developed by the kernel team, in sync with the kernel, it is still treated as part of 'the X.Y kernel', even though actually using it is optional.
It isn't quite as ghastly as it used to be(if more because of increased integration of peripherals than because of any philosophical shift); but it still seems to be the case that the PC OEMs will only assure specific components if you purchase from their 'business' lines, since IT departments like image stability; while the consumer offerings will only offer 'something gigabit' or 'something 802.11ac'(though in practice you often get lucky, since chipset-churn can eat up much of the savings provided by perpetually hunting the cheapest chipsets, so you'll often see a reasonably long period of identical hardware between the silent revisions).
It's worth noting, in terms of 'difficulty of dealing with undocumented binary blobs and ACPI in general', that Microsoft's own designed, developed, and blessed Surface Pro and Surface Book products have been dogged by power management issues; and that's with hardware hand picked by Microsoft, an OS built by Microsoft, and drivers and firmware either written by Microsoft or written for Microsoft by vendors who do most of their driver development work to support Microsoft OSes.
Obviously "but look at the other guy!" isn't an argument against the fact that Linux on laptops indeed has issues; it just provides some perspective on what a ghastly mess PC power management is. If Microsoft's own "Our OEMs are making us look bad, so here's a kick in the ass and a reminder of what kind of products we want in the PC space" product can't power-manage properly, that doesn't imply positive things about the difficulty for the Linux kernel team of getting power management to work correctly on some random vendor's apathetic attempt to shove a laptop out the door for as little money as possible.
I suspect that some of them are largely blind to this stuff: it's not as though hackers and FOSS idealists don't exist; but to the degree that people are hired by interested parties to work on the kernel, it is substantially about servers/HPC and assorted embedded systems. In these cases, the hardware you are working on supporting may or may not even include ACPI(on the embedded side) and won't be miserable consumer crap subjected to some of the hairier suspend/resume/unexpected user behavior stuff(on the server/HPC side); and the hardware you are doing your work on can be basically whatever you like, since SSH-ing in to a remote system or running a bunch of VMs, or using whatever debug interface some ARM dev board provides don't tend to require running Linux even if you are working on making Linux run.
Even those who aren't blind(Linus certainly swears enthusiastically when ACPI comes up) I'd imagine that there is no terribly good solution to a problem that can come up in myriad different ways depending on the device, vendor, BIOS/UEFI version, peripherals, etc. Some sort of support for "Don't try to do ACPI correctly, just apply the ghastly-awful-hacks-I've-constructed-for-this-device" is really about all you could do at the kernel development level without committing to the Sisyphean task of trying to hunt down and reverse engineer as many dysfunctional ACPI implementations as you can find and include one-off quirks support for each one of them.
I'd be the first to agree that Linux on laptops, especially if you try the new or exotic ones, isn't so hot; but it's not clear how the kernel developers are well placed to do something about it.