Failing to have peerage agreements in place to honor your downstream sales commitments is a form of throttling - Or, I would daresay, a form of outright fraud.
Only problem with that is Verizon has TONS of under-used transit capacity with other networks - when Verizon posted their thing about peering points with Netflix's partners, they also mentioned that their transit to other networks at times where Netflix was hitting 100% was only ~40% on average.
So, Verizon would have plenty of transit capacity if it was spread more evenly across all the peering Verizon has.
And the reason why using VPNs or other work-arounds works is because they cause traffic to pass through one of Verizon's under-used routes instead of the overloaded routes between Verizon and Netflix preferred by Netflix's CDNs and transit providers.
If the Netflix traffic distribution was more evenly spread both geographically and across available peers, Verizon would have much fewer reasons to object to upgrades.
The overlap region between ideal track centers is still somewhat of a gap; albeit not a dead/silent one.
There will still be some residual information in there due to head deviations from the ideal path and when solving complex puzzles like reconstructing overwritten PRML blocks, every little extra hint counts.
I have little doubt it is possible to recover at least some data from PRML drives that have been erased once, maybe twice. But the process would probably require the precision and sensitivity of something like an atomic force microscope, which would be a "little" too much time and effort for the casual identity thief or creep.
If you want to use sonar to map the ocean, you measure multi-path delays, phase shift, attenuation, etc. using a receiver array too.
Radar does much of the same as well: you need the delay to calculate the distance, phase/doppler shift to calculate the speed and heading, signal strength to estimate the cross-section, etc.
You can go way beyond just measuring drift from nominal values. With a distributed receiver array, they could probably use multi-path delays, reflection, attenuation, etc. from thermals, air currents, moisture, etc. to calculate temperature and other parameters almost anywhere within the network's airspace.
There is still a gap between tracks in today's drives; just nowhere near as much so whatever signal might be available on the fringes will be much weaker.
The real killer for PRML-based drives is that to cope with the amount of noise the head receives from nearby tracks, the coding itself relies on statistical analysis to reconstruct the data. Whatever signal might be on the fringe will be some blend of the old data under the current track, the new data, data on the tracks to either side, the previous data on the tracks to either side, etc. There may not be enough signal left in-between tracks after a full PRNG erase or two to recover anything useful.
That's what magnifiers and optical microscopes are for.
Even if you cannot individually identify pixels, you can still notice the marginally sharper text/line-art edges, smoother gradients, reduced stair-casing along polygon edges in 3D applications, etc.
But beyond 300dpi at typical tablet/smartphone reading/playing distances, I doubt that many people would really care about difference between 300-350dpi and 400-450+dpi.
There isn't much of a point in pushing display densities much beyond 300dpi for hand-held applications since most people can barely tell the difference but Apple was the first one to make a big deal out of it. Announcing higher resolutions sold many of the previous models and will sell future ones too - with the progress stagnation that has hit smartphones and tablets for much of the past two years, higher resolutions and the IGP power to drive them are almost the only two things that have improved by a fair amount.
Personally, I would be far more interested in seeing 1920x1200. 2GB RAM and 32GB SSD become the norm below 10"/$300. Right now, the N7-2013 is still practically the only tablet below $300 with those specs and price point. Most other devices below $300 launched in 2013-2014 have specs closer to the more ancient N7-2012 or sometimes even worse, which is sad, a shame and ridiculous. If analysts and manufacturers are surprised to see tablet sales dropped, they have not been paying attention to the crap the market has been flooded with for most of the past two years; no surprise sales are dropping when there is nothing worth upgrading to on the market.
The only differences being that with cell towers, the receivers and transmitters are controlled by two independent parties and the signal itself was not intended for that particular purpose.
You know exactly where the tower is, you can easily reconstruct the RF signal as-transmitted by receiving the bitstream yourself and calculating the original signal as-sent. All that is left to do is compute the correlation between measured signals across your receiver network and weather along the receiver-transmitter path and their immediate surroundings.
This is a bit like a radar version of passive sonar.
Cameras can fail, the communication links between the camera and whatever serves video stream can fail, the displays themselves can fail, power to the displays can fail, etc.
If you do a simple HUD overlaid on top of the conventional glass window, at least you are not completely screwed even if there is a compounded instrumentation failure as long as you can still get visual cues somewhere such as the moon, stars, city lights, runway and slope guidance beacons when landing, etc.
As long as you still have some degree of flight control left, line-of-sight, skills and luck, you can land a plane even with extensive instrumentation failures - there have been many seemingly impossible yet successful landings.
Having cockpit displays/HUDs to aggregate, complement and supplement existing instruments is fine but for completely replacing direct line-of-sight as a backup? I don't think so.
Geoblocking and all the unnecessary middlemen that try to use it to secure their artificial geographic monopolies need to die if they refuse to compete globally.
To be fair to local online vendors though, there would need to be an international standard for sales taxes such as one harmonized rate per country so international vendors would at least not need to deal with the countless regional variants within countries when charging foreign taxes. Another possibility would be to let financial institutions charge domestic taxes on the taxable part of electronic purchases since they are well-versed in the tax codes of whatever regions they do business in so vendors would not need to worry about managing international taxes at all.
If developers do not want to worry about the underlying hardware, all they need to do is stick to Google's developer guidelines and use Java. Let the JRE and native recompiler abstract all the hardware-dependent stuff. Not quite as compute/power-efficient (at least in theory) but from what I have seen, there seems to be tons of developers who waste tons of cycles regardless of portable vs native anyway.
I'm using Classic Shell too and I agree it does fix nearly everything that annoyed me in Win 8.x
Many people on the other hand are still upset (exaggeratedly so IMO) with needing third-party applications to restore classic start menu functionality or are adamantly opposed to any sort of such work-around.
If your "secure" applications run on Linux, Windows or any other major modern OS, that's hundreds of million lines of code that even experienced developers have little to no insight into and many of the security exploits that pop up, Heartbleed being the latest high-profile case, are tied to baked code and libraries that get reused by thousands of developers with implicit trust since almost nobody can afford to re-audit that code for themselves even when they have the expertise to do so.
Even if your application's own code is technically flawlessly secure, there are countless ways the OS, other applications running on the same machine and hardware may be used to undermine your otherwise perfect security.
The problems extend far beyond self-taught programming... and self-taught programmers are not intrinsically bad either.
Systems these days are so hopelessly complex due to running full-blown OSes (mainly Linux derivatives like Android these days) for convenience that guaranteeing security is practically impossible most of the time since nobody ever knows the system inside-out so everyone is relying on everyone else making their own part of the source tree work properly without unforeseen unexpected interactions between software components and also with the hardware.
Most developers and companies do not have the time and resources to go over and get intimately acquainted with every minute detail of their development environment, libraries, OS, etc. to understand the millions of ways things can possibly go wrong assuming they even have access to the source code in the first place. If they had to do that before getting to work on their actual project, most of them would die from old age before doing anything so demanding that degree of understanding is simply not realistic.
The threat of severe legal penalties for things that are often nearly impossible to foresee would make tons of would-be developers give up on the idea - it simply makes no sense.
Gases ionize when hit with atomic decay particles/radiations. A transistor with a high probability of spontaneously turning on in radioactive environments sounds dangerous to me.
Weight measurements are simple: the weight of a non-volatile substance (or volatile substance in a container) does not change with time, temperature or other variables. You have a quantity of whatever, put it on the scale and you are done.
Jewelry is a poor example for W&M policing since jewelry is luxury goods and jewelry is not sold by weight in the first place. Try the retail food and gas industry instead. I do not know how it works in the USA but in Canada, calibration stickers for pumps and balances used for retail must be in plain sight where consumers can easily inspect them and merchants are required to stop using the equipment if their calibration is out of date. No calibration, no sale.
Available bandwidth through a network of networks however is infinitely variable: there is nothing that can be "calibrated" to guarantee any amount of bandwidth along any particular route at any given time since the whole standard internet operates on a "best-effort" basis where "best-effort" actually means no special effort at all - just leave the equipment on and forwarding packets. If you want guaranteed performance between two points across the internet, you need to pay intervening networks for a private virtual circuit of some sort.
Currently the ISPs market "Up to 50mb!" but thats only if no one else out of your remote is currently online.
If you have 50Mbps over phone lines, you have VDSL2 and VDSL2 remotes typically have at least 20Mbps of available upstream capacity per port so if everyone on the same remote has 50Mbps service, about 40% of people connected to it can simultaneously use their service at full speed before the remote actually becomes a choking point. This part of the service is something the ISP has full direct control and visibility into. Even ancient ADSL1 DSLAMs had the ability to probe lines for service quality monitoring/provisioning purposes, everyone knows performance on xDSL depends on line quality and that part of the service has absolutely nothing to do with network neutrality.
Where things become far less predictable is when the traffic leaves the ISP's middle-mile infrastructure, interconnects with peers and transit providers, internal hops across those external parties the ISP has absolutely no visibility into or power to do anything about, interconnect between those third-parties and others beyond, the far-end interconnects between those third-parties' third-parties, the far-end network, etc.
If you want network neutrality to start defining some degree of end-to-end performance guarantees (unless further limited by technical limitations such as maximum sustainable line sync), the whole internet would be affected; not only the first-mile operators.
There are thousands of variables that can affect the bandwidth available between points A and B across the internet, many of which beyond the end-users and the ISPs' control, which makes any sort of bandwidth guarantees with "best-effort" transit impossible to actually guarantee in any remotely meaningful way. Throwing W&M, NIST or whatever else at this is not going to do anyone any good.
If you want everyone's internet service to effectively be covered by an end-to-end bandwidth SLA of some sort, things are likely going to get a fair bit more expensive if the minimum guarantee is to be remotely usable.
There is plenty of time since all modern gear uses some variant of store-and-forward architecture and routers need to be able to rewrite packet headers to set things like the ECN bit, modify the QoS field, check/update the TTL, check/update the CRC, etc. Most of the circuitry for this basic line-rate processing is built directly in the chips handling individual ports and most of that processing can be done on-the-fly as data gets shifted in/out of the ingress port's buffer during the store-and-forward process, addling little if any extra latency to the store-and-forward process.
The whole process of looking up through routing tables and scheduling a path between the chip receiving ingress data from a port and the chip driving the egress port is a far more complex operation than checking QoS flags to decide which priority egress queue it will land in (most modern equipment has eight egress queues to match Ethernet's three bits Class-of-Service tag) and then picking which queue gets a packet sent out next.
Basic traffic prioritization based on the QoS field is dead-simple and extremely lightweight hardware-wise.
The difference between phone and internet is that phone is classified as an essential service or very close to and has nearly absolute QoS guarantees short if infrastructure getting ripped apart. Internet on the other hand is merely a best-effort service every step of the way unless extraordinary measures (ex.: order FTTP/FTTB with SLA for both the link uptime and bandwidth through both endpoint ISPs and their intermediate network(s)) are taken to get around that.
If the whole internet was built up to the same standards as the PSTN network is (no congestion whatsoever allowed during typical peak hours), internet service could end up considerably more expensive.
You do not need fancy routers to do QoS: all you need is an agreement on your NNI (such as paid transit based on QoS tag) with whoever wants to pass QoS'd traffic to your network or whatever network you want to pass QoS'd traffic to and enable QoS-based routing on your routers and switches - DiffServ QoS has been supported by half-decent carrier-grade routers over a decade. Heck, even entry-level managed switches can do basic L3 QoS-based switching (such as mapping DiffServ QoS to Ethernet CoS tags) these days.
You want QoS for VoIP, video service providers (cable/phone or other) or subscribers may want QoS for their video streaming, other services may want QoS for whatever it is they are doing and end-users may want QoS for yet other different stuff.
QoS is just one of many methods that can be used to prioritize stuff. The only difference between cable/telco and over-the-top service providers is that the incumbent actually has access to the equipment to do it whichever way they please and manage associated costs whichever way they want.
Since there is no standard for handling QoS between networks, passing QoS'd traffic through peers and transit providers require extra agreements between entities and higher rates for the extra effort if the QoS tagging is going to actually be honored across the other parties' networks. Much of the time, networks simply clear the QoS field on ingress at their border routers.
If Network Neutrality allowed QoS and forced the whole transit and ISP business to honor it, it would come with extra fees attached to offset the extra costs. We are back almost exactly where everything started: premium rates for premium services.
Urine is not a fuel in TFA. They extracted a few chemicals from it which can be used to process carbon electrodes that allegedly outperform conventional carbon electrodes with platinum catalyst.
Eliminating the need for platinum could considerably reduce costs.
Slashdot Mirror
Failing to have peerage agreements in place to honor your downstream sales commitments is a form of throttling - Or, I would daresay, a form of outright fraud.
Only problem with that is Verizon has TONS of under-used transit capacity with other networks - when Verizon posted their thing about peering points with Netflix's partners, they also mentioned that their transit to other networks at times where Netflix was hitting 100% was only ~40% on average.
So, Verizon would have plenty of transit capacity if it was spread more evenly across all the peering Verizon has.
And the reason why using VPNs or other work-arounds works is because they cause traffic to pass through one of Verizon's under-used routes instead of the overloaded routes between Verizon and Netflix preferred by Netflix's CDNs and transit providers.
If the Netflix traffic distribution was more evenly spread both geographically and across available peers, Verizon would have much fewer reasons to object to upgrades.
The overlap region between ideal track centers is still somewhat of a gap; albeit not a dead/silent one.
There will still be some residual information in there due to head deviations from the ideal path and when solving complex puzzles like reconstructing overwritten PRML blocks, every little extra hint counts.
I have little doubt it is possible to recover at least some data from PRML drives that have been erased once, maybe twice. But the process would probably require the precision and sensitivity of something like an atomic force microscope, which would be a "little" too much time and effort for the casual identity thief or creep.
If you want to use sonar to map the ocean, you measure multi-path delays, phase shift, attenuation, etc. using a receiver array too.
Radar does much of the same as well: you need the delay to calculate the distance, phase/doppler shift to calculate the speed and heading, signal strength to estimate the cross-section, etc.
You can go way beyond just measuring drift from nominal values. With a distributed receiver array, they could probably use multi-path delays, reflection, attenuation, etc. from thermals, air currents, moisture, etc. to calculate temperature and other parameters almost anywhere within the network's airspace.
There is still a gap between tracks in today's drives; just nowhere near as much so whatever signal might be available on the fringes will be much weaker.
The real killer for PRML-based drives is that to cope with the amount of noise the head receives from nearby tracks, the coding itself relies on statistical analysis to reconstruct the data. Whatever signal might be on the fringe will be some blend of the old data under the current track, the new data, data on the tracks to either side, the previous data on the tracks to either side, etc. There may not be enough signal left in-between tracks after a full PRNG erase or two to recover anything useful.
That's what magnifiers and optical microscopes are for.
Even if you cannot individually identify pixels, you can still notice the marginally sharper text/line-art edges, smoother gradients, reduced stair-casing along polygon edges in 3D applications, etc.
But beyond 300dpi at typical tablet/smartphone reading/playing distances, I doubt that many people would really care about difference between 300-350dpi and 400-450+dpi.
There isn't much of a point in pushing display densities much beyond 300dpi for hand-held applications since most people can barely tell the difference but Apple was the first one to make a big deal out of it. Announcing higher resolutions sold many of the previous models and will sell future ones too - with the progress stagnation that has hit smartphones and tablets for much of the past two years, higher resolutions and the IGP power to drive them are almost the only two things that have improved by a fair amount.
Personally, I would be far more interested in seeing 1920x1200. 2GB RAM and 32GB SSD become the norm below 10"/$300. Right now, the N7-2013 is still practically the only tablet below $300 with those specs and price point. Most other devices below $300 launched in 2013-2014 have specs closer to the more ancient N7-2012 or sometimes even worse, which is sad, a shame and ridiculous. If analysts and manufacturers are surprised to see tablet sales dropped, they have not been paying attention to the crap the market has been flooded with for most of the past two years; no surprise sales are dropping when there is nothing worth upgrading to on the market.
The only differences being that with cell towers, the receivers and transmitters are controlled by two independent parties and the signal itself was not intended for that particular purpose.
You know exactly where the tower is, you can easily reconstruct the RF signal as-transmitted by receiving the bitstream yourself and calculating the original signal as-sent. All that is left to do is compute the correlation between measured signals across your receiver network and weather along the receiver-transmitter path and their immediate surroundings.
This is a bit like a radar version of passive sonar.
Cameras can fail, the communication links between the camera and whatever serves video stream can fail, the displays themselves can fail, power to the displays can fail, etc.
If you do a simple HUD overlaid on top of the conventional glass window, at least you are not completely screwed even if there is a compounded instrumentation failure as long as you can still get visual cues somewhere such as the moon, stars, city lights, runway and slope guidance beacons when landing, etc.
As long as you still have some degree of flight control left, line-of-sight, skills and luck, you can land a plane even with extensive instrumentation failures - there have been many seemingly impossible yet successful landings.
Having cockpit displays/HUDs to aggregate, complement and supplement existing instruments is fine but for completely replacing direct line-of-sight as a backup? I don't think so.
Geoblocking and all the unnecessary middlemen that try to use it to secure their artificial geographic monopolies need to die if they refuse to compete globally.
To be fair to local online vendors though, there would need to be an international standard for sales taxes such as one harmonized rate per country so international vendors would at least not need to deal with the countless regional variants within countries when charging foreign taxes. Another possibility would be to let financial institutions charge domestic taxes on the taxable part of electronic purchases since they are well-versed in the tax codes of whatever regions they do business in so vendors would not need to worry about managing international taxes at all.
If developers do not want to worry about the underlying hardware, all they need to do is stick to Google's developer guidelines and use Java. Let the JRE and native recompiler abstract all the hardware-dependent stuff. Not quite as compute/power-efficient (at least in theory) but from what I have seen, there seems to be tons of developers who waste tons of cycles regardless of portable vs native anyway.
I'm using Classic Shell too and I agree it does fix nearly everything that annoyed me in Win 8.x
Many people on the other hand are still upset (exaggeratedly so IMO) with needing third-party applications to restore classic start menu functionality or are adamantly opposed to any sort of such work-around.
If your "secure" applications run on Linux, Windows or any other major modern OS, that's hundreds of million lines of code that even experienced developers have little to no insight into and many of the security exploits that pop up, Heartbleed being the latest high-profile case, are tied to baked code and libraries that get reused by thousands of developers with implicit trust since almost nobody can afford to re-audit that code for themselves even when they have the expertise to do so.
Even if your application's own code is technically flawlessly secure, there are countless ways the OS, other applications running on the same machine and hardware may be used to undermine your otherwise perfect security.
The problems extend far beyond self-taught programming... and self-taught programmers are not intrinsically bad either.
Systems these days are so hopelessly complex due to running full-blown OSes (mainly Linux derivatives like Android these days) for convenience that guaranteeing security is practically impossible most of the time since nobody ever knows the system inside-out so everyone is relying on everyone else making their own part of the source tree work properly without unforeseen unexpected interactions between software components and also with the hardware.
Most developers and companies do not have the time and resources to go over and get intimately acquainted with every minute detail of their development environment, libraries, OS, etc. to understand the millions of ways things can possibly go wrong assuming they even have access to the source code in the first place. If they had to do that before getting to work on their actual project, most of them would die from old age before doing anything so demanding that degree of understanding is simply not realistic.
The threat of severe legal penalties for things that are often nearly impossible to foresee would make tons of would-be developers give up on the idea - it simply makes no sense.
Gases ionize when hit with atomic decay particles/radiations. A transistor with a high probability of spontaneously turning on in radioactive environments sounds dangerous to me.
DisplayPort did not support 2160p60 out-of-the-box either; it needed v1.2 to get there.
HDMI can do 2160p60 too, just needs v2.0.
Weight measurements are simple: the weight of a non-volatile substance (or volatile substance in a container) does not change with time, temperature or other variables. You have a quantity of whatever, put it on the scale and you are done.
Jewelry is a poor example for W&M policing since jewelry is luxury goods and jewelry is not sold by weight in the first place. Try the retail food and gas industry instead. I do not know how it works in the USA but in Canada, calibration stickers for pumps and balances used for retail must be in plain sight where consumers can easily inspect them and merchants are required to stop using the equipment if their calibration is out of date. No calibration, no sale.
Available bandwidth through a network of networks however is infinitely variable: there is nothing that can be "calibrated" to guarantee any amount of bandwidth along any particular route at any given time since the whole standard internet operates on a "best-effort" basis where "best-effort" actually means no special effort at all - just leave the equipment on and forwarding packets. If you want guaranteed performance between two points across the internet, you need to pay intervening networks for a private virtual circuit of some sort.
Currently the ISPs market "Up to 50mb!" but thats only if no one else out of your remote is currently online.
If you have 50Mbps over phone lines, you have VDSL2 and VDSL2 remotes typically have at least 20Mbps of available upstream capacity per port so if everyone on the same remote has 50Mbps service, about 40% of people connected to it can simultaneously use their service at full speed before the remote actually becomes a choking point. This part of the service is something the ISP has full direct control and visibility into. Even ancient ADSL1 DSLAMs had the ability to probe lines for service quality monitoring/provisioning purposes, everyone knows performance on xDSL depends on line quality and that part of the service has absolutely nothing to do with network neutrality.
Where things become far less predictable is when the traffic leaves the ISP's middle-mile infrastructure, interconnects with peers and transit providers, internal hops across those external parties the ISP has absolutely no visibility into or power to do anything about, interconnect between those third-parties and others beyond, the far-end interconnects between those third-parties' third-parties, the far-end network, etc.
If you want network neutrality to start defining some degree of end-to-end performance guarantees (unless further limited by technical limitations such as maximum sustainable line sync), the whole internet would be affected; not only the first-mile operators.
This should be enforced by weights and measures.
Good luck with that.
There are thousands of variables that can affect the bandwidth available between points A and B across the internet, many of which beyond the end-users and the ISPs' control, which makes any sort of bandwidth guarantees with "best-effort" transit impossible to actually guarantee in any remotely meaningful way. Throwing W&M, NIST or whatever else at this is not going to do anyone any good.
If you want everyone's internet service to effectively be covered by an end-to-end bandwidth SLA of some sort, things are likely going to get a fair bit more expensive if the minimum guarantee is to be remotely usable.
There is plenty of time since all modern gear uses some variant of store-and-forward architecture and routers need to be able to rewrite packet headers to set things like the ECN bit, modify the QoS field, check/update the TTL, check/update the CRC, etc. Most of the circuitry for this basic line-rate processing is built directly in the chips handling individual ports and most of that processing can be done on-the-fly as data gets shifted in/out of the ingress port's buffer during the store-and-forward process, addling little if any extra latency to the store-and-forward process.
The whole process of looking up through routing tables and scheduling a path between the chip receiving ingress data from a port and the chip driving the egress port is a far more complex operation than checking QoS flags to decide which priority egress queue it will land in (most modern equipment has eight egress queues to match Ethernet's three bits Class-of-Service tag) and then picking which queue gets a packet sent out next.
Basic traffic prioritization based on the QoS field is dead-simple and extremely lightweight hardware-wise.
The only time I remember getting one of these was in the middle of the '98 ice-storm.
How often do you get "all circuits busy" without some form of significant scale disaster attached?
The difference between phone and internet is that phone is classified as an essential service or very close to and has nearly absolute QoS guarantees short if infrastructure getting ripped apart. Internet on the other hand is merely a best-effort service every step of the way unless extraordinary measures (ex.: order FTTP/FTTB with SLA for both the link uptime and bandwidth through both endpoint ISPs and their intermediate network(s)) are taken to get around that.
If the whole internet was built up to the same standards as the PSTN network is (no congestion whatsoever allowed during typical peak hours), internet service could end up considerably more expensive.
You do not need fancy routers to do QoS: all you need is an agreement on your NNI (such as paid transit based on QoS tag) with whoever wants to pass QoS'd traffic to your network or whatever network you want to pass QoS'd traffic to and enable QoS-based routing on your routers and switches - DiffServ QoS has been supported by half-decent carrier-grade routers over a decade. Heck, even entry-level managed switches can do basic L3 QoS-based switching (such as mapping DiffServ QoS to Ethernet CoS tags) these days.
You want QoS for VoIP, video service providers (cable/phone or other) or subscribers may want QoS for their video streaming, other services may want QoS for whatever it is they are doing and end-users may want QoS for yet other different stuff.
QoS is just one of many methods that can be used to prioritize stuff. The only difference between cable/telco and over-the-top service providers is that the incumbent actually has access to the equipment to do it whichever way they please and manage associated costs whichever way they want.
Since there is no standard for handling QoS between networks, passing QoS'd traffic through peers and transit providers require extra agreements between entities and higher rates for the extra effort if the QoS tagging is going to actually be honored across the other parties' networks. Much of the time, networks simply clear the QoS field on ingress at their border routers.
If Network Neutrality allowed QoS and forced the whole transit and ISP business to honor it, it would come with extra fees attached to offset the extra costs. We are back almost exactly where everything started: premium rates for premium services.
Urine is not a fuel in TFA. They extracted a few chemicals from it which can be used to process carbon electrodes that allegedly outperform conventional carbon electrodes with platinum catalyst.
Eliminating the need for platinum could considerably reduce costs.