You probably use PayPal even when you don't know you are using it. PayPal isn't just about peer to peer transactions. They also offer businesses credit card clearing services through PayFlow. Customers don't need a PayPal account to use it, and they don't even know they are using PayPal. They're a lot bigger than you think.
PayPal is much more than just peer-to-peer transactions. They offer businesses a credit card processing service called PayFlow, which is used by many large tech companies to collect customer payments. It's really not that unusual for merchants to have only one credit card processor.
If a ticket is a good--something you can own--then you absolutely should be able to buy and sell it as you please, and even scalpers have every right to do what they do.
If a ticket is more like a seat rental contract--not a possession, but an agreement--then it makes sense to only be able to buy from the ticket seller, and to make them non-transferrable. In this case, we have a situation like we have with the airlines, where sure, you can get your money back...well, a little bit of it anyway, and then only in the form of credit towards future flights, after a $100 trip change fee. We ALL love how the airlines do things, right??? And that's how we want concerts to be? I don't think so.
There's no really good answer. But I don't think it's selfish to want to be able to resell a ticket when you can't use it.
That's great, until I have something come up that prevents me from attending the event. When that happens, am I required to throw away the tickets? Am I allowed to transfer or sell them to someone else who can go? And if that is allowed, the suggested solution breaks down, because the bot operators just need to provide fake names, then sell the tickets to people who have real names and IDs.
I'm not sure I like tickets being non-refundable and non-transferrable.
All of what you said is true, but it's also beside the point. The point is that we buy insurance to mitigate the risk of a major loss of something valuable that we own. Because my house is paid in full, I may not be required to have insurance, but I'd be stupid not to have it, unless I had enough cash to absorb a catastrophic loss on my own (which I don't).
Even if you never own a self-driving car, but simply use a service, that self-driving car still has an owner, and that owner is still as likely to need insurance for that car. This is no different from today's rental car agencies. They can choose to buy insurance for their fleets, or they can choose to self-fund their own insurance. Either way, someone is prepared to absorb the loss, should a loss occur.
My basic point is that moving from human drivers to computer drivers doesn't change the basic need for insuring against the loss of valuable property.
My house doesn't drive at all, but I still need insurance, because things can still happen to it.
Anything that is expensive, that you can't afford to replace should something happen to it, will need to be insured. This notion that self-driving cars will destroy the insurance industry is just plain silly.
AWS can be HIPAA-compliant, but that doesn't mean it always is.
In order to be compliant, it's necessary for the provider to have a business associate agreement with Amazon, and for the provider to comply with HIPAA standards in the way they transmit and store protected health information.
That said, if the provider follows the proper protocols, there's no reason to think it's less secure on AWS than on their own servers.
Your doctors likely already use cloud services to store your medical data. They transmit it via the Internet to other medical providers and to insurance companies, who in turn store much of their data in the cloud.
The cloud is neither here nor there, when it comes to security. There are secure cloud providers, and insecure ones. Doctors who do not store their data in the cloud, likely store it on their own servers, which are probably much LESS secure than AWS.
You can't really win. Your data is out there, whether you like it or not. The questions you need to ask yourself are: - How critical is security to me? - What will really happen if someone sees this information in an unauthorized manner? - Do I trust my providers to keep my data private?
There are no right or wrong answers, nor is there a such thing as 100% secure. If somebody REALLY wants your data, they will get it.
Calling cancer a "checkpoint" suggests that it has a purpose. This in turn suggests a Designer. Evolution, on the other hand, suggests that life is simply a survival of the fittest in a sea of random chance. Are these scientists suggesting that they now believe evolution is driven by purpose?
This might be one of the reasons Firefox has been losing market share to Chrome. Chrome has had this feature for some time already, I use it every day to manage my home and work accounts. Even bookmarks are managed separately for each account.
It's good to see Firefox catching up. It's a great browser, I hope they don't stop there!
Assange isn't really concerned about courts. He just wants to make headlines and make people squirm. Chain of custody is not necessary for either of those goals.
Whichever one happens to be on the side of sanity.
In this case, Google was arguing that an API shouldn't be copyrightable. For anyone who understands what an API is, this makes total sense.
If I want to make an after-market alternator for a Honda car, I can do so by creating my own device that has the right size pulley, screw threads, electrical output, and so on. This absolutely is "fair use." In the same way, the API is the spec for the functionality behind it. I should be able to make an after-market part that meets those specs, without infringing on any copyrights.
Because Google was on the right side of the issue, I root for Google in this case. But if the roles were reversed, I would root for Oracle just as quickly.
And those people will continue to live paycheck to paycheck, even if they do get an extra "basic" income every month. "Our" problem isn't that we don't have enough money, it's that we spend more than we actually have!
Sure, the data might be public domain. But this does not require them to license their developer API to anyone and everyone, for any purpose. I'm not aware of any commercial enterprise that licenses their API for use by competitors.
Of course, 100% of the world's population isn't needed. But at least 100% of a town. But even that would be skewed by people moving to that place just because of the "free money." Even then, a few months isn't really enough to see how spending habits change over time.
It's not universal until it applies to everyone. There's a big difference between handing a few random people an amount of money each month, and handing EVERYONE an amount of money each month. There's also a big difference between doing it for 6 months, and doing it for a lifetime. The results of this study, whatever they may be, won't tell us much about what would happen if it were applied universally.
If you want security, forget single-factor authentication.
You can come up with algorithms or random password generators all day long. The problem is, nobody can remember really good passwords. That means you have to store them somewhere, in a password vault or service, or stick them to your keyboard.
We should really stop relying on a single password for authentication, and move to two-factor authentication. Then password complexity becomes less of an issue in the first place.
You've clearly never converted a significant amount of legacy code from 32 bits to 64 bits. Strange things happen, and it's not always easy to isolate the cause. My guess is that there are a lot of calls to unmanaged Win32 libraries that would break, not to mention variables that are declared with non-portable sizes, such as Int32 instead of Int.
Then there is performance. I suspect they aren't joking when they suggest that performance of a 64-bit version would be slow, if for no other reason than that the larger executables would take longer to load.
Back in 1996, I used vi to write code. Each week, I would write out some command sequences I wanted to learn, and tape it to the wall behind my monitor. In this way, I got pretty good at using the tool.
But since then, an amazing thing was invented: the GUI. Why should I have to memorize all those obscure command sequences? Sure, it makes sense to learn shortcuts for frequently-used commands, but not so much for the rarely-used ones.
Command lines are good for scripting, but they aren't ideal for every-day productivity.
Competition is a good thing. Once they come out with an IDE for.NET (Project Rider), Microsoft will finally have some real competition in the IDE space. THAT might well be what Microsoft need to help it decide to put in the effort to make a 64-bit version.
In 1983, my high school offered a "data processing" class through the local technical school. It was basically data entry on a "mini" computer. I finished the class in about 6 weeks, and had nothing to do for the rest of the semester. About that time, the school got their first shipment of the original IBM PC, the ones that booted into ROM BASIC if you didn't insert a floppy disk. The teacher let me take the manuals home to study, and I spent the rest of that semester teaching myself how to write code.
In college, I was a computer science major. But even then, in every programming language class I took, I taught myself at the beginning of the semester by reading through the textbook.
Most good programmers I know were self-taught, even if they did take classes in school.
Slashdot Mirror
You probably use PayPal even when you don't know you are using it. PayPal isn't just about peer to peer transactions. They also offer businesses credit card clearing services through PayFlow. Customers don't need a PayPal account to use it, and they don't even know they are using PayPal. They're a lot bigger than you think.
PayPal is much more than just peer-to-peer transactions. They offer businesses a credit card processing service called PayFlow, which is used by many large tech companies to collect customer payments. It's really not that unusual for merchants to have only one credit card processor.
It all comes down to what you think a ticket is.
If a ticket is a good--something you can own--then you absolutely should be able to buy and sell it as you please, and even scalpers have every right to do what they do.
If a ticket is more like a seat rental contract--not a possession, but an agreement--then it makes sense to only be able to buy from the ticket seller, and to make them non-transferrable. In this case, we have a situation like we have with the airlines, where sure, you can get your money back...well, a little bit of it anyway, and then only in the form of credit towards future flights, after a $100 trip change fee. We ALL love how the airlines do things, right??? And that's how we want concerts to be? I don't think so.
There's no really good answer. But I don't think it's selfish to want to be able to resell a ticket when you can't use it.
Slashdot was looking for poll ideas. This question seem perfect as a poll!
That's great, until I have something come up that prevents me from attending the event. When that happens, am I required to throw away the tickets? Am I allowed to transfer or sell them to someone else who can go? And if that is allowed, the suggested solution breaks down, because the bot operators just need to provide fake names, then sell the tickets to people who have real names and IDs.
I'm not sure I like tickets being non-refundable and non-transferrable.
All of what you said is true, but it's also beside the point. The point is that we buy insurance to mitigate the risk of a major loss of something valuable that we own. Because my house is paid in full, I may not be required to have insurance, but I'd be stupid not to have it, unless I had enough cash to absorb a catastrophic loss on my own (which I don't).
Even if you never own a self-driving car, but simply use a service, that self-driving car still has an owner, and that owner is still as likely to need insurance for that car. This is no different from today's rental car agencies. They can choose to buy insurance for their fleets, or they can choose to self-fund their own insurance. Either way, someone is prepared to absorb the loss, should a loss occur.
My basic point is that moving from human drivers to computer drivers doesn't change the basic need for insuring against the loss of valuable property.
My house doesn't drive at all, but I still need insurance, because things can still happen to it.
Anything that is expensive, that you can't afford to replace should something happen to it, will need to be insured. This notion that self-driving cars will destroy the insurance industry is just plain silly.
AWS can be HIPAA-compliant, but that doesn't mean it always is.
In order to be compliant, it's necessary for the provider to have a business associate agreement with Amazon, and for the provider to comply with HIPAA standards in the way they transmit and store protected health information.
That said, if the provider follows the proper protocols, there's no reason to think it's less secure on AWS than on their own servers.
Your doctors likely already use cloud services to store your medical data. They transmit it via the Internet to other medical providers and to insurance companies, who in turn store much of their data in the cloud.
The cloud is neither here nor there, when it comes to security. There are secure cloud providers, and insecure ones. Doctors who do not store their data in the cloud, likely store it on their own servers, which are probably much LESS secure than AWS.
You can't really win. Your data is out there, whether you like it or not. The questions you need to ask yourself are:
- How critical is security to me?
- What will really happen if someone sees this information in an unauthorized manner?
- Do I trust my providers to keep my data private?
There are no right or wrong answers, nor is there a such thing as 100% secure. If somebody REALLY wants your data, they will get it.
Calling cancer a "checkpoint" suggests that it has a purpose. This in turn suggests a Designer. Evolution, on the other hand, suggests that life is simply a survival of the fittest in a sea of random chance. Are these scientists suggesting that they now believe evolution is driven by purpose?
This might be one of the reasons Firefox has been losing market share to Chrome. Chrome has had this feature for some time already, I use it every day to manage my home and work accounts. Even bookmarks are managed separately for each account.
It's good to see Firefox catching up. It's a great browser, I hope they don't stop there!
Assange isn't really concerned about courts. He just wants to make headlines and make people squirm. Chain of custody is not necessary for either of those goals.
Whichever one happens to be on the side of sanity.
In this case, Google was arguing that an API shouldn't be copyrightable. For anyone who understands what an API is, this makes total sense.
If I want to make an after-market alternator for a Honda car, I can do so by creating my own device that has the right size pulley, screw threads, electrical output, and so on. This absolutely is "fair use." In the same way, the API is the spec for the functionality behind it. I should be able to make an after-market part that meets those specs, without infringing on any copyrights.
Because Google was on the right side of the issue, I root for Google in this case. But if the roles were reversed, I would root for Oracle just as quickly.
And those people will continue to live paycheck to paycheck, even if they do get an extra "basic" income every month. "Our" problem isn't that we don't have enough money, it's that we spend more than we actually have!
Sure, the data might be public domain. But this does not require them to license their developer API to anyone and everyone, for any purpose. I'm not aware of any commercial enterprise that licenses their API for use by competitors.
I completely agree that 2FA is only appropriate for places where security really matters, like bank accounts and such.
Of course, 100% of the world's population isn't needed. But at least 100% of a town. But even that would be skewed by people moving to that place just because of the "free money." Even then, a few months isn't really enough to see how spending habits change over time.
It's not universal until it applies to everyone. There's a big difference between handing a few random people an amount of money each month, and handing EVERYONE an amount of money each month. There's also a big difference between doing it for 6 months, and doing it for a lifetime. The results of this study, whatever they may be, won't tell us much about what would happen if it were applied universally.
If you want security, forget single-factor authentication.
You can come up with algorithms or random password generators all day long. The problem is, nobody can remember really good passwords. That means you have to store them somewhere, in a password vault or service, or stick them to your keyboard.
We should really stop relying on a single password for authentication, and move to two-factor authentication. Then password complexity becomes less of an issue in the first place.
You've clearly never converted a significant amount of legacy code from 32 bits to 64 bits. Strange things happen, and it's not always easy to isolate the cause. My guess is that there are a lot of calls to unmanaged Win32 libraries that would break, not to mention variables that are declared with non-portable sizes, such as Int32 instead of Int.
Then there is performance. I suspect they aren't joking when they suggest that performance of a 64-bit version would be slow, if for no other reason than that the larger executables would take longer to load.
Back in 1996, I used vi to write code. Each week, I would write out some command sequences I wanted to learn, and tape it to the wall behind my monitor. In this way, I got pretty good at using the tool.
But since then, an amazing thing was invented: the GUI. Why should I have to memorize all those obscure command sequences? Sure, it makes sense to learn shortcuts for frequently-used commands, but not so much for the rarely-used ones.
Command lines are good for scripting, but they aren't ideal for every-day productivity.
Competition is a good thing. Once they come out with an IDE for .NET (Project Rider), Microsoft will finally have some real competition in the IDE space. THAT might well be what Microsoft need to help it decide to put in the effort to make a 64-bit version.
In 1983, my high school offered a "data processing" class through the local technical school. It was basically data entry on a "mini" computer. I finished the class in about 6 weeks, and had nothing to do for the rest of the semester. About that time, the school got their first shipment of the original IBM PC, the ones that booted into ROM BASIC if you didn't insert a floppy disk. The teacher let me take the manuals home to study, and I spent the rest of that semester teaching myself how to write code.
In college, I was a computer science major. But even then, in every programming language class I took, I taught myself at the beginning of the semester by reading through the textbook.
Most good programmers I know were self-taught, even if they did take classes in school.
Sometimes I think that what passes for HUMAN intelligence is just all smoke and mirrors.
In Houston in summer, yes, you'd need a shower after any bike commute to work, even if you have to exert no energy at all.