I'd go a step further. I would publicly, and with much fanfare, announce the development of anti-piracy filtering on the CloudFlare network, in part using domains and WHOIS details appearing in copyright cases (public record). When ready, offer to test it with "a handful of the most easily verifiable known sites" which, of course, would be code for "every Sony property that touches CloudFlare".
Let them see the results of early testing and ask if they still want it. When they backpedal, stop development. Don't turn it off, don't back out the changes (that would be further development), just stop development. Until they pay for the time spent implementing it in the first place, plus a modest fee to cover the time it will take to back it out, of course. Oh, and legal fees.
Perhaps it's just me, I can't name the 183 (or so) countries of the world, and I often miss one or two US states when listing them
I can't remember which of the several thousand bookmarks I have are still relevant; nor do I remember, or often have time, to sift through them and delete those which are no longer relevant. Tabs, grouped by window, are an easy way to track this.
If I'm still researching the topic, any tabs open in that topic's window are relevant (or have not been reviewed yet); when I'm done researching a topic, I bookmark any content I might find useful later and close that topic's window, along with all of its tabs. Done. I don't have to open the overly complex (compared to clicking single "X") bookmark management interface to clean up after a research session, which matters when researching several concurrent topics as I'd spend practically as much time cleaning up after each topic as I spend on the actual research. Most of those tabs have no relevance after the research session ends and, thus, do not belong in the long-term archive that is my bookmark list.
Mind you, I'm an efficient researcher and tend to keep my tab count under 200, spread across 6 or 7 windows, but I see how someone who opens every link they find on a subject, or who is maybe researching a wider range of topics at a given moment, might peak in the thousands. If you just finished several days, or a week or more, of topical research, would you rather your cleanup process was clicking a handful of "X" buttons to close a handful of windows, or sifting through hundreds or thousands of bookmarks to ensure that you only delete the ones that are no longer relevant?
Or are you implying that, because some people might lose track of the names of countries or states, we shouldn't have so many? Maybe you think a few nukes would improve things? Should we just bookmark Bolivia and only open it up when you need a bump of coke?
Ok, so we're still semi on the same page, and you've given me a slightly different perspective which may well lead to a theoretical solution (which will never be implemented, even if it could work, because money). I have an appointment to get to, so I don't have time to put the concept into words right now; I'll reply to your post again when I find the time.
Who knows, maybe my idea will be workable and maybe, by en even smaller margin, it might get implemented.
No, I got your point; you still seem to be missing mine, though.
If your traffic is only measured against your other traffic, your QoS headers have no effect on anyone else's traffic. Follow?
It's a simple implementation, actually; your ISP already splits its aggregate bandwidth into rate-limited streams (or buckets, if you prefer) based on the speed you pay for. They can just as easily apply QoS rules defined for each stream on an individual basis.
Hell, my consumer-grade router can do that. I can assign vnets a fixed amount of bandwidth and each vnet can have its own QoS rules; one vnet having rules that set every packet to high priority doesn't affect the other vnets (of course, it also doesn't benefit that vnet, either).
In other words, your QoS rules decide which of your packets get dropped or delayed if one or more of your packets need to be dropped or delayed; they don't, in this hypothetical (and easy to implement) scenario, determine whether your packets or someone else's get dropped or delayed. That latter determination would need to be made by the ISP's own traffic management system and a fair way to determine that is to determine what percentage of the aggregate bandwidth belongs to each user (e.g. we've sold 100Tb/sec and you pat for 100Mb/sec, you "own" 0.0001% of available bandwidth) and ensure that each user gets that percentage of whatever aggregate bandwidth is actually available during times of congestion.
Then, you can set all of your QoS rules to high priority all day long and your rules don't affect me in the slightest.
To put it another way, call me when you've implemented this and know what you're actually talking about. I have and I do or I wouldn't be repeating it.
That's not a problem if your QoS settings are evaluated against only your traffic. In other words, if you mark all of your packets high-priority, none of them really will be because they're all in the same priority queue. If implemented properly, the only one you can screw is yourself.
You buy bandwidth from your ISP, your bandwidth, in aggregate, is equal to everyone else's. You open a connection to Slashdot and begin sending and receiving packets with "normal priority" QoS headers; you then open a connection to your VoIP provider to make a call and begin sending them packets with "high priority" QoS headers. If you, then, saturate your available bandwidth, your connection to Slashdot will suffer but your VoIP call should not. Setting both to "high priority" negates any possible benefit to yourself but does not affect anyone else because your traffic isn't being evaluated against theirs.
Make perfect sense to have self driving cars communications isolated onto a low latency network.
It sure does, which is precisely why there are standards that exist for that type of communication. Those standards don't involve the Internet at all, thus they are isolated from that high-latency network.
The way QoS is supposed to work is that the endpoints (e.g. you and/or the website you are trying to visit) set the QoS values in the packet header and the infrastructure in between is supposed to honor that. Nobody would complain about that if it's what was happening, but it's not.
You know what? Actually, screw what you've said here, and screw what I said above. The industry average processing fee is 3% + 17 cents for in-person transactions and 3.5% + 32 cents for online transactions.
For swiped transactions, Square charges just 2.75%. For manually entered it's 3.5% + 15 cents and for internet transactions it's 2.9% + 30 cents.
From where I'm sitting, Square charged a LOT less than your average card processor for swiped transactions (-0.25% and -17 cents per transaction). For manually entered transactions, they're cheaper for smaller transactions ($4 or less) but more expensive over that; which really makes sense when you consider that's how most retailer-initiated credit card fraud happens. These should also be the least common type of transaction (most businesses will never use these). As for online transactions, it looks like Square is ahead by 0.6% and 2 cents per transaction.
So, it seems they're a better value for most businesses, not just the small ones.
I actually expected them to only be cheaper at volumes of $7000/mo or less, based on the rates I saw on both sides last time I checked (it's been a few years), so it was interesting to see how things have changed since. I did not expect Square to actually become the cheaper option.
The card issuers are the ones in a position to fix the problem. Square is a card processor, not an issuer, they don't set card issuer policies, so they can't fix a card issuer problem. Ergo, to provide their service, they must charge the fee; to not charge the fee means to not be able to pay employees to keep the service running, which means not providing the, service.
Follow now?
Also, your argument ignores "processing fees" (charged by the credit networks themselves) and "payroll for the people who keep the service running", which would still need to be charged for. Also add equipment purchase and maintenance costs, real-estate costs, building maintenance costs, gas, power, and water costs, and the cost of a shit ton of bandwidth (and the fiber over which it is delivered) and several banks of phone lines (in each of their buildings), all required to keep the service running. I was going easy on your, argument, trying to give it a break, but you just couldn't let me do that, could you?
If you think you can provide card processing services for free, step the fuck up and do it. I'd sign up on day one if I was presented information proving a viable business model.
Square's cut covers processing fees (which you'd have with any card processor), fraud (since you're transacting against their merchant account and not your own), and payroll for the people who keep the service running. Often times, for smaller businesses, Square offers a better value proposition than a traditional card processor which requires a merchant account (and the associated costs).
This. Bad engineering more often reflects bad management than bad engineers. Of course, if they live under bad management long enough, a good engineer will eventually become a bad one.
It depends how you define CPU, and I think Rutulian was defining it as a single core, in which case he's actually mostly right. I mean, now we have hyperthreading, which can attempt to execute two threads, but stalls when the execution paths of both threads would cross, so that it can decide which thread should be allowed to execute first. This happens more often than you might imagine, so the performance boost can be anywhere from absolutely none at all, all the way up to nearly double. That is to say, a CPU (core) with hyperthreading can execute, on average, just under 1.5 threads per cycle.
I know damned few fucking women that come to work hoping their boss or the guy in the cubicle next to them hits on them
And I know damned few men who hit on their coworkers. Sometimes asking someone out for coffee or a drink is just a means of getting to know them better, possibly for the purpose of building an understanding that allows them to work together better.
I do, however, know men who've been accused of sexual harassment for doing just that.
And there's a bit of truth in what both of you have to say; a woman seeking a payday is more likely to pursue legal avenues even after the alleged harassment has been dealt with so you will find many more instances of that if you actually look. Most women (in my experience) just want to be treated like human beings and will only complain about conditions when they're not; and once the situation has been remedied, they're most likely to carry on like nothing happened. By and far, the ones who sue are not the reasonable type -- the whole purpose of civil courts is to sort out which party is the unreasonable one in a dispute; two reasonable people never sit opposite each other in a courtroom.
Culturally men need to initiate romantic relations.
Well, there's your problem. That, of course, combined with some women either looking for a payday (e.g. making shit up) or being so full of themselves that every man who even glances in her direction must want her (e.g. imagining shit) can make it dangerous to even have women present in the workplace.
Admittedly, many (if not most) claims of harassment are legitimate, as most women with their head screwed on straight enough to land a job in the first place aren't that full of themselves. That, however, does not negate the fact that the ones who get the most media attention (and biggest payouts) happen to be the ones who don't have their head screwed on quite straight.
More to the point, why should two people not explore their relationship compatibility just because they work together? If they're not both adult enough to take "no" for an answer and drop it, well then, there's harassment and whoever can't hear "no" should no longer be employed. But it's important to recognize that this does, in fact, go both ways, and that it's not harassment until the would-be harasser knows it's unwanted; that is, until you say "no". Of course, once you've said "no", it does need to stop.
To be clear, I'm referring to verbal advances. Physical contact should always be opt-in, but there's really no way to opt-in to speaking, so that's got to be allowed to be opt-out. I mean, I suppose you could ask someone's permission to ask them out, but then someone complains about that and you have to ask permission to ask permission to ask them out... or we can just be adults and say "no" and drop it.
Slashdot Mirror
I'd go a step further. I would publicly, and with much fanfare, announce the development of anti-piracy filtering on the CloudFlare network, in part using domains and WHOIS details appearing in copyright cases (public record). When ready, offer to test it with "a handful of the most easily verifiable known sites" which, of course, would be code for "every Sony property that touches CloudFlare".
Let them see the results of early testing and ask if they still want it. When they backpedal, stop development. Don't turn it off, don't back out the changes (that would be further development), just stop development. Until they pay for the time spent implementing it in the first place, plus a modest fee to cover the time it will take to back it out, of course. Oh, and legal fees.
You bought and paid for the domain, ergo it was your domain. You were absolutely in the right to offer to sell the domain and not give it for free.
No. In the case of marriage, if you can find someone to buy the other half, sell her ASAP.
You sort of went off the rails there (or you did some rails before you wrote it) but wither way, yeah, basically everything you just wrote.
Perhaps it's just me, I can't name the 183 (or so) countries of the world, and I often miss one or two US states when listing them
I can't remember which of the several thousand bookmarks I have are still relevant; nor do I remember, or often have time, to sift through them and delete those which are no longer relevant. Tabs, grouped by window, are an easy way to track this.
If I'm still researching the topic, any tabs open in that topic's window are relevant (or have not been reviewed yet); when I'm done researching a topic, I bookmark any content I might find useful later and close that topic's window, along with all of its tabs. Done. I don't have to open the overly complex (compared to clicking single "X") bookmark management interface to clean up after a research session, which matters when researching several concurrent topics as I'd spend practically as much time cleaning up after each topic as I spend on the actual research. Most of those tabs have no relevance after the research session ends and, thus, do not belong in the long-term archive that is my bookmark list.
Mind you, I'm an efficient researcher and tend to keep my tab count under 200, spread across 6 or 7 windows, but I see how someone who opens every link they find on a subject, or who is maybe researching a wider range of topics at a given moment, might peak in the thousands. If you just finished several days, or a week or more, of topical research, would you rather your cleanup process was clicking a handful of "X" buttons to close a handful of windows, or sifting through hundreds or thousands of bookmarks to ensure that you only delete the ones that are no longer relevant?
Or are you implying that, because some people might lose track of the names of countries or states, we shouldn't have so many? Maybe you think a few nukes would improve things? Should we just bookmark Bolivia and only open it up when you need a bump of coke?
Ok, so we're still semi on the same page, and you've given me a slightly different perspective which may well lead to a theoretical solution (which will never be implemented, even if it could work, because money). I have an appointment to get to, so I don't have time to put the concept into words right now; I'll reply to your post again when I find the time.
Who knows, maybe my idea will be workable and maybe, by en even smaller margin, it might get implemented.
No, I got your point; you still seem to be missing mine, though.
If your traffic is only measured against your other traffic, your QoS headers have no effect on anyone else's traffic. Follow?
It's a simple implementation, actually; your ISP already splits its aggregate bandwidth into rate-limited streams (or buckets, if you prefer) based on the speed you pay for. They can just as easily apply QoS rules defined for each stream on an individual basis.
Hell, my consumer-grade router can do that. I can assign vnets a fixed amount of bandwidth and each vnet can have its own QoS rules; one vnet having rules that set every packet to high priority doesn't affect the other vnets (of course, it also doesn't benefit that vnet, either).
In other words, your QoS rules decide which of your packets get dropped or delayed if one or more of your packets need to be dropped or delayed; they don't, in this hypothetical (and easy to implement) scenario, determine whether your packets or someone else's get dropped or delayed. That latter determination would need to be made by the ISP's own traffic management system and a fair way to determine that is to determine what percentage of the aggregate bandwidth belongs to each user (e.g. we've sold 100Tb/sec and you pat for 100Mb/sec, you "own" 0.0001% of available bandwidth) and ensure that each user gets that percentage of whatever aggregate bandwidth is actually available during times of congestion.
Then, you can set all of your QoS rules to high priority all day long and your rules don't affect me in the slightest.
To put it another way, call me when you've implemented this and know what you're actually talking about. I have and I do or I wouldn't be repeating it.
Ok, so, what you're saying is that we're on the same page and you completely missed the point of my initial comment when you replied to it.
Problem is that's a system which relies on trust.
That's not a problem if your QoS settings are evaluated against only your traffic. In other words, if you mark all of your packets high-priority, none of them really will be because they're all in the same priority queue. If implemented properly, the only one you can screw is yourself.
You buy bandwidth from your ISP, your bandwidth, in aggregate, is equal to everyone else's. You open a connection to Slashdot and begin sending and receiving packets with "normal priority" QoS headers; you then open a connection to your VoIP provider to make a call and begin sending them packets with "high priority" QoS headers. If you, then, saturate your available bandwidth, your connection to Slashdot will suffer but your VoIP call should not. Setting both to "high priority" negates any possible benefit to yourself but does not affect anyone else because your traffic isn't being evaluated against theirs.
Make perfect sense to have self driving cars communications isolated onto a low latency network.
It sure does, which is precisely why there are standards that exist for that type of communication. Those standards don't involve the Internet at all, thus they are isolated from that high-latency network.
The way QoS is supposed to work is that the endpoints (e.g. you and/or the website you are trying to visit) set the QoS values in the packet header and the infrastructure in between is supposed to honor that. Nobody would complain about that if it's what was happening, but it's not.
You know what? Actually, screw what you've said here, and screw what I said above. The industry average processing fee is 3% + 17 cents for in-person transactions and 3.5% + 32 cents for online transactions.
For swiped transactions, Square charges just 2.75%. For manually entered it's 3.5% + 15 cents and for internet transactions it's 2.9% + 30 cents.
From where I'm sitting, Square charged a LOT less than your average card processor for swiped transactions (-0.25% and -17 cents per transaction). For manually entered transactions, they're cheaper for smaller transactions ($4 or less) but more expensive over that; which really makes sense when you consider that's how most retailer-initiated credit card fraud happens. These should also be the least common type of transaction (most businesses will never use these). As for online transactions, it looks like Square is ahead by 0.6% and 2 cents per transaction.
So, it seems they're a better value for most businesses, not just the small ones.
I actually expected them to only be cheaper at volumes of $7000/mo or less, based on the rates I saw on both sides last time I checked (it's been a few years), so it was interesting to see how things have changed since. I did not expect Square to actually become the cheaper option.
The card issuers are the ones in a position to fix the problem. Square is a card processor, not an issuer, they don't set card issuer policies, so they can't fix a card issuer problem. Ergo, to provide their service, they must charge the fee; to not charge the fee means to not be able to pay employees to keep the service running, which means not providing the, service.
Follow now?
Also, your argument ignores "processing fees" (charged by the credit networks themselves) and "payroll for the people who keep the service running", which would still need to be charged for. Also add equipment purchase and maintenance costs, real-estate costs, building maintenance costs, gas, power, and water costs, and the cost of a shit ton of bandwidth (and the fiber over which it is delivered) and several banks of phone lines (in each of their buildings), all required to keep the service running. I was going easy on your, argument, trying to give it a break, but you just couldn't let me do that, could you?
If you think you can provide card processing services for free, step the fuck up and do it. I'd sign up on day one if I was presented information proving a viable business model.
Jackass.
If you're going to play that game, maybe don't make the company with the mostly black logo the white guy?
The solution: dont tell the AI whether people are black or white.
RTFA, they didn't...
Square's cut covers processing fees (which you'd have with any card processor), fraud (since you're transacting against their merchant account and not your own), and payroll for the people who keep the service running. Often times, for smaller businesses, Square offers a better value proposition than a traditional card processor which requires a merchant account (and the associated costs).
That falls apart when considering a lone engineer...
This. Bad engineering more often reflects bad management than bad engineers. Of course, if they live under bad management long enough, a good engineer will eventually become a bad one.
It depends how you define CPU, and I think Rutulian was defining it as a single core, in which case he's actually mostly right. I mean, now we have hyperthreading, which can attempt to execute two threads, but stalls when the execution paths of both threads would cross, so that it can decide which thread should be allowed to execute first. This happens more often than you might imagine, so the performance boost can be anywhere from absolutely none at all, all the way up to nearly double. That is to say, a CPU (core) with hyperthreading can execute, on average, just under 1.5 threads per cycle.
You clearly got my point, so.... ok?
So far what we have is zero evidence of any women getting paydays from allegation complaints, justifiable or not.
Oh?
That fact that there were very few justified payouts has nothing to do with...
That's your allegation that women are "getting paydays" from supposedly justified complaints.
Like you said, it's on the claimant to support their claim. Read the rest of my comment for my thoughts on which of you is right, and why.
I know damned few fucking women that come to work hoping their boss or the guy in the cubicle next to them hits on them
And I know damned few men who hit on their coworkers. Sometimes asking someone out for coffee or a drink is just a means of getting to know them better, possibly for the purpose of building an understanding that allows them to work together better.
I do, however, know men who've been accused of sexual harassment for doing just that.
Your zero examples say otherwise.
So do yours.
And there's a bit of truth in what both of you have to say; a woman seeking a payday is more likely to pursue legal avenues even after the alleged harassment has been dealt with so you will find many more instances of that if you actually look. Most women (in my experience) just want to be treated like human beings and will only complain about conditions when they're not; and once the situation has been remedied, they're most likely to carry on like nothing happened. By and far, the ones who sue are not the reasonable type -- the whole purpose of civil courts is to sort out which party is the unreasonable one in a dispute; two reasonable people never sit opposite each other in a courtroom.
Culturally men need to initiate romantic relations.
Well, there's your problem. That, of course, combined with some women either looking for a payday (e.g. making shit up) or being so full of themselves that every man who even glances in her direction must want her (e.g. imagining shit) can make it dangerous to even have women present in the workplace.
Admittedly, many (if not most) claims of harassment are legitimate, as most women with their head screwed on straight enough to land a job in the first place aren't that full of themselves. That, however, does not negate the fact that the ones who get the most media attention (and biggest payouts) happen to be the ones who don't have their head screwed on quite straight.
More to the point, why should two people not explore their relationship compatibility just because they work together? If they're not both adult enough to take "no" for an answer and drop it, well then, there's harassment and whoever can't hear "no" should no longer be employed. But it's important to recognize that this does, in fact, go both ways, and that it's not harassment until the would-be harasser knows it's unwanted; that is, until you say "no". Of course, once you've said "no", it does need to stop.
To be clear, I'm referring to verbal advances. Physical contact should always be opt-in, but there's really no way to opt-in to speaking, so that's got to be allowed to be opt-out. I mean, I suppose you could ask someone's permission to ask them out, but then someone complains about that and you have to ask permission to ask permission to ask them out... or we can just be adults and say "no" and drop it.
If you install an X server in Windows, yes, X11 works.