Google already provides that reason by strongly encouraging developers to use the ADK (Java) instead of NDK (platform-specific) for Android app/game development exactly to avoid locking themselves down to a specific ISA. Google is probably not too pleased with prevalent use of NDK in Android's top-2000 apps.
If Intel manages to produce an ART or DALVIK JRE for x86 that performs closer to native performance in more circumstances, it would make x86-based SoCs stronger options for portable apps and weaken the case for developers choosing to use ARM-NDK. I imagine Google would be quite happy with that.
Baytrail had a fairly big performance lead on most ARM-based chips in CPU-centric benchmarks at launch and scored a fair number of design wins early this year so Intel appears to be making a fair amount of progress there.
Since the "defacto standard" for Android is also for developers to use the ADK which is Java-based (the Android developers' guide recommends against using the NDK unless absolutely necessary), a fair chunk of applications out there do run on Atom-based Android devices as-is; albeit possibly not a chunk of the top-2000 most popular ones that do depend on the NDK for purposes beyond optional optimizations.
If there is a company with years of experience optimizing (re-)compilers, Intel is probably it. I would not be too surprised if Intel optimized the pants off their x86 native recompiler to convince Android developers to quit messing with the ARM NDK.
With Intel bringing the fight to ARM with their 2-3W Atom-based SoCs that give most ARM-based chips a run for their money at least on the CPU front, I would not say x86 is failing to scale to low power anymore.
If Intel continues pushing mobile performance as hard as they have been for the past year, next year should be really interesting.
x86 really started kicking the pants off just about everything else when it went superscalar out-of-order with the Pentium Pro.
As far as cost, speed and efficiency goes, I think modern-day x86 CPUs have proven that x86 can scale surprisingly well across all three parameters.
BTW, x86-64 does not use an "emulator" to run 32bits code. 32bits application code runs natively but the application itself is wrapped inside a 32bits "Windows-on-Windows" layer to map 32bits APIs to the OS' native 64bits APIs. Even in a "native 64bits" Windows application, the use and generation of 64bits code is actually optional; the only immediate difference is the ability to do direct calls to native APIs.
When Ivy Bridge came out, popular Sandy Bridge chips' prices went up and Intel also bumped Ivy Bridge chip prices up $10-20.
When Haswell came out, many of the more popular Ivy Bridge chips went up $10-20 again.
How many years has it been since the last time Intel made major price cut announcements after introducing newer higher-end models within a product line or even introducing a new product line? I do not remember reading about such announcements in over five years; instead of slashing prices, Intel simply discontinues models altogether. If you want to buy Intel chips at prices significantly below launch prices, you have to either buy second-hand or find a vendor who has surplus stock they need to get rid of. (Or buy from Microcenter which appears to have some sort of sweetheart deal with Intel for unlocked chips.)
I am a little puzzled about why they would need to add battery coolant heaters: if their inverter is 95% efficient, that would already give them 1-7kW of waste heat they can use as a heater to get batteries to operating temperature fairly quickly if they bypass the radiator until then.
Of course, that does not work so well if people want to drive like madmen right out of their driveway or the highway they use is practically in their backyard. I suppose that would be who plug-in battery heaters would be for.
How do autopilots in airplanes work? They work on the assumption that they have a clear path along their assigned course based on the flight plan and when that assumption is incorrect (assuming the potential obstruction has TCAS), alarms start going off to prompt pilots to do something to avoid the probable crash. As long as the pilots and ATC do their jobs right, most collision avoidance is taken care of before the plane even lifts off.
This is very different from driving on the streets where there are no "flight plans", no authority managing space reservations along streets, tons of other cars, cyclists, pedestrians, intersections, etc. all over the place that require continuous on-the-spot adjustments to immediate surroundings instead of only worrying about probable obstacles 50km or 2-3mins ahead. Driving a car is a lot more involved than just setting a speed, direction and altitude to the next way-point and let the computer worry about maintaining those parameters between way-points.
Autopilots on planes are basically cruise-control on steroids: about equivalent to slapping lane-sensing cameras and front/rear radar/sonar to measure distances on a car and letting cruise-control handle speed, holding lane position and maintaining safe distances within that lane; basically, take most of the mundane part of flights or highway driving off the pilots' or drivers' hands - if they choose to.
Designing a car autopilot to handle staying in a lane for 300km of highway is a much simpler challenge than designing a car autopilot that can cope with urban and downtown neighborhoods where obstacles can pop out from anywhere with little to no warning.
Toyota, Honda and Ford got sued by plenty of people about overstated fuel efficiency - particularly in colder states and Canada where many complain that their hybrid car has worse real-world MPG than plain ICE cars.
How much MPG inflation was applied to "Car A" vs "Car B" ?
If Car A scores 50MPG using a tweaked evaluation rebuild while Car B scores 40MPG in all-stock off-the-assembly-line configuration, there is a fairly good chance Car B may actually fare better under real-world conditions than a stock version of Car A.
It is a bit like F1 racing: under ideal conditions, the engine would be designed to just barely not fall apart until the last race of the season is over. For an MPG evaluation, the car only needs to last long enough to complete the tests without any obvious signs of problems and I bet there are many inventive ways to inflate MPG figures using that.
Part of the reason for the "blacklist" is because FCC certification is only valid for individual WiFi card + antenna combinations and the list prevents accidental use of non-certified combinations.
I used the empirical method: before I even read about the RPoV, I had already discovered that being too close to displays made me feel like the screen was ripping my eyes out after too many hours and found that this problem completely went away (for me) around 30-36" and RPoV explains why I need to sit at least that far to be comfortable in front of a screen for arbitrarily long periods of time... I discovered my RPoV before knowing what it was called.
This is a bit like an eye exam where you are supposed to let your eyes focus without straining to get the most accurate reading for your prescription.
And yes, I do sit at 30-40" from my PC displays most of the time... I happened to have a tape measure on my desk right now so I measured my current distance just for the heck of it and I'm at 42".
There is such a thing as too closely: the human eye has something called the "resting point of vergeance" which is the focal distance at which the eye focuses at rest.
This is the ideal minimum viewing distance if you want to stare at a screen for arbitrarily long periods of time. The average RPoV is around 38" but can vary from 10" to 60" depending on individual, physical condition, viewing conditions, etc. Mine is around 35" with glasses on, 10" without glasses.
That would be 3800 gallons assuming power to recharge your electric car was free. If it costs you a dollar per gallon equivalent (75% lower $/mile), you now need over 5000 gallons before reaching break-even not counting the likely 1-2 battery replacements along the way.
Yeah, the economics behind all-electric does not add up with such large up-front premiums.
The sad thing about all-electric is that it is technically much simpler than ICE and should be cheaper to mass-produce too since it uses mostly cheap materials, does not require as much complex molding, precision machining and cumbersome heavy-lifting. The biggest challenge is the battery.
Hosting servers on your own network instead of peering achieves roughly the same goal; all it changes is which network the server resides on but that server still needs to connect to the network and effectively acts as a substitute for extra direct-peering links to the content provider.
By skipping the common NNI between CDN/peers/content-provider, the on-net content servers/caches effectively bypass congestion at the NNI layer and act as a fast lane. Different spin, same net effect.
Google knows that song fairly well since they provide content cache appliances to ISPs for Youtube.
AMD may have shed the risk associated with owning fabs but process-wise, they have also slipped almost two process generations behind Intel - Intel is about to start shipping 14nm products while AMD is still on 28nm.
And Intel is also sharing some of their fab costs by leasing some of their capacity to other fab-less chip designers such as Altera.
I bet AMD never expected TSMC and GF to slip so far behind Intel when they spun their fabs off.
There is not much point in "forcing them apart" since they are already staying mostly apart from each other: yes, there might be four major wired service providers in the USA but in most neighborhoods, only one or two of them are available... for the most part, they avoid overlapping with each other beyond one telco and one cableco duopoly.
With the original Bell breakup, regulators expected the mini-Bells to compete with each other for territory but the Bells ended up sticking to their home turfs.
First mile access is a natural monopoly: overlapping on a competitor's territory is expensive and yields a fraction of the revenue investing in an exclusive market does.
If you want to end the first mile monopoly, you have to turn it into a public utility that any service provider can rent or some variant of that model.
In cryptography, RNGs are typically used to seed PRNGs.
You do not send the random bits: you encrypt and transmit the PRNG seed along with whatever other parameters might be necessary to synchronize both ends then use the PRNG to generate your nonces and the nonces are used to generate your OTP blocks.
I do not see where the problem with a camera is: even if you lock the camera in a perfectly dark EMI-shielded box, the CCD or CMOS sensor will still have a fair amount of thermal noise and the same goes for the ADCs so even if all the camera does is take images of the darkness, it will still get a fair amount of entropy from thermal and electrical noise. Put a few thousand pixels worth of this through SHA256 and now you have a pretty decent RNG even if you only get one LSB worth of entropy per pixel..
Give them a motivation to actually try to make a half-decent effort at weeding out the obvious and not evaluating patents related to domains they clearly have not got a damned clue about.
Do what all the small ISPs are now doing, dedicated 1gb fiber to all customers, all leading back to a consolidation chassis that has more bandwidth than all of the ports running full rate,
Last I heard, the going rate for a 100gb line card is down to about $6k.
That sounds nice in theory but can quickly become cost-prohibitive in practice. All the OLTs I remember reading about have at least a 10:1 contention ratio between their maximum possible aggregate downstream capacity and uplink capacity. When you have up to 432x1GbE subscribers sharing 40Gbps of uplink, the likelihood of all 432 subscribers simultaneously trying to pull an average of nearly 90Mbps worth of unicast traffic at any given time is extremely low.
As for your 6k$, you are definitely not getting a line card at that price - at least not from a top-tier carrier-grade router manufacturer: line cards for Cisco, Juniper, Brocade and most others usually cost over 100k$ unless you are looking at 1GbE or low-port-count 10GbE cards. For 6k$, you can a QFP module to plug in in a 100GbE line card... so you pay ~200k$ for the line cards themselves and then another ~6k$ per port you want to use for the QFP that goes in it that matches whatever wiring or fiber you want to use. A fully-configured 100GbE router can easily cost millions of dollars.
Paying $0.5/mbit to peer with someone is outrageously expensive. For $0.50, you can get transit from LA to NY, not just down the street like with peering.
And that is the problem: providing tons of bandwidth between PoPs is relatively cheap and easy as long as there is still dark fiber or wavelength services available between endpoints with all the equipment neatly packed in carrier hotels along strategic fiber routes. Spreading it out to every address in the coverage area on the other hand is extremely inefficient and costly. With Netflix accounting for ~1/3 of all internet traffic, cablecos can put 1/3 of the blame on them for having to go through more node splits faster than planned and upgrading all intermediate hops between the CMTSes and the peering point(s) too.
The ISPs' costs extend well beyond the peering point but the peering point is the most convenient place to try charging something for it. Failing that, ISPs would simply apply steeper rate hikes across the board, which sucks for people who use less than the average or median (I do not care which one you pick - at least half of people get screwed either way since the average will likely be higher than median) amount of bandwidth.
No matter which way you slice it, the customer ultimately gets screwed.
In a hypothetical world where Comcast was forced to bend over to L3 and Cogent, Comcast would probably have increased their rates by an additional $0.50/month and earned ~200M$/year extra that way... maybe add it as a below-the-line "Netflix peering imbalance compensation" fee to let subscribers know that this new fee covers some sort of Netflix-related costs.
Comcast did not want to relax their settlement-free peering deal with Cogent and L3 to accommodate increased Netflix traffic before and let their peering points saturate, rendering Netflix nearly unusable before the direct peering deal. In other words, this "imagine how pissed their customers would be if they could not get Netflix" is exactly the scenario Comcast is coming from and what Netflix paid to put an end to.
It is not 100% profit since Comcast still needs to add ports to their routers for Netflix to connect to and adjust the rest of their network accordingly.
Even if it was straight 100% net profit, we are still talking less than 80M$/year, which is less than 0.1% of Comcast's income; practically a rounding error within Comcast's accounting or around $5/year per Netflix customer using Comcast.
To me, that sounds like tons of ado about nothing. Cogent and L3 are frustrated about losing Netflix as a client, Netflix discovered that direct peering might actually not be as bad as they originally feared and now Cogent/L3 are trying to raise the stink again because they want regulatory protections against losing more clients to direct peering.
With Netflix accounting for almost 1/3 of all internet traffic, they could justify buying a large chunk of Cogent or L3 simply to fulfill their own needs.
Slashdot Mirror
Intel needs to provide that reason.
Google already provides that reason by strongly encouraging developers to use the ADK (Java) instead of NDK (platform-specific) for Android app/game development exactly to avoid locking themselves down to a specific ISA. Google is probably not too pleased with prevalent use of NDK in Android's top-2000 apps.
If Intel manages to produce an ART or DALVIK JRE for x86 that performs closer to native performance in more circumstances, it would make x86-based SoCs stronger options for portable apps and weaken the case for developers choosing to use ARM-NDK. I imagine Google would be quite happy with that.
Baytrail had a fairly big performance lead on most ARM-based chips in CPU-centric benchmarks at launch and scored a fair number of design wins early this year so Intel appears to be making a fair amount of progress there.
Since the "defacto standard" for Android is also for developers to use the ADK which is Java-based (the Android developers' guide recommends against using the NDK unless absolutely necessary), a fair chunk of applications out there do run on Atom-based Android devices as-is; albeit possibly not a chunk of the top-2000 most popular ones that do depend on the NDK for purposes beyond optional optimizations.
If there is a company with years of experience optimizing (re-)compilers, Intel is probably it. I would not be too surprised if Intel optimized the pants off their x86 native recompiler to convince Android developers to quit messing with the ARM NDK.
With Intel bringing the fight to ARM with their 2-3W Atom-based SoCs that give most ARM-based chips a run for their money at least on the CPU front, I would not say x86 is failing to scale to low power anymore.
If Intel continues pushing mobile performance as hard as they have been for the past year, next year should be really interesting.
x86 really started kicking the pants off just about everything else when it went superscalar out-of-order with the Pentium Pro.
As far as cost, speed and efficiency goes, I think modern-day x86 CPUs have proven that x86 can scale surprisingly well across all three parameters.
BTW, x86-64 does not use an "emulator" to run 32bits code. 32bits application code runs natively but the application itself is wrapped inside a 32bits "Windows-on-Windows" layer to map 32bits APIs to the OS' native 64bits APIs. Even in a "native 64bits" Windows application, the use and generation of 64bits code is actually optional; the only immediate difference is the ability to do direct calls to native APIs.
When Ivy Bridge came out, popular Sandy Bridge chips' prices went up and Intel also bumped Ivy Bridge chip prices up $10-20.
When Haswell came out, many of the more popular Ivy Bridge chips went up $10-20 again.
How many years has it been since the last time Intel made major price cut announcements after introducing newer higher-end models within a product line or even introducing a new product line? I do not remember reading about such announcements in over five years; instead of slashing prices, Intel simply discontinues models altogether. If you want to buy Intel chips at prices significantly below launch prices, you have to either buy second-hand or find a vendor who has surplus stock they need to get rid of. (Or buy from Microcenter which appears to have some sort of sweetheart deal with Intel for unlocked chips.)
I am a little puzzled about why they would need to add battery coolant heaters: if their inverter is 95% efficient, that would already give them 1-7kW of waste heat they can use as a heater to get batteries to operating temperature fairly quickly if they bypass the radiator until then.
Of course, that does not work so well if people want to drive like madmen right out of their driveway or the highway they use is practically in their backyard. I suppose that would be who plug-in battery heaters would be for.
Same here. Tried using Win8 as-is for about two weeks, still hated the Metro UI, installed Classic Shell and fluttered on.
How do autopilots in airplanes work? They work on the assumption that they have a clear path along their assigned course based on the flight plan and when that assumption is incorrect (assuming the potential obstruction has TCAS), alarms start going off to prompt pilots to do something to avoid the probable crash. As long as the pilots and ATC do their jobs right, most collision avoidance is taken care of before the plane even lifts off.
This is very different from driving on the streets where there are no "flight plans", no authority managing space reservations along streets, tons of other cars, cyclists, pedestrians, intersections, etc. all over the place that require continuous on-the-spot adjustments to immediate surroundings instead of only worrying about probable obstacles 50km or 2-3mins ahead. Driving a car is a lot more involved than just setting a speed, direction and altitude to the next way-point and let the computer worry about maintaining those parameters between way-points.
Autopilots on planes are basically cruise-control on steroids: about equivalent to slapping lane-sensing cameras and front/rear radar/sonar to measure distances on a car and letting cruise-control handle speed, holding lane position and maintaining safe distances within that lane; basically, take most of the mundane part of flights or highway driving off the pilots' or drivers' hands - if they choose to.
Designing a car autopilot to handle staying in a lane for 300km of highway is a much simpler challenge than designing a car autopilot that can cope with urban and downtown neighborhoods where obstacles can pop out from anywhere with little to no warning.
Toyota, Honda and Ford got sued by plenty of people about overstated fuel efficiency - particularly in colder states and Canada where many complain that their hybrid car has worse real-world MPG than plain ICE cars.
How much MPG inflation was applied to "Car A" vs "Car B" ?
If Car A scores 50MPG using a tweaked evaluation rebuild while Car B scores 40MPG in all-stock off-the-assembly-line configuration, there is a fairly good chance Car B may actually fare better under real-world conditions than a stock version of Car A.
It is a bit like F1 racing: under ideal conditions, the engine would be designed to just barely not fall apart until the last race of the season is over. For an MPG evaluation, the car only needs to last long enough to complete the tests without any obvious signs of problems and I bet there are many inventive ways to inflate MPG figures using that.
Part of the reason for the "blacklist" is because FCC certification is only valid for individual WiFi card + antenna combinations and the list prevents accidental use of non-certified combinations.
I used the empirical method: before I even read about the RPoV, I had already discovered that being too close to displays made me feel like the screen was ripping my eyes out after too many hours and found that this problem completely went away (for me) around 30-36" and RPoV explains why I need to sit at least that far to be comfortable in front of a screen for arbitrarily long periods of time... I discovered my RPoV before knowing what it was called.
This is a bit like an eye exam where you are supposed to let your eyes focus without straining to get the most accurate reading for your prescription.
And yes, I do sit at 30-40" from my PC displays most of the time... I happened to have a tape measure on my desk right now so I measured my current distance just for the heck of it and I'm at 42".
There is such a thing as too closely: the human eye has something called the "resting point of vergeance" which is the focal distance at which the eye focuses at rest.
This is the ideal minimum viewing distance if you want to stare at a screen for arbitrarily long periods of time. The average RPoV is around 38" but can vary from 10" to 60" depending on individual, physical condition, viewing conditions, etc. Mine is around 35" with glasses on, 10" without glasses.
That would be 3800 gallons assuming power to recharge your electric car was free. If it costs you a dollar per gallon equivalent (75% lower $/mile), you now need over 5000 gallons before reaching break-even not counting the likely 1-2 battery replacements along the way.
Yeah, the economics behind all-electric does not add up with such large up-front premiums.
The sad thing about all-electric is that it is technically much simpler than ICE and should be cheaper to mass-produce too since it uses mostly cheap materials, does not require as much complex molding, precision machining and cumbersome heavy-lifting. The biggest challenge is the battery.
The nuclear and elemental particle physicists' message to God.
Hosting servers on your own network instead of peering achieves roughly the same goal; all it changes is which network the server resides on but that server still needs to connect to the network and effectively acts as a substitute for extra direct-peering links to the content provider.
By skipping the common NNI between CDN/peers/content-provider, the on-net content servers/caches effectively bypass congestion at the NNI layer and act as a fast lane. Different spin, same net effect.
Google knows that song fairly well since they provide content cache appliances to ISPs for Youtube.
AMD may have shed the risk associated with owning fabs but process-wise, they have also slipped almost two process generations behind Intel - Intel is about to start shipping 14nm products while AMD is still on 28nm.
And Intel is also sharing some of their fab costs by leasing some of their capacity to other fab-less chip designers such as Altera.
I bet AMD never expected TSMC and GF to slip so far behind Intel when they spun their fabs off.
There is not much point in "forcing them apart" since they are already staying mostly apart from each other: yes, there might be four major wired service providers in the USA but in most neighborhoods, only one or two of them are available... for the most part, they avoid overlapping with each other beyond one telco and one cableco duopoly.
With the original Bell breakup, regulators expected the mini-Bells to compete with each other for territory but the Bells ended up sticking to their home turfs.
First mile access is a natural monopoly: overlapping on a competitor's territory is expensive and yields a fraction of the revenue investing in an exclusive market does.
If you want to end the first mile monopoly, you have to turn it into a public utility that any service provider can rent or some variant of that model.
In cryptography, RNGs are typically used to seed PRNGs.
You do not send the random bits: you encrypt and transmit the PRNG seed along with whatever other parameters might be necessary to synchronize both ends then use the PRNG to generate your nonces and the nonces are used to generate your OTP blocks.
I do not see where the problem with a camera is: even if you lock the camera in a perfectly dark EMI-shielded box, the CCD or CMOS sensor will still have a fair amount of thermal noise and the same goes for the ADCs so even if all the camera does is take images of the darkness, it will still get a fair amount of entropy from thermal and electrical noise. Put a few thousand pixels worth of this through SHA256 and now you have a pretty decent RNG even if you only get one LSB worth of entropy per pixel..
Give them a motivation to actually try to make a half-decent effort at weeding out the obvious and not evaluating patents related to domains they clearly have not got a damned clue about.
Do what all the small ISPs are now doing, dedicated 1gb fiber to all customers, all leading back to a consolidation chassis that has more bandwidth than all of the ports running full rate,
Last I heard, the going rate for a 100gb line card is down to about $6k.
That sounds nice in theory but can quickly become cost-prohibitive in practice. All the OLTs I remember reading about have at least a 10:1 contention ratio between their maximum possible aggregate downstream capacity and uplink capacity. When you have up to 432x1GbE subscribers sharing 40Gbps of uplink, the likelihood of all 432 subscribers simultaneously trying to pull an average of nearly 90Mbps worth of unicast traffic at any given time is extremely low.
As for your 6k$, you are definitely not getting a line card at that price - at least not from a top-tier carrier-grade router manufacturer: line cards for Cisco, Juniper, Brocade and most others usually cost over 100k$ unless you are looking at 1GbE or low-port-count 10GbE cards. For 6k$, you can a QFP module to plug in in a 100GbE line card... so you pay ~200k$ for the line cards themselves and then another ~6k$ per port you want to use for the QFP that goes in it that matches whatever wiring or fiber you want to use. A fully-configured 100GbE router can easily cost millions of dollars.
Paying $0.5/mbit to peer with someone is outrageously expensive. For $0.50, you can get transit from LA to NY, not just down the street like with peering.
And that is the problem: providing tons of bandwidth between PoPs is relatively cheap and easy as long as there is still dark fiber or wavelength services available between endpoints with all the equipment neatly packed in carrier hotels along strategic fiber routes. Spreading it out to every address in the coverage area on the other hand is extremely inefficient and costly. With Netflix accounting for ~1/3 of all internet traffic, cablecos can put 1/3 of the blame on them for having to go through more node splits faster than planned and upgrading all intermediate hops between the CMTSes and the peering point(s) too.
The ISPs' costs extend well beyond the peering point but the peering point is the most convenient place to try charging something for it. Failing that, ISPs would simply apply steeper rate hikes across the board, which sucks for people who use less than the average or median (I do not care which one you pick - at least half of people get screwed either way since the average will likely be higher than median) amount of bandwidth.
No matter which way you slice it, the customer ultimately gets screwed.
In a hypothetical world where Comcast was forced to bend over to L3 and Cogent, Comcast would probably have increased their rates by an additional $0.50/month and earned ~200M$/year extra that way... maybe add it as a below-the-line "Netflix peering imbalance compensation" fee to let subscribers know that this new fee covers some sort of Netflix-related costs.
Comcast did not want to relax their settlement-free peering deal with Cogent and L3 to accommodate increased Netflix traffic before and let their peering points saturate, rendering Netflix nearly unusable before the direct peering deal. In other words, this "imagine how pissed their customers would be if they could not get Netflix" is exactly the scenario Comcast is coming from and what Netflix paid to put an end to.
that's a 100% net profit.
It is not 100% profit since Comcast still needs to add ports to their routers for Netflix to connect to and adjust the rest of their network accordingly.
Even if it was straight 100% net profit, we are still talking less than 80M$/year, which is less than 0.1% of Comcast's income; practically a rounding error within Comcast's accounting or around $5/year per Netflix customer using Comcast.
To me, that sounds like tons of ado about nothing. Cogent and L3 are frustrated about losing Netflix as a client, Netflix discovered that direct peering might actually not be as bad as they originally feared and now Cogent/L3 are trying to raise the stink again because they want regulatory protections against losing more clients to direct peering.
With Netflix accounting for almost 1/3 of all internet traffic, they could justify buying a large chunk of Cogent or L3 simply to fulfill their own needs.