We need big airplanes today because: 1) they are more efficient fuel wise per passenger, 2) they need fewer pilots per passenger, and 3) gate and landing slot limitations.
1) is not relevant here.
2) relevant only if it needs a pilot
3) only relevant at big airports.
As for expensive, capital cost favor the small planes.
This plane seats 9: the capital cost is $333k/passenger. By comparison, the popular 737-800 cost $100M and seats 189 at $529k/passenger. A 9 seat Cessna is $2M or $222k/passenger and has a range of 1232mi.
This plane would be immediately competitive with the Cessna.
If these can be operated without pilots, they will take a huge chunk of the market. The whole hub and spoke system is passenger hostile, but forced by 1) and 2) above.
That is, your passenger actually wanted to go from Bristol to Glasgow: any time spent in London or Edinburgh is wasted.
During all the ages before Malthus, and for well over a century afterward, populations the world over remained bound by the nearly fixed productivity of the land,
This is a common opinion, but it is flat wrong-- and if it were true it would be misleading.
It's misleading because producing food is only part of the story. Generally, food needs to be stored. During storage, it must protected from rot and vermin. There were many storage techniques known to the people of Malthus's day which were not known in "all the ages". And, food sometimes needs to be transported. The canals and ships of Malthus's day made this more efficient than it had ever been; though no nearly so efficient as it would soon be.
But production was "nearly fixed" if you ignore capital and technical improvements like better plows and irrigation and better crops (can you say potato) and better animal breeds and better crop rotations. That is, it wasn't fixed at all.
Granted, the 1800s would be the better still. And the 1900s. And the 2000s (so far anyway).
Finally, even if Malthus had been right about food production, we reached worldwide peak baby 30 years ago. You picked the wrong century to freak out in.
If there is a problem, it's not too/many/ people. People are a feature, not a bug.
I'm guessing wrt the latter, Torvalds learnt american english and so never found out that in british english "git" is a somewhat unpleasent insult.
Torvalds knew the meaning of git at release time and quipped:
"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
If you think that then you've never used systemd and not read the manual either
I didn't want to read your damn manual. I had a init system-- it never gave lip and I could customize it when I wanted to.
Now my Debian systems have systemd and I've spent too much time reading the damn manual for a program that ostensibly solves problems I never had.
I for one welcome our new Devuan overlords.
If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that.
Seeing this old quote always makes me laugh---soon afterwards cars started having additional speed controls and putting them next to the windshield washer or on the steering wheel, next to the controls for the stereo.
The nerds at Ma Bell used to provide very high quality telephony; they were shocked and appalled when the market chose low quality low cost telephony. The medical transcription market has gone through the same change..
The documents, especially the ones used clinically, can suffer from lower quality of ASR and/or offshoring.. Also, in the old days, light editing was usually part of the process. This happens less in today's price obsessed market and sadly results in less readable reports.
On the other hand, today it's possible to get turn around times of 0 with document issues identified in real time by NLP. That is a really big improvement. (I don't know if Nuance has that, but if they don't, they will soon)
For what it's worth, Scala can compile with vanilla Java. You can't have them both in the same file, but you can have everything else, including mutual dependencies. Scala can use all existing libs with no modifications. "Effective Java" is most of the way to Scala.
Scala is a superset of Java in a way Jython is not because Scala has all the features of Java in a way Jython does not. Annotations, static typing, main methods, hash codes and many more are still there from Java. Admittedly, some misfeatures were left on the cutting room floor--- primitive types, special syntax for arrays, call-side variance, etc.
This is best understood in the context of mutability/immutability.
Mutable structures---like arrays--- have problems with ownership and thread safety. Before you pass it to a method you must copy it, if the method might change it. If someone passes you an array, you may need to make a copy before working with it. Also, mutable structures must be invariant for type safety.
Immutable structures solve these problems but they are more complicated. Consider the immutable vectors from Clojure or Scala--- they have an array-like api but are immutable. They are implemented as wide trees, so a logical read or write may take 5 or 6 actual read or writes.
Immutable structures are easier to reason about. And defensive copies and monitors are not required for bug-free operation. But there is a trade off.
A copy-on-write array can have good read performance. The sticky part is the write, which is O(N). If writes are infrequent or can be batched, this may be ok. Java's String class has copy-on-write semantics.
But I'll just note that reluctance to follow FOIA requests was not unreasonable.
Are you trolling? FOIA requests aren't for your friends--- friends just ask. They are for your critics. Most people think their critics are mistaken and unreasonable. So almost all FOIA requests look unreasonable to the person who has to respond. Reasonable or not, they are the law.
In the case of the CRU, they where figuring out what excuses to use before they got the first FOIA request. So, their use of this complaint doesn't look just misguided, it looks disingenuous.
Historically speaking, the Church/Islam encouraged science purely because they had money to support scientists. There was no such thing as grants or state funding back then. The Church was a big bank. This was not because of anything inherent to Religion that encourages finding objective fact.
Nothing inherent to religion encourages finding objective fact. But Christianity has always been very interested in objective fact.
It's not an accident that science was born in Christendom. Christianity provided the motive--- to understand God's world. Christianity provided the means--- the material wealth of a machine culture and, as you say, some direct funding. But more importantly, Christianity provided the faith in reason and the faith in the existence of objective truth itself. Finally, Christianity provided the opportunity--- many of the early scientists were clerics and almost all were devout believers. Christianity invented the university, for God's sake.
You can think Christianity was framed, if that is something you wish to believe.
I'll buy that: the name on a mailing label or shipment may be a different concept than the primary name associated with the account. If so, its wrong to conflate them.
The meta-rule in computer science is "Once And Only Once". In the database world this is called Normalization.
Normalization holds that there should be exactly one definitive place for each bit of data. For example, customer's name should be in her row in the Customer table. It should not be in 5 different tables and in the Orders table once per order. If it is in 5 different tables sooner or later they will get out of sync. That is bad. If the database is large and important it is very bad indeed.
Backups, datawarehouse etc don't count here as definitive places, because while there may circumstances that will make them definitive, in the normal course of events they are not.
Denormalization is sometimes done to improve speed, but it is dangerous.
Caches and replication can also be dangerous if they can get out of sync, or worse, if they muddy the concept of what is the definitive version of the data.
Yeah, he thinks security bugs are just like regular bugs. But he's wrong. Most bugs don't bite most users--- the ones that don't can be ignored. Very few people can ignore security bugs--- they bite everyone.
The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.
Slashdot Mirror
Don't gripe, just switch. Devuan is your friend.
We need big airplanes today because: 1) they are more efficient fuel wise per passenger, 2) they need fewer pilots per passenger, and 3) gate and landing slot limitations. 1) is not relevant here. 2) relevant only if it needs a pilot 3) only relevant at big airports. As for expensive, capital cost favor the small planes. This plane seats 9: the capital cost is $333k/passenger. By comparison, the popular 737-800 cost $100M and seats 189 at $529k/passenger. A 9 seat Cessna is $2M or $222k/passenger and has a range of 1232mi. This plane would be immediately competitive with the Cessna. If these can be operated without pilots, they will take a huge chunk of the market. The whole hub and spoke system is passenger hostile, but forced by 1) and 2) above. That is, your passenger actually wanted to go from Bristol to Glasgow: any time spent in London or Edinburgh is wasted.
Yeah, it sounds like the rallying cry for Right Thinking People which precedes bad luck.
True capitalism assumes perfect information in the market to determine a price. Unfortunately, we live in a world of imperfect information.
Fortunately, the other systems don't need perfect information to be perfect. Oh wait, they do.
A free market may not be "perfect" but it's a better solution to the calculation problem than the alternatives.
Some of these cases may be heart attacks, but I suspect most are actually just female hysteria.
Most chest pain in the ER turns out to be non-serious.
Still, it's to be careful as the serious cases are doozies.
During all the ages before Malthus, and for well over a century afterward, populations the world over remained bound by the nearly fixed productivity of the land,
This is a common opinion, but it is flat wrong-- and if it were true it would be misleading.
It's misleading because producing food is only part of the story. Generally, food needs to be stored. During storage, it must protected from rot and vermin. There were many storage techniques known to the people of Malthus's day which were not known in "all the ages". And, food sometimes needs to be transported. The canals and ships of Malthus's day made this more efficient than it had ever been; though no nearly so efficient as it would soon be.
But production was "nearly fixed" if you ignore capital and technical improvements like better plows and irrigation and better crops (can you say potato) and better animal breeds and better crop rotations. That is, it wasn't fixed at all.
Granted, the 1800s would be the better still. And the 1900s. And the 2000s (so far anyway).
Finally, even if Malthus had been right about food production, we reached worldwide peak baby 30 years ago. You picked the wrong century to freak out in.
If there is a problem, it's not too /many/ people. People are a feature, not a bug.
If it goes down, they'll get a financial education!
Google, for instance, is an advertising company that uses AI.
I'm guessing wrt the latter, Torvalds learnt american english and so never found out that in british english "git" is a somewhat unpleasent insult.
Torvalds knew the meaning of git at release time and quipped: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
If you think that then you've never used systemd and not read the manual either
I didn't want to read your damn manual. I had a init system-- it never gave lip and I could customize it when I wanted to. Now my Debian systems have systemd and I've spent too much time reading the damn manual for a program that ostensibly solves problems I never had. I for one welcome our new Devuan overlords.
If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that.
Seeing this old quote always makes me laugh---soon afterwards cars started having additional speed controls and putting them next to the windshield washer or on the steering wheel, next to the controls for the stereo.
It can, actually. It alternatively compiles to JavaScript.
The nerds at Ma Bell used to provide very high quality telephony; they were shocked and appalled when the market chose low quality low cost telephony. The medical transcription market has gone through the same change..
The documents, especially the ones used clinically, can suffer from lower quality of ASR and/or offshoring.. Also, in the old days, light editing was usually part of the process. This happens less in today's price obsessed market and sadly results in less readable reports.
On the other hand, today it's possible to get turn around times of 0 with document issues identified in real time by NLP. That is a really big improvement. (I don't know if Nuance has that, but if they don't, they will soon)
As you probably guessed, I write spell checkers.
My code wants to be antropomorhized!
http://www.psmag.com/navigation/health-and-behavior/truth-wont-admit-drinking-healthy-87891/
Even women who drink 6 drinks per day have lower overall mortality than teetotalers.
Uhm, according to Paul we can, must and should "Roll Back the Empire". He's about as dove-like as they come.
He's about a mile left of Obama on defense.
For what it's worth, Scala can compile with vanilla Java. You can't have them both in the same file, but you can have everything else, including mutual dependencies. Scala can use all existing libs with no modifications. "Effective Java" is most of the way to Scala.
Scala is a superset of Java in a way Jython is not because Scala has all the features of Java in a way Jython does not. Annotations, static typing, main methods, hash codes and many more are still there from Java. Admittedly, some misfeatures were left on the cutting room floor--- primitive types, special syntax for arrays, call-side variance, etc.
This is best understood in the context of mutability/immutability.
Mutable structures---like arrays--- have problems with ownership and thread safety. Before you pass it to a method you must copy it, if the method might change it. If someone passes you an array, you may need to make a copy before working with it. Also, mutable structures must be invariant for type safety.
Immutable structures solve these problems but they are more complicated. Consider the immutable vectors from Clojure or Scala--- they have an array-like api but are immutable. They are implemented as wide trees, so a logical read or write may take 5 or 6 actual read or writes.
Immutable structures are easier to reason about. And defensive copies and monitors are not required for bug-free operation. But there is a trade off.
A copy-on-write array can have good read performance. The sticky part is the write, which is O(N). If writes are infrequent or can be batched, this may be ok. Java's String class has copy-on-write semantics.
ubuntu is to debian as firefox is to gecko
Debian has iceweasel, not firefox nor gecko, you insensitive clod.
But I'll just note that reluctance to follow FOIA requests was not unreasonable.
Are you trolling? FOIA requests aren't for your friends--- friends just ask. They are for your critics. Most people think their critics are mistaken and unreasonable. So almost all FOIA requests look unreasonable to the person who has to respond. Reasonable or not, they are the law.
In the case of the CRU, they where figuring out what excuses to use before they got the first FOIA request. So, their use of this complaint doesn't look just misguided, it looks disingenuous.
Historically speaking, the Church/Islam encouraged science purely because they had money to support scientists. There was no such thing as grants or state funding back then. The Church was a big bank. This was not because of anything inherent to Religion that encourages finding objective fact.
Nothing inherent to religion encourages finding objective fact. But Christianity has always been very interested in objective fact.
It's not an accident that science was born in Christendom. Christianity provided the motive--- to understand God's world. Christianity provided the means--- the material wealth of a machine culture and, as you say, some direct funding. But more importantly, Christianity provided the faith in reason and the faith in the existence of objective truth itself. Finally, Christianity provided the opportunity--- many of the early scientists were clerics and almost all were devout believers. Christianity invented the university, for God's sake.
You can think Christianity was framed, if that is something you wish to believe.
I'll buy that: the name on a mailing label or shipment may be a different concept than the primary name associated with the account. If so, its wrong to conflate them.
The meta-rule in computer science is "Once And Only Once". In the database world this is called Normalization.
Normalization holds that there should be exactly one definitive place for each bit of data. For example, customer's name should be in her row in the Customer table. It should not be in 5 different tables and in the Orders table once per order. If it is in 5 different tables sooner or later they will get out of sync. That is bad. If the database is large and important it is very bad indeed.
Backups, datawarehouse etc don't count here as definitive places, because while there may circumstances that will make them definitive, in the normal course of events they are not.
Denormalization is sometimes done to improve speed, but it is dangerous.
Caches and replication can also be dangerous if they can get out of sync, or worse, if they muddy the concept of what is the definitive version of the data.
Yeah, he thinks security bugs are just like regular bugs. But he's wrong. Most bugs don't bite most users--- the ones that don't can be ignored. Very few people can ignore security bugs--- they bite everyone. The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.