Aside from the egregious delay in fixing these things; does anyone else get a very, very, bad feeling about the expected quality of the firmware when 'supply a string longer than a normal user would type' is a successful attack?
If you aren't sanitizing your inputs against that one; what are you sanitizing?
Ironically, that's the main sense in which arguments that Mercator projections are 'imperialist' aren't total nonsense:
You don't 'imperialize' by drawing the other guy's country really small and hurting his feelings; you do so by having the maritime expertise to deliver troops and maintain supply lines across large areas of the world; and conquering the other guy's country.
As a rather useful projection for navigation, Mercator can definitely help you out with that; the wonky land areas are just a minor side effect.
The trouble isn't with the Mercator projection, it does what it was designed to do well enough; but the somewhat baffling decision to make a map whose main virtues are for marine navigation the quasi-default for classroom applications mostly focused on what happens on land.
I've never heard a particularly cogent justification for that one.
It's considered tacky to talk about 'blocking' GPS; but if you look for 'GPS signal generators' or 'GPS simulators', you can get hardware that doesn't merely interfere with GPS; but can produce a fairly convincing GPS fix for a time/location/etc. that you specify. Tricky and subtle to fool a suitably nice GPS system that is actively paranoid about the possibility; a couple of antennas on the ground just doesn't look quite like a satellite constellation; but can fool more naive GPS systems quite effectively.
It is suspected that this is the technique behind a few surveillance drones that were led off course and (mostly) soft-landed in hostile areas(I think the most recent case was a US drone that got a little too close to the Iranians). Really shoddy firmware might get fatally confused if you suddenly present it with some wild fantasy data; but if you start feeding accurate GPS signals, and gradually skew them, error can quickly and quietly accumulate much faster than a naive target might suggest.
I imagine that the power of blocking or spoofing GPS depends mostly on how many backup instruments you have; and how paranoid you are. GPS is preferred because it provides very well-behaved data from a chip that costs peanuts; but it's not as though everyone just stumbled around and got lost before it was available. A drone built right down to budget and weight might not have anything to fall back on; but compasses, terrain-following, inertial navigation, even celestial navigation if it isn't too sunny are all options.
I assume that someone with service provider MiTM access could do a bunch of SS7 weirdness, in order to confuse attribution; but that's my understanding: if you have privileged access at the provider level, you don't need to do anything to traffic routing/redirection that might attract attention, you can just grab a copy as it passes by; while if you don't have provider-level cooperation;, you either need to try to get the traffic sent somewhere you do have access to(or run the comparatively great risk of sending people out with stingrays to do it in person; which is likely a poor plan unless you are the local cops.
Sort of like when something deeply unsettling happens to the world's BGP configurations. Ma Bell doesn't need to mess with those to tap your stuff; but some backwater that normally doesn't pass traffic worth spying on needs to modify things if they want to intercept something of interest.
That might work in select locations; but CIWS isn't cheap(Phalanx is north of $5 million a pop; albeit probably more because of the support electronics than the gun alone); and ammunition isn't inexpensive and is a nontrivial danger to everyone in the area; and both factors are going to limit the number of places you can get away with deploying it.
This should improve the odds that cheapo Chinese drones start to feature more robust IMU/gyro/etc. based fallbacks for dealing with excessive RF noise!
In all seriousness, jamming a drone obviously makes life harder, since it excludes all 'basically just an RC airplane' hardware; prevents the operator from getting footage or issuing new commands, and so on; but it's hardly some rule of the universe that 'just make a docile attempt at landing' is the inevitable response to hitting a nasty RF spike. A variety of options, from heuristics of various sophistication for backing out and trying to escape the jamming; to attempts to fly straight toward where the emissions are most intense and ruin the jammer's day; to just dead-reckoning via onboard sensors and a backup flight path, all exist.
And that doesn't include the drones that actually have some nontrivial machine vision capabilities, or sensors other than cameras that can be used for navigation, though such tend to be rather more expensive.
If they are being paid in a way that reflects their being competent-or-better actual engineers; expecting them to play IT isn't necessarily unreasonable; but it seems pretty dumb.
You don't want to deal with lousy IT, no matter how much money you 'save'; because that's just miserable; but if you are paying an electrical engineer to spin up EC2 instances or a civil engineer to be poking at a recalcitrant data logger rather than thinking guru-level thoughts about concrete loading, you are arguably squandering relatively expensive and rare talent on problems that a reasonably competent small-shop IT generalist is exactly the sort of person to make go away so that your subject matter experts can do their thing.
Engineers who can't handle writing(or at least prototyping) simulation code are potentially more of an issue(expecting them to whip out their l33t optimization skills to save you a modest amount of CPU time by rendering the code unmaintanable is often folly; but it's been a while since most engineering disciplines were amenable to calculations entirely on slide rules and legal pads); but even there the value of an engineer who can go from Debian_netinst_x86-64 to 'fully configured numPy environment' is something that is a trifle hard to stress over as long as they know what to do with a development environment once set up.
I have a personal fondness for generalist tinkering, so I sympathize; but I also recognize that much of my generalist tinkering is purely recreational because it involves either fiddling with stuff that I'm not very good at; or doing things that someone cheaper could easily do because I'm interested in how they work. In this case, I'd be severely doubtful of the wisdom of trying to impose IT stuff on a bunch of actual, went-to-engineer-school-and-are-priced-to-reflect-that, engineers rather than investigate the possibility of finding a reasonably flexible IT/lightweight 'CS' with strong tinkering background person who appreciates the variety of an office too small for rigid specialization and the chance to poke at a wide variety of problems; and making that person available to your engineers for fiddling with peripherals, basic network and systems administration, any EC2 jockeying, etc.
It's actually quite simple: just avoid storing all of this sort of data to begin with!"
So it's just Dun & Bradstreet's well-known dedication to establishing the dictatorship of the proletariat that caused them to accumulate all these data? Not, y'know, the fact that it's how they make money? This seems eminently plausible...
Just remember; focus on the 'scary hackers' side of the story; not the 'the data were already aggregated and available, and presumably in use, well before the leak occurred' aspect.
As long as giant databases remain in respectable hands, no harm can come of them; so just worry about whether it was a nation-state actor or an 'advanced persistent threat'. Nothing else to see here.
Since demonstrating your loyalty by listening to the company podcast is voluntary; I, for one, express childlike faith that it is completely impossible that compliance statistics would be gathered in the background; or ever factored in to a decision to not-fire-because-they-aren't-employees somebody. That sort of covert stuff just isn't Uber's company culture!
Surely if we wanted accommodation for dealing with a dying family member he should have gone with a company that touts its commitment to work/death balance?
Without further evidence I'm inclined to be skeptical; but (while the TLAs seem to prefer more whiz-bang techniques when they have the option); I'd imagine that good, old fashioned, human infiltration is both likely to be effective and likely to be pretty low risk; which makes it a concern.
Both proprietary and OSS software have to be written and reviewed by somebody; and ensuring that your people end up as some of the important 'somebodys' is likely to be pretty doable if you have competent employees available; and they are willing to accept not-wildly-competitive salaries or do unpaid maintainer shit work because you are also paying them.
There is some risk of discovery, it's hard to obfuscate perfectly while still leaving useful backdoors and exploits; but there's the handy feature that it's not as though the LKML or Facebook get to shoot people for treason and espionage; so the worst-case is being blackballed by part of the tech industry and having to go back to working on internal projects, or get a job with Booz Allen Hamilton; which isn't too terrifying a prospect by espionage standards.
The classification of encryption software as a munition wasn't so much 'preposterious' as it was 'completely futile'.
Unless you adopt an intentionally myopic view of 'munitions' that excludes pretty much everything except the actual component that ends up embedded in your opponent's chest cavity, encryption has at least as good a claim as, say, imaging hardware, ECM, fancy radar absorbent materials, and similar things that don't directly kill anyone; but are enormously useful in either detecting the other guy so you can kill him; or keeping him from detecting you so that he cannot.
It's just that, unlike most of the other items on that list, good cryptographic algorithms can be copied in arbitrary quantities from a single smuggled example by people who wouldn't even qualify as script kiddies(reverse engineering usually makes life easier when trying to clone most hardware; but you still need at least something resembling an industrial base and skilled workforce if you want to take a single fancy night scope or something and start producing equivalents on a useful scale; and you also don't tend to develop mature, high end, hardware without a reasonably long period of incremental progress and refinement of your production capacity.
Even if there weren't a single decent cryptographer or number theorist outside the US(and obviously absurd assumption), nobody expects that you can intercept 100% of the copies; and software is such that any idiot can turn one copy into as many copies as you want, all perfect. Sophisticated physical objects, by contrast, are often quite informative; but even keeping one maintained without access to parts can be tricky; and using one to establish independent manufacture is within reach only of people who already have pretty credible capacity.
Anyone who thought that the munition classification was going to keep crypto out of anyone's hands was an idiot; but the classification itself is reasonably plausible.
That sounds more like an 'ugly; but not unrealistic' case than a 'worst possible' case.
Incandescent lighting is substantially dead; and that's a bunch of neat resistive load that has been handed off to the low-bidder PSUs crammed into CCFLs and LED 'bulbs', consumer electronics widgets often have slightly nicer quality; but also produce all kinds of weird line noise. That pretty much leaves you with the refrigerator, stove(if electric), and AC(if any). Doesn't mean that measuring is going to be easy; but if you are providing an electrical meter that is supposed to be good enough for billing purposes, getting it right is an important obligation.
Depends on how fast you extract it; but it's a rare aquifer is replenished faster than a bunch of users whose only cost for tapping it is subsidized diesel to drive the pumps will tend to extract.
Depending on how far out in the sticks they are, transmission costs probably don't help; nor does the fact that using a diesel pump is going to turn diesel into water-moved-where-you-want-it more efficiently than running a diesel generator, transmission lines to the desired location, and then running an electric pump unless the engine in question is small enough that it can't get even close to the efficiency that larger heat engines enjoy.
If you are using electricity to pump water; and want the water at night, why would you use batteries; rather than 'gravity'? You don't need to elevate water much to get it to flow downhill; and storing water a few meters above ground level is cheaper and more mature than battery tech by a substantial margin.
(Now, anyone for a bet on how many years these guys have before 'finding groundwater that still exists' becomes a markedly more exciting challenge than 'pumping it' is?)
I certainly would have no reason to argue that.africa isn't at least as worthy as a great many other gTLDs; and since we've already started down that dumb idea, there's no principled reason to deny the request to create it; it's just that gTLDs are mostly worthless trash with no particularly good reason to exist, so not being worse than they are isn't much of an achievement; and I would also have a difficult time arguing in favor of the utility and value of the TLD.
Even if the AU were way more EU-like, having a TLD for a continent; rather than for entities in the AU zone or something, still wouldn't make a whole lot of sense.
If having their precious vanity domain amuses some people, it certainly won't be the dumbest idea ICANN has dabbled in; but it's hard to make a good case for a TLD that is geographic, rather than vaguely tied to a concept, like.com and friends; but covers an area that is unified more or less only in the sense that it's classified as a single continent. For the purposes of travel, trade, customs, currency, etc. there isn't really such a thing as 'Africa', there are 54 nation states(not all of them exactly happy with each other at any given time); plus a dozen or so oddball dependencies and quasi-states that have some trappings of statehood but not enough clout to get full recognition. Unless you expect your customers to suck at geography and need to remind them what continent you are on for some reason, 'is in or associated with Africa' really doesn't clarify much.
It does. The part in the Pixel is(I think) a Qualcomm; but they are annoying as hell to get datasheets for; so these examples are Realtek:
Here are their I2S codecs(what you'd likely find in a cellphone or similar device); and here are the Intel HDA ones; as you'd see in a PC. Unless you are doing something particularly fancy(in which case the an offboard DSP might actually be worth the trouble); the main purpose appears to be allowing you to decouple the ADCs and DACs(which aren't necessarily well suited to being fabbed on the process that makes the most sense for a SoC or PC chipset; and which can vary widely in number and quality depending on the desired features of the product, which would lead to nasty SKU proliferation) from the SoC or chipset; with just a simple, versatile, digital data link between the two chips, allowing the SoC or chipset to support a wide variety of audio configurations with just one design; and allowing the device vendor to get their choice of features and performance(anywhere from a single mic, single audio out, lousy ADC and DAC quality; up to zillions-of-peripherals-and-golden-eared-audiophile-DACs) just by attaching a different codec chip.
The most spartan designs might not need a 'codec' at all(you can get MEMs mics that speak I2S directly, with the analog support circutry integrated into the package; and you can also get audio amps/speaker/headphone drivers that speak I2S directly and have a DAC onboard, rather than accepting a low voltage analog audio input); but if you've got a mic array, a speaker, headphone/mic jack, line out, etc. a codec can bundle up all the support for the various analog interfaces and allow you to attach them all to the SoC/chipset with a single digital bus.
In this case, the fact that it's a codec soldering issue is presumably why all three mics die at once. That would be seriously unlikely if the mics themselves failed; but the codec handles all the mics, so a failure there knocks out the mics in roughly the same way that just yanking out a soundcard would.
It may be a sloppy usage, or just unfamiliar to people used to dealing with the delights of 'codec packs' and getting oddball media to play back; but the term 'audio codec' appears to be what they use for the chip that handles talking to one or more mics and audio ins and outs and(possibly in addition to providing hardware accellerated processing of certain features) wraps that all up into a(fairly high speed; but conveniently low pin count and digital, I2S or similar inter-chip audio bus) for connection to the SoC.
At least in the case of the Pixel XL; the part in question is a Qualcomm WCD9335. The usual joys of actually finding Qualcomm datasheets apply; but it's referred to as a "WCD9335 audio codec" in a variety of places it is mentioned.
Given contemporary CPU power, I'm not sure if having the coding and decoding offboard is of much interest anymore; but using the offboard codec allows you to get away with supporting a wide variety of different audio capabilities(anywhere from just single mic and speaker to fancy array mics and zillions of audio ins and outs) with the same SoC implementing a relatively simple digital bus(no need to add a whole bunch of ADCs and DACs to every SoC just in case some high-end phone models want to use them); and allowing the designer to choose a codec chip based on how many mics and audio outs they need to support; whether they care about 'audiophile' DACs, etc.
Somewhat analogous to 'Intel HD Audio' on the PC side: this specifies a fairly cheap and flexible interface with some amount of standardization of how you talk to various features; but doesn't require adding ADCs and DACs to the CPU or chipset; and allows motherboard vendors to use any support chip that speaks HDA depending on their desired budget, number of audio ins and outs, interest in audio quality, etc.
They aren't the vendor used by the Pixel, to my knowledge; but take a look at Cirrus Logic's "'Codecs' page for a whole bunch of datasheets outlining the purpose and capabilities of chips referred to as 'audio codecs'.
.Net Micro is actually pretty teeny for what it is; but it bears about the same relationship to anything Windows that Micropython does to anything Linux: surprisingly good compatibility, for something that supports slightly upmarket microcontrollers, with a popular language used on the OS; but otherwise unrelated.
Slashdot Mirror
Aside from the egregious delay in fixing these things; does anyone else get a very, very, bad feeling about the expected quality of the firmware when 'supply a string longer than a normal user would type' is a successful attack?
If you aren't sanitizing your inputs against that one; what are you sanitizing?
Ironically, that's the main sense in which arguments that Mercator projections are 'imperialist' aren't total nonsense:
You don't 'imperialize' by drawing the other guy's country really small and hurting his feelings; you do so by having the maritime expertise to deliver troops and maintain supply lines across large areas of the world; and conquering the other guy's country.
As a rather useful projection for navigation, Mercator can definitely help you out with that; the wonky land areas are just a minor side effect.
The trouble isn't with the Mercator projection, it does what it was designed to do well enough; but the somewhat baffling decision to make a map whose main virtues are for marine navigation the quasi-default for classroom applications mostly focused on what happens on land.
I've never heard a particularly cogent justification for that one.
It's considered tacky to talk about 'blocking' GPS; but if you look for 'GPS signal generators' or 'GPS simulators', you can get hardware that doesn't merely interfere with GPS; but can produce a fairly convincing GPS fix for a time/location/etc. that you specify. Tricky and subtle to fool a suitably nice GPS system that is actively paranoid about the possibility; a couple of antennas on the ground just doesn't look quite like a satellite constellation; but can fool more naive GPS systems quite effectively.
It is suspected that this is the technique behind a few surveillance drones that were led off course and (mostly) soft-landed in hostile areas(I think the most recent case was a US drone that got a little too close to the Iranians). Really shoddy firmware might get fatally confused if you suddenly present it with some wild fantasy data; but if you start feeding accurate GPS signals, and gradually skew them, error can quickly and quietly accumulate much faster than a naive target might suggest.
I imagine that the power of blocking or spoofing GPS depends mostly on how many backup instruments you have; and how paranoid you are. GPS is preferred because it provides very well-behaved data from a chip that costs peanuts; but it's not as though everyone just stumbled around and got lost before it was available. A drone built right down to budget and weight might not have anything to fall back on; but compasses, terrain-following, inertial navigation, even celestial navigation if it isn't too sunny are all options.
I assume that someone with service provider MiTM access could do a bunch of SS7 weirdness, in order to confuse attribution; but that's my understanding: if you have privileged access at the provider level, you don't need to do anything to traffic routing/redirection that might attract attention, you can just grab a copy as it passes by; while if you don't have provider-level cooperation;, you either need to try to get the traffic sent somewhere you do have access to(or run the comparatively great risk of sending people out with stingrays to do it in person; which is likely a poor plan unless you are the local cops.
Sort of like when something deeply unsettling happens to the world's BGP configurations. Ma Bell doesn't need to mess with those to tap your stuff; but some backwater that normally doesn't pass traffic worth spying on needs to modify things if they want to intercept something of interest.
That might work in select locations; but CIWS isn't cheap(Phalanx is north of $5 million a pop; albeit probably more because of the support electronics than the gun alone); and ammunition isn't inexpensive and is a nontrivial danger to everyone in the area; and both factors are going to limit the number of places you can get away with deploying it.
This should improve the odds that cheapo Chinese drones start to feature more robust IMU/gyro/etc. based fallbacks for dealing with excessive RF noise!
In all seriousness, jamming a drone obviously makes life harder, since it excludes all 'basically just an RC airplane' hardware; prevents the operator from getting footage or issuing new commands, and so on; but it's hardly some rule of the universe that 'just make a docile attempt at landing' is the inevitable response to hitting a nasty RF spike. A variety of options, from heuristics of various sophistication for backing out and trying to escape the jamming; to attempts to fly straight toward where the emissions are most intense and ruin the jammer's day; to just dead-reckoning via onboard sensors and a backup flight path, all exist.
And that doesn't include the drones that actually have some nontrivial machine vision capabilities, or sensors other than cameras that can be used for navigation, though such tend to be rather more expensive.
If they are being paid in a way that reflects their being competent-or-better actual engineers; expecting them to play IT isn't necessarily unreasonable; but it seems pretty dumb.
You don't want to deal with lousy IT, no matter how much money you 'save'; because that's just miserable; but if you are paying an electrical engineer to spin up EC2 instances or a civil engineer to be poking at a recalcitrant data logger rather than thinking guru-level thoughts about concrete loading, you are arguably squandering relatively expensive and rare talent on problems that a reasonably competent small-shop IT generalist is exactly the sort of person to make go away so that your subject matter experts can do their thing.
Engineers who can't handle writing(or at least prototyping) simulation code are potentially more of an issue(expecting them to whip out their l33t optimization skills to save you a modest amount of CPU time by rendering the code unmaintanable is often folly; but it's been a while since most engineering disciplines were amenable to calculations entirely on slide rules and legal pads); but even there the value of an engineer who can go from Debian_netinst_x86-64 to 'fully configured numPy environment' is something that is a trifle hard to stress over as long as they know what to do with a development environment once set up.
I have a personal fondness for generalist tinkering, so I sympathize; but I also recognize that much of my generalist tinkering is purely recreational because it involves either fiddling with stuff that I'm not very good at; or doing things that someone cheaper could easily do because I'm interested in how they work. In this case, I'd be severely doubtful of the wisdom of trying to impose IT stuff on a bunch of actual, went-to-engineer-school-and-are-priced-to-reflect-that, engineers rather than investigate the possibility of finding a reasonably flexible IT/lightweight 'CS' with strong tinkering background person who appreciates the variety of an office too small for rigid specialization and the chance to poke at a wide variety of problems; and making that person available to your engineers for fiddling with peripherals, basic network and systems administration, any EC2 jockeying, etc.
"What is a non-leftist solution to this problem?
It's actually quite simple: just avoid storing all of this sort of data to begin with!"
So it's just Dun & Bradstreet's well-known dedication to establishing the dictatorship of the proletariat that caused them to accumulate all these data? Not, y'know, the fact that it's how they make money? This seems eminently plausible...
Just remember; focus on the 'scary hackers' side of the story; not the 'the data were already aggregated and available, and presumably in use, well before the leak occurred' aspect.
As long as giant databases remain in respectable hands, no harm can come of them; so just worry about whether it was a nation-state actor or an 'advanced persistent threat'. Nothing else to see here.
Since demonstrating your loyalty by listening to the company podcast is voluntary; I, for one, express childlike faith that it is completely impossible that compliance statistics would be gathered in the background; or ever factored in to a decision to not-fire-because-they-aren't-employees somebody. That sort of covert stuff just isn't Uber's company culture!
Has Nintendo ever done a decent job with software that isn't a game?
Surely if we wanted accommodation for dealing with a dying family member he should have gone with a company that touts its commitment to work/death balance?
Without further evidence I'm inclined to be skeptical; but (while the TLAs seem to prefer more whiz-bang techniques when they have the option); I'd imagine that good, old fashioned, human infiltration is both likely to be effective and likely to be pretty low risk; which makes it a concern.
Both proprietary and OSS software have to be written and reviewed by somebody; and ensuring that your people end up as some of the important 'somebodys' is likely to be pretty doable if you have competent employees available; and they are willing to accept not-wildly-competitive salaries or do unpaid maintainer shit work because you are also paying them.
There is some risk of discovery, it's hard to obfuscate perfectly while still leaving useful backdoors and exploits; but there's the handy feature that it's not as though the LKML or Facebook get to shoot people for treason and espionage; so the worst-case is being blackballed by part of the tech industry and having to go back to working on internal projects, or get a job with Booz Allen Hamilton; which isn't too terrifying a prospect by espionage standards.
The classification of encryption software as a munition wasn't so much 'preposterious' as it was 'completely futile'.
Unless you adopt an intentionally myopic view of 'munitions' that excludes pretty much everything except the actual component that ends up embedded in your opponent's chest cavity, encryption has at least as good a claim as, say, imaging hardware, ECM, fancy radar absorbent materials, and similar things that don't directly kill anyone; but are enormously useful in either detecting the other guy so you can kill him; or keeping him from detecting you so that he cannot.
It's just that, unlike most of the other items on that list, good cryptographic algorithms can be copied in arbitrary quantities from a single smuggled example by people who wouldn't even qualify as script kiddies(reverse engineering usually makes life easier when trying to clone most hardware; but you still need at least something resembling an industrial base and skilled workforce if you want to take a single fancy night scope or something and start producing equivalents on a useful scale; and you also don't tend to develop mature, high end, hardware without a reasonably long period of incremental progress and refinement of your production capacity.
Even if there weren't a single decent cryptographer or number theorist outside the US(and obviously absurd assumption), nobody expects that you can intercept 100% of the copies; and software is such that any idiot can turn one copy into as many copies as you want, all perfect. Sophisticated physical objects, by contrast, are often quite informative; but even keeping one maintained without access to parts can be tricky; and using one to establish independent manufacture is within reach only of people who already have pretty credible capacity.
Anyone who thought that the munition classification was going to keep crypto out of anyone's hands was an idiot; but the classification itself is reasonably plausible.
That sounds more like an 'ugly; but not unrealistic' case than a 'worst possible' case.
Incandescent lighting is substantially dead; and that's a bunch of neat resistive load that has been handed off to the low-bidder PSUs crammed into CCFLs and LED 'bulbs', consumer electronics widgets often have slightly nicer quality; but also produce all kinds of weird line noise. That pretty much leaves you with the refrigerator, stove(if electric), and AC(if any). Doesn't mean that measuring is going to be easy; but if you are providing an electrical meter that is supposed to be good enough for billing purposes, getting it right is an important obligation.
Depends on how fast you extract it; but it's a rare aquifer is replenished faster than a bunch of users whose only cost for tapping it is subsidized diesel to drive the pumps will tend to extract.
Depending on how far out in the sticks they are, transmission costs probably don't help; nor does the fact that using a diesel pump is going to turn diesel into water-moved-where-you-want-it more efficiently than running a diesel generator, transmission lines to the desired location, and then running an electric pump unless the engine in question is small enough that it can't get even close to the efficiency that larger heat engines enjoy.
If you are using electricity to pump water; and want the water at night, why would you use batteries; rather than 'gravity'? You don't need to elevate water much to get it to flow downhill; and storing water a few meters above ground level is cheaper and more mature than battery tech by a substantial margin.
(Now, anyone for a bet on how many years these guys have before 'finding groundwater that still exists' becomes a markedly more exciting challenge than 'pumping it' is?)
I certainly would have no reason to argue that .africa isn't at least as worthy as a great many other gTLDs; and since we've already started down that dumb idea, there's no principled reason to deny the request to create it; it's just that gTLDs are mostly worthless trash with no particularly good reason to exist, so not being worse than they are isn't much of an achievement; and I would also have a difficult time arguing in favor of the utility and value of the TLD.
So the gTLDs are a total slum and surprisingly expensive? I'm even more impressed.
Even if the AU were way more EU-like, having a TLD for a continent; rather than for entities in the AU zone or something, still wouldn't make a whole lot of sense.
.com and friends; but covers an area that is unified more or less only in the sense that it's classified as a single continent. For the purposes of travel, trade, customs, currency, etc. there isn't really such a thing as 'Africa', there are 54 nation states(not all of them exactly happy with each other at any given time); plus a dozen or so oddball dependencies and quasi-states that have some trappings of statehood but not enough clout to get full recognition. Unless you expect your customers to suck at geography and need to remind them what continent you are on for some reason, 'is in or associated with Africa' really doesn't clarify much.
If having their precious vanity domain amuses some people, it certainly won't be the dumbest idea ICANN has dabbled in; but it's hard to make a good case for a TLD that is geographic, rather than vaguely tied to a concept, like
It does. The part in the Pixel is(I think) a Qualcomm; but they are annoying as hell to get datasheets for; so these examples are Realtek:
Here are their I2S codecs(what you'd likely find in a cellphone or similar device); and here are the Intel HDA ones; as you'd see in a PC. Unless you are doing something particularly fancy(in which case the an offboard DSP might actually be worth the trouble); the main purpose appears to be allowing you to decouple the ADCs and DACs(which aren't necessarily well suited to being fabbed on the process that makes the most sense for a SoC or PC chipset; and which can vary widely in number and quality depending on the desired features of the product, which would lead to nasty SKU proliferation) from the SoC or chipset; with just a simple, versatile, digital data link between the two chips, allowing the SoC or chipset to support a wide variety of audio configurations with just one design; and allowing the device vendor to get their choice of features and performance(anywhere from a single mic, single audio out, lousy ADC and DAC quality; up to zillions-of-peripherals-and-golden-eared-audiophile-DACs) just by attaching a different codec chip.
The most spartan designs might not need a 'codec' at all(you can get MEMs mics that speak I2S directly, with the analog support circutry integrated into the package; and you can also get audio amps/speaker/headphone drivers that speak I2S directly and have a DAC onboard, rather than accepting a low voltage analog audio input); but if you've got a mic array, a speaker, headphone/mic jack, line out, etc. a codec can bundle up all the support for the various analog interfaces and allow you to attach them all to the SoC/chipset with a single digital bus.
In this case, the fact that it's a codec soldering issue is presumably why all three mics die at once. That would be seriously unlikely if the mics themselves failed; but the codec handles all the mics, so a failure there knocks out the mics in roughly the same way that just yanking out a soundcard would.
It may be a sloppy usage, or just unfamiliar to people used to dealing with the delights of 'codec packs' and getting oddball media to play back; but the term 'audio codec' appears to be what they use for the chip that handles talking to one or more mics and audio ins and outs and(possibly in addition to providing hardware accellerated processing of certain features) wraps that all up into a(fairly high speed; but conveniently low pin count and digital, I2S or similar inter-chip audio bus) for connection to the SoC.
At least in the case of the Pixel XL; the part in question is a Qualcomm WCD9335. The usual joys of actually finding Qualcomm datasheets apply; but it's referred to as a "WCD9335 audio codec" in a variety of places it is mentioned.
Given contemporary CPU power, I'm not sure if having the coding and decoding offboard is of much interest anymore; but using the offboard codec allows you to get away with supporting a wide variety of different audio capabilities(anywhere from just single mic and speaker to fancy array mics and zillions of audio ins and outs) with the same SoC implementing a relatively simple digital bus(no need to add a whole bunch of ADCs and DACs to every SoC just in case some high-end phone models want to use them); and allowing the designer to choose a codec chip based on how many mics and audio outs they need to support; whether they care about 'audiophile' DACs, etc.
Somewhat analogous to 'Intel HD Audio' on the PC side: this specifies a fairly cheap and flexible interface with some amount of standardization of how you talk to various features; but doesn't require adding ADCs and DACs to the CPU or chipset; and allows motherboard vendors to use any support chip that speaks HDA depending on their desired budget, number of audio ins and outs, interest in audio quality, etc.
They aren't the vendor used by the Pixel, to my knowledge; but take a look at Cirrus Logic's "'Codecs' page for a whole bunch of datasheets outlining the purpose and capabilities of chips referred to as 'audio codecs'.
.Net Micro is actually pretty teeny for what it is; but it bears about the same relationship to anything Windows that Micropython does to anything Linux: surprisingly good compatibility, for something that supports slightly upmarket microcontrollers, with a popular language used on the OS; but otherwise unrelated.