Not true. Linux has a NAT implementation for IPv6 already. There's nothing about IPv6 that inherently prevents NAT. It just isn't necessary in nearly as many places.
No support for packet level encryption.
Probably because in practice, encapsulation is "good enough".
Change ISPs? All your internal IPs have to change.
Only if you aren't using NAT. Besides, with service discovery and SLAAC, chances are you won't have to reconfigure anything anyway.
Um, yes we do. They've been used in power tools for something like 7 or 8 years now. And they were first developed nearly 20 years ago.
Ah, but people use cars very differently than they use power tools. Most people keep one battery on a rapid charger, then swap it out when the one they're using goes dead. That's potentially a very different usage model than plugging in your car every night and trickle-charging it over twelve hours or more. You'll probably see a much broader variation of usage patterns in automobiles, too, with some people driving ten miles a day, and others driving a hundred. Finally, cars have a *lot* of cells crammed into a tiny space, all being charged and discharged at once, which means it is also a completely different thermal environment than the one in which power tool batteries operate.
Folks can certainly speculate on how they'll behave long-term in cars based on lab behavior, but I've seen a lot of stuff that works in a lab, but falls apart in the real world. I don't want to be an early adopter of these things. In a few years, when the kinks are worked out, great. Until then, I view batteries with suspicion.:-)
Sorry, but the sort of cells that go into laptops have completely different behavioral properties than the spinels and phosphates used in EVs...
All the laptops I've seen in the past six or seven years use LiPo packs, which as I understand it, is a direction the automakers would like to move in, for space reasons (hopefully after they improve the life expectancy). But point taken.
To some extent, yes, they do. To the best of my knowledge, all rechargeable battery technology exhibits capacity decay over time. The only question is whether they show significant loss of capacity after five years, ten years, twenty years, or some period of time that's long enough that nobody cares anymore. This, in turn, depends on not just the battery technology, but also on how you use it and how the car's charge circuitry was designed—deep discharges from long trips versus lots of very shallow discharges, continuous trickle charging versus letting the battery sag to 90% before you top it up, whether you always charge the battery or allow it to stay mostly discharged for a period of time (which promotes dendrite formation), etc. all play a role in how long a battery lasts.
As far as I can tell, we really have no idea how LiFePO4 is going to hold up in the real world; the sample size of LiFePO4 batteries that are more than a couple of years old is too small. But for older designs that use NiMH or older lithium ion chemistries, we know approximately how long they'll last, and it isn't pretty.
That change happened before television, back when the average politician spent (adjusted for inflation) single-digit millions of dollars when running for the presidency instead of single-digit billions.
It is probably worth pointing out that the vast majority of people with cataracts could dramatically improve their vision just by using N-acetylcarnosine eye drops daily for a few months. Cataract surgery should be reserved for only the most serious cases, and only when eye drop treatment has failed. Instead, surgery seems to be the default treatment in the U.S. And this is, in part, why medical care is so expensive here....
Mean instantaneous power would presumably be calculated by deciding on a sampling interval, determining the wattage at each interval, summing the sample values, and dividing by the number of samples. I mean, if you could somehow come up with a mathematical function, you could ostensibly use an integral, but here in the real world, we tend towards summation.
I think you're missing the point. Coal is rapidly becoming unwelcome, and natural gas is not viable in the long term, either. There's a limited supply of it, and contrary to what some people might have you believe by calling it "clean-burning", it still contributes to global warming, and even if it replaced other fossil fuels, we would still be producing an awful lot of CO2.
In the long term, we have to move to renewable energy. There is simply no other feasible alternative short of discovering oil on Mars (and even then, we will eventually run out). Having solutions in place that make renewable energy feasible as our sole means of providing power is the only way to future-proof our ability to provide power. Whether this project succeeds or fails is immaterial; the lessons learned are absolutely necessary, and we might as well start learning them now.
One the one hand, if the requirements keep changing, developers must change direction, too. What's the point of delivering something that no one wants anymore? If your goal is to deliver functionality that the market no longer wants, then your business will go out of business. Fast.
I think the core problem is not that the basic requirements change, but rather that some key aspects of development, such as UI design, are black holes. The requirement is a usable UI. However, if allowed to do so, the details will change at such a rate that they suck all the developer time away from everything else. "Ooh, could we make it mauve instead?" And maybe we should put this button over there instead of over here. If you don't nail down the design ahead of time and get proper buy-in from all the stakeholders, you're screwed. Iterative design results in design-by-committee unholiness—a product that satisfies no one and takes ten times as long to build.
Well if your requirements are that chaotic, you'll have at least as many problems in waterfall.
No, you won't, because the waterfall model requires you to put everyone in a room and not let them leave until they have agreed to a set of requirements that they can live with. And anything that didn't get hammered out at that initial meeting, unless it really is absolutely a show-stopper, becomes a "we'll take a look at it for version 2.0" feature.
Neither is a miracle cure, if you can get it mostly right the first time do that but if not then you just have to start somewhere rather than wait every detail to be done.
No, if you can't get it mostly right the first time, then your software architect skills are not up to the task of writing that particular piece of software. Thus, the right way to approach the problem is to hire a software architect who can get it mostly right the first time.
Failure to integrate is an avoidable problem; you should have been doing that all along. What I've seen is that you get 90% of the way very quickly, but then because of the lack of sufficient design and architecture planning up front, you end up with a design in which the remaining 10% takes 90% of the time.
In other words, it's an interesting way to build a prototype that you never intend to ship, so long as you understand that the next thing you should do is throw it away, design a proper architecture based on the lessons you learned along the way, and borrow only fragments of the code from the prototype as you build the final design using a more traditional process. If you try to evolve the prototype into the final design, you're in for a world of hurt.
All the planning in the world can not assist with political changes in a business. Requirements are a moving target and agile is the best method formal framework available for integrating those new requirements into the workflow.
Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.
Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.
Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole. This problem can also plague the architecture underneath if you aren't careful.
Depends largely on how dense and pedestrian-friendly the city is. In San Francisco, New York City, or Boston, that would be true. On the flip side, in the south half of the San Francisco Bay Area, it is continuous city, and I see maybe one or two pedestrians every couple of weeks unless I'm on minor roads.
With a fully autonomous system, cars in the appropriate directions would be told to stop after the pedestrian presses a button.
Not if they're designed right, they won't. With a fully autonomous system, the vehicles would by default prefer major roads over minor roads, and those major roads would often have pedestrian bridges. However, when a pedestrian needs to cross a road that lacks such bridges, the pedestrian pressing a button would change that preference.
Any vehicles within a span beginning a block away and extending to three blocks away would shift over one road in either direction. So as soon as the nearest block worth of traffic in either direction clears the intersection, the road would be clear for pedestrians for a period of time, but the cars themselves would not stop, or even slow down.
As for the cars when they are in manual mode? All intersections are to be treated as 4-way stops.
There would still have to be some sort of traffic lights for those vehicles. Preferably all-ways-red until a vehicle or bicycle sits on the sensor for a period of time. Incidentally, bicycles are potentially a concern because of their tendency to blow through stop signs and traffic lights....
In that case, put it in a deep mine, and set up a doomsday switch that nukes the tunnel if civilization falls. By the time civilization gets back to the point where it is capable of mining the stuff again, they'll also be advanced enough to recognize the dangers.
I'm not 100% clear on what this hack does. Are they:
Tricking an app into providing a bogus receipt to broken third-party servers that fail to properly validate store receipts, and thus provide content without a valid purchase,
Taking an existing pirated copy of an in-app purchase blob and tricking the app into thinking that it was provided by the store, or
Tricking an app into thinking that a receipt is valid by changing certificate trust policies, thus causing them to activate a feature that was built into the app to begin with?
In a cave? There's no wind, and little to no groundwater. After all, those are the usual criteria for selecting the locations of these dumps in the first place.
Yes. Write down the same text in, say, the top 10 major modern languages and writing systems (let's say, English, Spanish, Mandarin, Arabic, Hindi, French, Russian, Japanese etc).
No need. You're dealing with nuclear waste. Just draw a picture and provide it as a key. Show an image of a uranium atom with different colors or patterns for protons versus neutrons, then show the count of each in unary. Then give the name of the element in English or your choice of other languages. Use that name everywhere else. Include several copies of the key to minimize the risk of it being destroyed.
As for presentation, think laser cutting in a large block of metal. The larger the feature, the longer it will take to erode or corrode. Make it out of gold-plated bronze or something, and make each letter's size and cutting depth be measured in feet.
After every bug in my project you post a press release, discrediting the person who found the bug as some subversive agent, and explaining its uses of the bug in a positive light.
Unfortunately, most products these days don't obey the laws of supply and demand because of lack of competition, high cost of entry into the market, etc.
The most harmful part of tobacco is lead-210 and polonium-210 caused by the radioactive decay of phosphate-based fertilizers with uranium contamination. The nicotine is way, way farther down the list. Marijuana doesn't have that problem because less fertilizer is used. If marijuana were mass-farmed in the U.S., you'd probably have the exact same cancer risk.
Slashdot Mirror
Either way, there's nothing inherently preventing it, and if there's enough demand, someone will implement it.
Not true. Nearly two-thirds of the U.S. Senate are sharks.
Think positively. At least the GP didn't say "rain them in". When it comes to online forum grammar, I'd call that a small victory.
Not true. Linux has a NAT implementation for IPv6 already. There's nothing about IPv6 that inherently prevents NAT. It just isn't necessary in nearly as many places.
Probably because in practice, encapsulation is "good enough".
Only if you aren't using NAT. Besides, with service discovery and SLAAC, chances are you won't have to reconfigure anything anyway.
No more so than any other piece of OS-level code.
Ah, but people use cars very differently than they use power tools. Most people keep one battery on a rapid charger, then swap it out when the one they're using goes dead. That's potentially a very different usage model than plugging in your car every night and trickle-charging it over twelve hours or more. You'll probably see a much broader variation of usage patterns in automobiles, too, with some people driving ten miles a day, and others driving a hundred. Finally, cars have a *lot* of cells crammed into a tiny space, all being charged and discharged at once, which means it is also a completely different thermal environment than the one in which power tool batteries operate.
Folks can certainly speculate on how they'll behave long-term in cars based on lab behavior, but I've seen a lot of stuff that works in a lab, but falls apart in the real world. I don't want to be an early adopter of these things. In a few years, when the kinks are worked out, great. Until then, I view batteries with suspicion. :-)
All the laptops I've seen in the past six or seven years use LiPo packs, which as I understand it, is a direction the automakers would like to move in, for space reasons (hopefully after they improve the life expectancy). But point taken.
To some extent, yes, they do. To the best of my knowledge, all rechargeable battery technology exhibits capacity decay over time. The only question is whether they show significant loss of capacity after five years, ten years, twenty years, or some period of time that's long enough that nobody cares anymore. This, in turn, depends on not just the battery technology, but also on how you use it and how the car's charge circuitry was designed—deep discharges from long trips versus lots of very shallow discharges, continuous trickle charging versus letting the battery sag to 90% before you top it up, whether you always charge the battery or allow it to stay mostly discharged for a period of time (which promotes dendrite formation), etc. all play a role in how long a battery lasts.
As far as I can tell, we really have no idea how LiFePO4 is going to hold up in the real world; the sample size of LiFePO4 batteries that are more than a couple of years old is too small. But for older designs that use NiMH or older lithium ion chemistries, we know approximately how long they'll last, and it isn't pretty.
That change happened before television, back when the average politician spent (adjusted for inflation) single-digit millions of dollars when running for the presidency instead of single-digit billions.
And assuming they behave like laptop batteries, when the car is five years old, count on half of that.
It is probably worth pointing out that the vast majority of people with cataracts could dramatically improve their vision just by using N-acetylcarnosine eye drops daily for a few months. Cataract surgery should be reserved for only the most serious cases, and only when eye drop treatment has failed. Instead, surgery seems to be the default treatment in the U.S. And this is, in part, why medical care is so expensive here....
Mean instantaneous power would presumably be calculated by deciding on a sampling interval, determining the wattage at each interval, summing the sample values, and dividing by the number of samples. I mean, if you could somehow come up with a mathematical function, you could ostensibly use an integral, but here in the real world, we tend towards summation.
Move Washington D.C. to Texas. The hot air quota will be filled readily.
I think you're missing the point. Coal is rapidly becoming unwelcome, and natural gas is not viable in the long term, either. There's a limited supply of it, and contrary to what some people might have you believe by calling it "clean-burning", it still contributes to global warming, and even if it replaced other fossil fuels, we would still be producing an awful lot of CO2.
In the long term, we have to move to renewable energy. There is simply no other feasible alternative short of discovering oil on Mars (and even then, we will eventually run out). Having solutions in place that make renewable energy feasible as our sole means of providing power is the only way to future-proof our ability to provide power. Whether this project succeeds or fails is immaterial; the lessons learned are absolutely necessary, and we might as well start learning them now.
I think the core problem is not that the basic requirements change, but rather that some key aspects of development, such as UI design, are black holes. The requirement is a usable UI. However, if allowed to do so, the details will change at such a rate that they suck all the developer time away from everything else. "Ooh, could we make it mauve instead?" And maybe we should put this button over there instead of over here. If you don't nail down the design ahead of time and get proper buy-in from all the stakeholders, you're screwed. Iterative design results in design-by-committee unholiness—a product that satisfies no one and takes ten times as long to build.
No, you won't, because the waterfall model requires you to put everyone in a room and not let them leave until they have agreed to a set of requirements that they can live with. And anything that didn't get hammered out at that initial meeting, unless it really is absolutely a show-stopper, becomes a "we'll take a look at it for version 2.0" feature.
No, if you can't get it mostly right the first time, then your software architect skills are not up to the task of writing that particular piece of software. Thus, the right way to approach the problem is to hire a software architect who can get it mostly right the first time.
Failure to integrate is an avoidable problem; you should have been doing that all along. What I've seen is that you get 90% of the way very quickly, but then because of the lack of sufficient design and architecture planning up front, you end up with a design in which the remaining 10% takes 90% of the time.
In other words, it's an interesting way to build a prototype that you never intend to ship, so long as you understand that the next thing you should do is throw it away, design a proper architecture based on the lessons you learned along the way, and borrow only fragments of the code from the prototype as you build the final design using a more traditional process. If you try to evolve the prototype into the final design, you're in for a world of hurt.
Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.
Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.
Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole. This problem can also plague the architecture underneath if you aren't careful.
Depends largely on how dense and pedestrian-friendly the city is. In San Francisco, New York City, or Boston, that would be true. On the flip side, in the south half of the San Francisco Bay Area, it is continuous city, and I see maybe one or two pedestrians every couple of weeks unless I'm on minor roads.
Not if they're designed right, they won't. With a fully autonomous system, the vehicles would by default prefer major roads over minor roads, and those major roads would often have pedestrian bridges. However, when a pedestrian needs to cross a road that lacks such bridges, the pedestrian pressing a button would change that preference.
Any vehicles within a span beginning a block away and extending to three blocks away would shift over one road in either direction. So as soon as the nearest block worth of traffic in either direction clears the intersection, the road would be clear for pedestrians for a period of time, but the cars themselves would not stop, or even slow down.
There would still have to be some sort of traffic lights for those vehicles. Preferably all-ways-red until a vehicle or bicycle sits on the sensor for a period of time. Incidentally, bicycles are potentially a concern because of their tendency to blow through stop signs and traffic lights....
In that case, put it in a deep mine, and set up a doomsday switch that nukes the tunnel if civilization falls. By the time civilization gets back to the point where it is capable of mining the stuff again, they'll also be advanced enough to recognize the dangers.
I'm not 100% clear on what this hack does. Are they:
Or some combination of the above?
In a cave? There's no wind, and little to no groundwater. After all, those are the usual criteria for selecting the locations of these dumps in the first place.
No need. You're dealing with nuclear waste. Just draw a picture and provide it as a key. Show an image of a uranium atom with different colors or patterns for protons versus neutrons, then show the count of each in unary. Then give the name of the element in English or your choice of other languages. Use that name everywhere else. Include several copies of the key to minimize the risk of it being destroyed.
As for presentation, think laser cutting in a large block of metal. The larger the feature, the longer it will take to erode or corrode. Make it out of gold-plated bronze or something, and make each letter's size and cutting depth be measured in feet.
Ah. So you work for a three-letter agency, then?
Unfortunately, most products these days don't obey the laws of supply and demand because of lack of competition, high cost of entry into the market, etc.
The most harmful part of tobacco is lead-210 and polonium-210 caused by the radioactive decay of phosphate-based fertilizers with uranium contamination. The nicotine is way, way farther down the list. Marijuana doesn't have that problem because less fertilizer is used. If marijuana were mass-farmed in the U.S., you'd probably have the exact same cancer risk.