Paid based on quality of service is one thing. That means the waitress makes [at least] minimum wage, and gets tipped when she serves well, and not tipped when she doesn't.
The problem is when the waitress is being paid below minimum wage and needs tips just to reach her base pay. This leads to people expecting some base amount of tip (15, 18, 20% are commonly quoted), PLUS more tips if the service is good.
I have no problem tipping 25-50% for amazing service. I also have no problem leaving a penny as a tip if I get one refill on my coke/tea/water during a 90 minute meal where my glass is empty for most of it.
Also, I have a problem with the idea of percentage based tipping in general. If I buy a $2 sandwich and get great service, and you buy a $20 steak and get average service, I expect to tip more than you do, and generally do. I have tipped $5 on a $3 meal. I have tipped $0.01 on a $400 whole-family-out-for-4th-of-July dinner.
One state, and I cannot for the life of me find the link now, had referendums this year to control the voting of state representatives on particular issues. That's one way to institute direct democracy from the bottom up.
If you watched the animation you would realize that the "general depiction of a rising and falling curve" is the point. The google prediction is two weeks ahead of the CDC data for the same changes, and can be data mined far more specifically for location and such.
Of course you can prove a negative, usually by contradiction. Assume the opposite and see if that produces a contradiction. If it does, then the original negative is true.
Because telnetd has some tiny fraction of the system overhead of ssh daemons, even "tiny" ones.
Re:I haven't followed the whole Android business,
on
T-Mobile G1 Rooted
·
· Score: 4, Informative
Sorry, I fail for not RTFA. They are misusing "rooted", which confused me. "rooted" in the popular [geek] vernacular means that a remote non-admin user can gain root access, such as through a buffer overflow exploit. It has nothing to do with the practice of gaining root access on your own devices.
So, the point is, while I am still paying my ISP, and you are still paying your ISP, if one of them is not delivering packets to/from me/you, one of them is not fulfilling its contract with one of us. If your ISP rejects packets that I try to send you, then it has likely violated its SLA with you, and vice versa. You are paying them to give you the traffic addressed to you and [try to] deliver traffic from you. When they start rejecting traffic to you, they are no longer providing the service you are paying them for.
The former. The AC that I responded to implied that any cable connection must have basic cable channels on it. That is incorrect, as plenty of people have cable connections with no cable tv subscription. The cable company is not required to deliver local channels at all, unencrypted or otherwise, to those people.
Unencrypted, yes. Delivered, no. There is nothing that says they have to give you the broadcast channels at all, just that if they do then they must be unencrypted. With the proper filter installed you won't receive any TV channels.
I think that you are mistaken. Smoke up and smoke out can mean the same thing in this context, but smoke up is more specific (smoke out can imply smoking until you run out).
How do you resolve conflicts when the rigidity rules say one thing, while the brick value rules say another, and the color dithering rules say yet another? There should be a weighting function, and the impact of that decision will cascade down the mosaic, affecting other decisions. Finding the combination of decisions that yields the optimal (for a given set of weights) arrangement is NP.
If you use a less strict definition of "lego brick" that includes plates then there are also 1/3 by X proportions. Then there is the rigidity issue (the classic brick-laying arrangement of offset rows is good, while straight row/column arrangement of constant-width bricks is very bad). And finally the problem of parts cost (the easiest solution is a whole lot of 1x1 bricks, but 1x1 are rare and expensive, while 1x4 are cheap and super common).
The major algorithmic difference is that lego blocks are not [always] square, and figuring out which combination of sizes to use to cover an arbitrarily shaped block of color is NP-Hard. What he has done here is seriously impressive.
I think the primary item here is the integration of the application-launching functionality of a "launch bar" with the status-of-my-open-applications functionality of a "task bar", which is a far less common combination.
I would gladly work 24h on call for 50k, that's over twice what I am making now for a 8-5 job.
Paid based on quality of service is one thing. That means the waitress makes [at least] minimum wage, and gets tipped when she serves well, and not tipped when she doesn't.
The problem is when the waitress is being paid below minimum wage and needs tips just to reach her base pay. This leads to people expecting some base amount of tip (15, 18, 20% are commonly quoted), PLUS more tips if the service is good.
I have no problem tipping 25-50% for amazing service. I also have no problem leaving a penny as a tip if I get one refill on my coke/tea/water during a 90 minute meal where my glass is empty for most of it.
Also, I have a problem with the idea of percentage based tipping in general. If I buy a $2 sandwich and get great service, and you buy a $20 steak and get average service, I expect to tip more than you do, and generally do. I have tipped $5 on a $3 meal. I have tipped $0.01 on a $400 whole-family-out-for-4th-of-July dinner.
One state, and I cannot for the life of me find the link now, had referendums this year to control the voting of state representatives on particular issues. That's one way to institute direct democracy from the bottom up.
3 false positives and 1 false negative among a number of true positives and negatives. Who are you to say what a useful ratio is?
If you watched the animation you would realize that the "general depiction of a rising and falling curve" is the point. The google prediction is two weeks ahead of the CDC data for the same changes, and can be data mined far more specifically for location and such.
Of course you can prove a negative, usually by contradiction. Assume the opposite and see if that produces a contradiction. If it does, then the original negative is true.
That would take negative two Funny moderations, since I score Funny as -3.
Because telnetd has some tiny fraction of the system overhead of ssh daemons, even "tiny" ones.
Sorry, I fail for not RTFA. They are misusing "rooted", which confused me. "rooted" in the popular [geek] vernacular means that a remote non-admin user can gain root access, such as through a buffer overflow exploit. It has nothing to do with the practice of gaining root access on your own devices.
They would probably be more helpful...
What don't you get? Someone ran a network service on an open platform, the service was buggy, the device got exploited (in theory, anyways).
*whoosh*
people other than the person running telnetd can gain root access to the device.
So, the point is, while I am still paying my ISP, and you are still paying your ISP, if one of them is not delivering packets to/from me/you, one of them is not fulfilling its contract with one of us. If your ISP rejects packets that I try to send you, then it has likely violated its SLA with you, and vice versa. You are paying them to give you the traffic addressed to you and [try to] deliver traffic from you. When they start rejecting traffic to you, they are no longer providing the service you are paying them for.
The former. The AC that I responded to implied that any cable connection must have basic cable channels on it. That is incorrect, as plenty of people have cable connections with no cable tv subscription. The cable company is not required to deliver local channels at all, unencrypted or otherwise, to those people.
You are correct, except for one detail... Someone who is only paying for cable internet is not a cable tv subscriber.
Unencrypted, yes. Delivered, no. There is nothing that says they have to give you the broadcast channels at all, just that if they do then they must be unencrypted. With the proper filter installed you won't receive any TV channels.
I think that you are mistaken. Smoke up and smoke out can mean the same thing in this context, but smoke up is more specific (smoke out can imply smoking until you run out).
http://www.urbandictionary.com/define.php?term=smoke+up
http://www.urbandictionary.com/define.php?term=smoke+out
It's a pager, so it does it the same way cell phones do, from the time signal from cell phone towers.
Caller ID spoofing comprises a number of TCPA violations, most of which have explicit civil penalties.
+1 Agree
You seem to be under the mistaken impression that the G1 runs linux. It runs Android.
How do you resolve conflicts when the rigidity rules say one thing, while the brick value rules say another, and the color dithering rules say yet another? There should be a weighting function, and the impact of that decision will cascade down the mosaic, affecting other decisions. Finding the combination of decisions that yields the optimal (for a given set of weights) arrangement is NP.
If you use a less strict definition of "lego brick" that includes plates then there are also 1/3 by X proportions. Then there is the rigidity issue (the classic brick-laying arrangement of offset rows is good, while straight row/column arrangement of constant-width bricks is very bad). And finally the problem of parts cost (the easiest solution is a whole lot of 1x1 bricks, but 1x1 are rare and expensive, while 1x4 are cheap and super common).
The major algorithmic difference is that lego blocks are not [always] square, and figuring out which combination of sizes to use to cover an arbitrarily shaped block of color is NP-Hard. What he has done here is seriously impressive.
I think the primary item here is the integration of the application-launching functionality of a "launch bar" with the status-of-my-open-applications functionality of a "task bar", which is a far less common combination.