Well, this is the problem with human language: humans use it.
Words mean whatever most people agree they mean, and regrettably most people are sloppy thinkers. Shortly after a word like, oh say "broadband", enters the language with a wonderfully sharp meaning that is immediately dulled the instant the masses take it up.
This leaves the more precise-minded of us in a lexicographic position analogous to a carpenter attempting to carve a dovetail joint with a stick of butter.
That's assuming the "wild west energy" is something worth recapturing. Sure, a lot of people struck it rich in the dot com boom, but the lion's share of fortunes made were on the naivete and herd behavior of investors.
Well, to be fair machine learning addresses the most practical near-term applications of AI: replacing human judgment in classification, and extending that to volumes of data humans can't handle.
It may not be any kind of progress toward building something like Daneel Olivaw, but if that ever happens it probably won't happen because machines that are actually like humans are all that useful. It'll happen because someone wants to know if its possible.
I remember one interesting paper I read in my undergraduate psych course which made a lot of intuitive sense: the experiment showed that the likelihood of punishment had a much stronger effect on subject behavior than the severity of punishment. Think of how everyone slows down when they see a cop car parked on the side of the road, but they blithely sail past signs announcing that speeding fines are doubled.
Imagine a universe in which someone involved in the kind of fraud VW did was fined, say, 5% of his annual wages -- a mere slap on the wrist compared to jail time -- but everyone believed that if you did tried it you'd be caught. On other hand, imagine a universe where the punishment was life in prison, but nobody believed anyone would ever get caught. Which universe has the most fraud?
I think we understand this with respect to our own behavior, and yet somehow when a problem like this comes up, we turn to "make the punishment worse" rather than "make the punishment certain." Because it's *easy* to make punishments more severe. It's hard to catch people, bring them to face justice, and successfully try them. But that's what we've got to do.
What is the basis for your doubt? I find it interesting that you cite your personal doubt as if it actually proves something.
Doubt doesn't prove anything. You find people who doubt literally anything. There are people who doubt the moon landing was real, or that the Earth is spherical. And what sustains them is that they find other people who have the same doubts, and they take that somehow as confirmation.
So Google sets up an auction in which bidders compete to pay Google the most money. Then Google enters the auction as both the seller and also as a bidder?
Am I missing something here? Or is Google actually proposing something you wouldn't have to be stupid to believe might work?
You as a driver aren't entirely at their mercy. You can pay attention and avoid them in all but the most extreme circumstances.
True, but you have nothing to worry about flying except in the most extreme circumstances. Are extreme circumstances so much rarer driving than flying?
Here's another problem I have with this way of looking at things -- people always picture themselves as drivers as they are on their best days. On his best days, under ideal circumstances, even an average driver can do quite impressive feats of emergency danger-avoidance. You have to picture yourself on a really bad day, because that's where most of the statistical risk is. A day when you didn't sleep the night before; and things have you angry and distracted, and maybe the road conditions are unusually bad. Even if it's one day in ten, that's the day you have to worry about because it represents the bulk of your risk exposure.
Ultimately the problem with "being in control" starts with the illusion of being in control of yourself. Consistent self-possession, self-discipline, and control of your emotions is a rare, rare thing. Yet we all picture ourselves that way, because even the most mediocre of us are that way -- on our very best days.
That's why I prefer looking at statistics than what I *believe* I can do. It avoids the judgment-corrupting effects of self-flattery.
By that logic people would be terrified to take a taxi or an Uber. And you really don't have control if some drunk in the oncoming lane swerves into yours; your fate is up to pure luck.
The notion of "control" I think is just rationalizing familiarity bias.
Engineers tend to think statistically -- which is a good thing. But it can produce judgments which are contrary to common intuition. That's because intuition is, from an engineering standpoint, crap.
Take automobiles. Three thousand Americans die annually in cars -- that's like a 9/11 attack every year. Plus car accidents produce a bountiful annual crop of disfigurations and crippling injuries. Yet nobody is concerned about getting in a car. Planes on the other hand are much safer. Now as an engineer trained to use numbers as your yardstick, the natural way of thinking is this: "Since cars are acceptably safe to the public, if I can get the deaths/mile figures for airplanes down to the same level my job is done." Except that plane failures are often spectacularly horrific. People are naturally terrified of them. It's common sense to be afraid of something that moves at hundreds of mile per hour thousands of feet in the air.
So people demand very high levels of safety for aviation, which drives the cost of air travel up. OK, then; that means rationally they should also want the same deal for automobiles, which are by every measure much more dangerous. Except no, every time someone proposes making safety improvements people resist the cost, even though on a dollar per life saved basis the make much more sense than trying to make airliners even safer.
Conclusion: the natural human emotional response to risk and cost is hopelessly borked.
Now the Hyperloop is a novel form of transportation, and our bias against novelty when it comes to fear means that people will demand it be designed to be much safer than air travel even. And by design it probably is. But given the physical nature of the thing, lurking out on the tail end of the probability curve there are no doubt potential events of spectacular carnage. But they are so unlikely that given the number of people who are expected to ride the system it makes no sense.
I don't know specifically what those scenarios are; I'm not a Hyperloop engineer. But if they do exist it may be that I'm literally better off knowing.
Whatever model you choose, make it easy for the customer to spend their money with you.
Here's a useful trick that I learned. To cut down on contracting costs with larger institutional customers:: use task order contracts. A task order contract is a blanket contract for quantity of future services the customer will request at his own discretion. This solves the problem that there are many times the customer needs a little bit of your time but it's really impractical to contract for $100-$1000 of work. Without such a thing you either end up helping them for free, or they go without your services. Either way you don't get paid.
The contract looks like this: (1) I agree to provide you with the following services (development, support, training whatever) at $200/hour (for example), billed in fifteen minute (for example) increments.
(2) You name which of your employees can authorize a task.
(3) The maximum cost of a task will be $1000 (for example); if I think the task will cost more than that we will contract for it separately.
(4) The total amount covered under this contract (will be necessary in many cases to specify this) will be $20,000 (for example) and the contract will last until $20,000 have been spent (or until next October, again for example).
(5) Blah blah blah boilerplate that every contract has to have and which makes writing small contracts a financial waste of time.
(7) If you don't like my work you can go elsewhere and you really aren't out anything; on the other hand if you want a guarantee of my availability or response time to a query you will have to pay me a modest retainer.
So the way this works is the customer really wants a report to show such-and-so. He calls you up and you reckon you can do it in ten minutes, plus ten for walking him through installing the changes. So you say, "I can do this for $100." Now if the authorized person thinks this is worth $100, you do it and send them a bill. There is no formal contracting or negotiation required other than go/no go.
The way this *really* works is that since all the tedious and troublesome aspects of agreeing to spend $100 with you are already taken care of, your customers will be included to do it. $50 or $100 here and there doesn't seem like much, but if it's easy to get those little things add up to a lot of money.
on the nature of your customer and the type of software. When you talk about 'business models', before you get into any kind of complicated strategy, the important thing to fix in your mind is that you have to answer this question: where is the cash going to come from?
Let's say your software is a version of Tetris. In that case you don't have many places to get cash from. What you'd do is to find sources of revenue that were so small that it really isn't worthy anyone's time to download the source code from github and build it themselves. Put it in the app store and charge $0.99, or throw up an occasional ad. Just avoid being too greedy, and people will be OK with the bargain. And make sure the app is relatively bug-free, because people will simply stop using it if it frustrates them and there goes your ad revenue.
Tetris represents one end of the spectrum along several dimensions: it is simple in concept and use; it is as non-critical as any app can be. Now I spent a decade as a lead developer in a small company with a product that was the exact opposite ends of the spectra. It was highly complex, took training to operate and administer; had many, many components to install and configure, and was mission critical. This software happened to be proprietary (not my choice, at the time many of our customers had "no open source" policies, strange as that may sound), but the practicalities from the customer perspective would have been the same either way.
License fees were only a tiny fraction of our revenues; in order of size our revenue streams were (write this down): day-to-day technical support, on-site installation and training, software customizations, hardware sales, license fees (in a distant fifth), and finally advanced training. From a revenue standpoint we probably might as well have been open source. There is one thing that being proprietary protected us from: competition. You will have to consider the question of why your customers will turn to you when they could in theory turn to anyone. Competition from other developers is the single biggest problem for any open source business model.
So on either end of the complexity or mission-criticality scale, to make money with open source you've got to be the most convenient way of getting things done. For simple apps, keep them cheap and reliable. For complex apps, you have to sell yourself, and that means being pleasant and professional. If you build a team, don't fill it entirely with grouchy genius slobs; make sure you have people on the team who are young, attractive, and personable too. If you've never tried it, you'll be amazed. If it's just you, well you might not have much to work with, but you should spruce yourself up a bit. Maybe not a suit -- customers will see that as phony if you're not the type -- but maybe throwing a blazer over your jeans and t- shirt will hit the right note.
As for technology, if you have invested a lot of your life in developing a product you'll want to avoid becoming commodity (i.e., easily replaceable) labor after it's finished. That means you need to select your platforms carefully. Avoid the latest "golden hammers" that everyone's learning. Instead look for good projects that make your job easy and have enough of a user base that support won't go away overnight. Think "Scala" rather than "Node.js". Again -- this is from the developer's standpoint. If you're a customer paying someone to develop a system that you will open source, think "Node.js" rather than "Scala".
Well, maybe having more realistic expectations might be a good start.
I think the people who voted for Donald Trump actually got what they voted for: an outsider not steeped in the Washington way of doing things who had little personal or political connection to the people down there. What they went wrong wasn't in judging Trump's character, but in judging what such a character would be able to accomplish.
The problem with electing someone who is untainted with the Establishment is that the establishment are the people who actually know how to run things. If you send in a complete outsider with the idea that will shake things up, you end up with Establishment types running things and the President not really understanding what they're up to.
Now as to election *fixing*; the problem is people trusting politicians to cheat on their behalf. That's extremely unrealistic; like marrying someone whose marriage you broke up and expecting them to be faithful to you. Protections for people you dislike are protections for you, too.
It helps if you think of elections, not as an exercise in self-expression, but an exercise in political power.
You don't have to like or even approve of someone you vote for. It's *nice* when you can, but the point is to shape your future in the most advantageous way possible.
Only if they had an incompetent lawyer draw up the contracts.
When you negotiate a contract, your lawyer tries to give you as many outs as possible while preventing the other side from being able to weasel out. When you are setting up a contract with consumers who don't have benefit of counsel, basically the only thing that restrains you is your public reputation, and in some cases the state attorney general.
Judging from her profile, she had 11 years working in IT positions starting at HP in 2002 and including two banks and a major credit card processing company.
It is not inconceivable that a person with such a background would acquire the necessary skills on the job; back in 2002 there weren't many (if any) degree programs in IT security, and to be frank a CS degree doesn't really prepare you to do security work much better than a music degree. So would you rather hire a recent grad with the right degree for this position, or someone who'd been working in the field since before the degree was commonly offered?
On the other hand, Equifax just had a major security screw-up and did not handle it very professionally. So while nothing in her background precludes her being qualified for the job, her actual job performance calls her competence into question.
Slashdot Mirror
Well, this is the problem with human language: humans use it.
Words mean whatever most people agree they mean, and regrettably most people are sloppy thinkers. Shortly after a word like, oh say "broadband", enters the language with a wonderfully sharp meaning that is immediately dulled the instant the masses take it up.
This leaves the more precise-minded of us in a lexicographic position analogous to a carpenter attempting to carve a dovetail joint with a stick of butter.
Sensitivity to insult isn't exactly new, you know. What's different is the power of harassment to follow you around.
That's assuming the "wild west energy" is something worth recapturing. Sure, a lot of people struck it rich in the dot com boom, but the lion's share of fortunes made were on the naivete and herd behavior of investors.
Far from oblique, as was my reference to TNG Season 2 Episode 21.
Well, to be fair machine learning addresses the most practical near-term applications of AI: replacing human judgment in classification, and extending that to volumes of data humans can't handle.
It may not be any kind of progress toward building something like Daneel Olivaw, but if that ever happens it probably won't happen because machines that are actually like humans are all that useful. It'll happen because someone wants to know if its possible.
Ha! I'm playing for a draw.
I remember one interesting paper I read in my undergraduate psych course which made a lot of intuitive sense: the experiment showed that the likelihood of punishment had a much stronger effect on subject behavior than the severity of punishment. Think of how everyone slows down when they see a cop car parked on the side of the road, but they blithely sail past signs announcing that speeding fines are doubled.
Imagine a universe in which someone involved in the kind of fraud VW did was fined, say, 5% of his annual wages -- a mere slap on the wrist compared to jail time -- but everyone believed that if you did tried it you'd be caught. On other hand, imagine a universe where the punishment was life in prison, but nobody believed anyone would ever get caught. Which universe has the most fraud?
I think we understand this with respect to our own behavior, and yet somehow when a problem like this comes up, we turn to "make the punishment worse" rather than "make the punishment certain." Because it's *easy* to make punishments more severe. It's hard to catch people, bring them to face justice, and successfully try them. But that's what we've got to do.
In the short run, yes.
What is the basis for your doubt? I find it interesting that you cite your personal doubt as if it actually proves something.
Doubt doesn't prove anything. You find people who doubt literally anything. There are people who doubt the moon landing was real, or that the Earth is spherical. And what sustains them is that they find other people who have the same doubts, and they take that somehow as confirmation.
"If transmissions were being monitored during battle, no uncoded messages were to be transmitted on an open channel."
And yet even though they were aware enough to draft a regulation, their mobile communicators didn't come with a secure messaging system either.
So Google sets up an auction in which bidders compete to pay Google the most money. Then Google enters the auction as both the seller and also as a bidder?
Am I missing something here? Or is Google actually proposing something you wouldn't have to be stupid to believe might work?
Hmm, let's compare:
* 700 MPHs vs 70 MPHs -- the speed is an order of magnitude in difference, and
* traveling at a height of 30,000 feet vs surface level,
Gee, ya think there _might_ be some rational fear to flying !?
Nope.
You as a driver aren't entirely at their mercy. You can pay attention and avoid them in all but the most extreme circumstances.
True, but you have nothing to worry about flying except in the most extreme circumstances. Are extreme circumstances so much rarer driving than flying?
Here's another problem I have with this way of looking at things -- people always picture themselves as drivers as they are on their best days. On his best days, under ideal circumstances, even an average driver can do quite impressive feats of emergency danger-avoidance. You have to picture yourself on a really bad day, because that's where most of the statistical risk is. A day when you didn't sleep the night before; and things have you angry and distracted, and maybe the road conditions are unusually bad. Even if it's one day in ten, that's the day you have to worry about because it represents the bulk of your risk exposure.
Ultimately the problem with "being in control" starts with the illusion of being in control of yourself. Consistent self-possession, self-discipline, and control of your emotions is a rare, rare thing. Yet we all picture ourselves that way, because even the most mediocre of us are that way -- on our very best days.
That's why I prefer looking at statistics than what I *believe* I can do. It avoids the judgment-corrupting effects of self-flattery.
By that logic people would be terrified to take a taxi or an Uber. And you really don't have control if some drunk in the oncoming lane swerves into yours; your fate is up to pure luck.
The notion of "control" I think is just rationalizing familiarity bias.
Engineers tend to think statistically -- which is a good thing. But it can produce judgments which are contrary to common intuition. That's because intuition is, from an engineering standpoint, crap.
Take automobiles. Three thousand Americans die annually in cars -- that's like a 9/11 attack every year. Plus car accidents produce a bountiful annual crop of disfigurations and crippling injuries. Yet nobody is concerned about getting in a car. Planes on the other hand are much safer. Now as an engineer trained to use numbers as your yardstick, the natural way of thinking is this: "Since cars are acceptably safe to the public, if I can get the deaths/mile figures for airplanes down to the same level my job is done." Except that plane failures are often spectacularly horrific. People are naturally terrified of them. It's common sense to be afraid of something that moves at hundreds of mile per hour thousands of feet in the air.
So people demand very high levels of safety for aviation, which drives the cost of air travel up. OK, then; that means rationally they should also want the same deal for automobiles, which are by every measure much more dangerous. Except no, every time someone proposes making safety improvements people resist the cost, even though on a dollar per life saved basis the make much more sense than trying to make airliners even safer.
Conclusion: the natural human emotional response to risk and cost is hopelessly borked.
Now the Hyperloop is a novel form of transportation, and our bias against novelty when it comes to fear means that people will demand it be designed to be much safer than air travel even. And by design it probably is. But given the physical nature of the thing, lurking out on the tail end of the probability curve there are no doubt potential events of spectacular carnage. But they are so unlikely that given the number of people who are expected to ride the system it makes no sense.
I don't know specifically what those scenarios are; I'm not a Hyperloop engineer. But if they do exist it may be that I'm literally better off knowing.
Whatever model you choose, make it easy for the customer to spend their money with you.
Here's a useful trick that I learned. To cut down on contracting costs with larger institutional customers:: use task order contracts. A task order contract is a blanket contract for quantity of future services the customer will request at his own discretion. This solves the problem that there are many times the customer needs a little bit of your time but it's really impractical to contract for $100-$1000 of work. Without such a thing you either end up helping them for free, or they go without your services. Either way you don't get paid.
The contract looks like this:
(1) I agree to provide you with the following services (development, support, training whatever) at $200/hour (for example), billed in fifteen minute (for example) increments.
(2) You name which of your employees can authorize a task.
(3) The maximum cost of a task will be $1000 (for example); if I think the task will cost more than that we will contract for it separately.
(4) The total amount covered under this contract (will be necessary in many cases to specify this) will be $20,000 (for example) and the contract will last until $20,000 have been spent (or until next October, again for example).
(5) Blah blah blah boilerplate that every contract has to have and which makes writing small contracts a financial waste of time.
(7) If you don't like my work you can go elsewhere and you really aren't out anything; on the other hand if you want a guarantee of my availability or response time to a query you will have to pay me a modest retainer.
So the way this works is the customer really wants a report to show such-and-so. He calls you up and you reckon you can do it in ten minutes, plus ten for walking him through installing the changes. So you say, "I can do this for $100." Now if the authorized person thinks this is worth $100, you do it and send them a bill. There is no formal contracting or negotiation required other than go/no go.
The way this *really* works is that since all the tedious and troublesome aspects of agreeing to spend $100 with you are already taken care of, your customers will be included to do it. $50 or $100 here and there doesn't seem like much, but if it's easy to get those little things add up to a lot of money.
The scenario you spin posits that you're working for an incompetent. Which is a common use case, I grant you, but not universal.
on the nature of your customer and the type of software. When you talk about 'business models', before you get into any kind of complicated strategy, the important thing to fix in your mind is that you have to answer this question: where is the cash going to come from?
Let's say your software is a version of Tetris. In that case you don't have many places to get cash from. What you'd do is to find sources of revenue that were so small that it really isn't worthy anyone's time to download the source code from github and build it themselves. Put it in the app store and charge $0.99, or throw up an occasional ad. Just avoid being too greedy, and people will be OK with the bargain. And make sure the app is relatively bug-free, because people will simply stop using it if it frustrates them and there goes your ad revenue.
Tetris represents one end of the spectrum along several dimensions: it is simple in concept and use; it is as non-critical as any app can be. Now I spent a decade as a lead developer in a small company with a product that was the exact opposite ends of the spectra. It was highly complex, took training to operate and administer; had many, many components to install and configure, and was mission critical. This software happened to be proprietary (not my choice, at the time many of our customers had "no open source" policies, strange as that may sound), but the practicalities from the customer perspective would have been the same either way.
License fees were only a tiny fraction of our revenues; in order of size our revenue streams were (write this down): day-to-day technical support, on-site installation and training, software customizations, hardware sales, license fees (in a distant fifth), and finally advanced training. From a revenue standpoint we probably might as well have been open source. There is one thing that being proprietary protected us from: competition. You will have to consider the question of why your customers will turn to you when they could in theory turn to anyone. Competition from other developers is the single biggest problem for any open source business model.
So on either end of the complexity or mission-criticality scale, to make money with open source you've got to be the most convenient way of getting things done. For simple apps, keep them cheap and reliable. For complex apps, you have to sell yourself, and that means being pleasant and professional. If you build a team, don't fill it entirely with grouchy genius slobs; make sure you have people on the team who are young, attractive, and personable too. If you've never tried it, you'll be amazed. If it's just you, well you might not have much to work with, but you should spruce yourself up a bit. Maybe not a suit -- customers will see that as phony if you're not the type -- but maybe throwing a blazer over your jeans and t- shirt will hit the right note.
As for technology, if you have invested a lot of your life in developing a product you'll want to avoid becoming commodity (i.e., easily replaceable) labor after it's finished. That means you need to select your platforms carefully. Avoid the latest "golden hammers" that everyone's learning. Instead look for good projects that make your job easy and have enough of a user base that support won't go away overnight. Think "Scala" rather than "Node.js". Again -- this is from the developer's standpoint. If you're a customer paying someone to develop a system that you will open source, think "Node.js" rather than "Scala".
Well, maybe having more realistic expectations might be a good start.
I think the people who voted for Donald Trump actually got what they voted for: an outsider not steeped in the Washington way of doing things who had little personal or political connection to the people down there. What they went wrong wasn't in judging Trump's character, but in judging what such a character would be able to accomplish.
The problem with electing someone who is untainted with the Establishment is that the establishment are the people who actually know how to run things. If you send in a complete outsider with the idea that will shake things up, you end up with Establishment types running things and the President not really understanding what they're up to.
Now as to election *fixing*; the problem is people trusting politicians to cheat on their behalf. That's extremely unrealistic; like marrying someone whose marriage you broke up and expecting them to be faithful to you. Protections for people you dislike are protections for you, too.
It helps if you think of elections, not as an exercise in self-expression, but an exercise in political power.
You don't have to like or even approve of someone you vote for. It's *nice* when you can, but the point is to shape your future in the most advantageous way possible.
Actually you may be garbling the story that Meuller *might* have Trump's tax returns.
Nobody but the IRS has seen any of Trump's recent tax returns.
did it really take a study and five papers to tell us that eating garbage food is bad for us?
No, but the study doesn't tell us that bad diet is bad; it quantifies how bad it is and ranks it against other risk factors.
Only if they had an incompetent lawyer draw up the contracts.
When you negotiate a contract, your lawyer tries to give you as many outs as possible while preventing the other side from being able to weasel out. When you are setting up a contract with consumers who don't have benefit of counsel, basically the only thing that restrains you is your public reputation, and in some cases the state attorney general.
Judging from her profile, she had 11 years working in IT positions starting at HP in 2002 and including two banks and a major credit card processing company.
It is not inconceivable that a person with such a background would acquire the necessary skills on the job; back in 2002 there weren't many (if any) degree programs in IT security, and to be frank a CS degree doesn't really prepare you to do security work much better than a music degree. So would you rather hire a recent grad with the right degree for this position, or someone who'd been working in the field since before the degree was commonly offered?
On the other hand, Equifax just had a major security screw-up and did not handle it very professionally. So while nothing in her background precludes her being qualified for the job, her actual job performance calls her competence into question.
I take your point, but if your recipe called for 1/3 of a tablespoon of cinnamon, I'd call that a dodgy recipe.