I think you may confuse acidic with bitter? You still get the acids with a fast brew cycle, but the bitter taste takes longer to extract from the grounds. A slow dripper with low temperature (i.e. your typical $30 brewer) extracts very little acid, but a lot of bitterness.
For acidity, the beans matter a lot too. African highland beans are high in mineral acids (mainly phosphoric acid) while South American beans are high in organic acids (mainly acetic acid).
I make espresso each morning. It literally takes me 60 seconds to grind the beans, fill the carrier and press the shot. Don't see any faster or cheaper option.
Even if you like filtered coffee (which is about the cheapest to produce) then you get a much better cup if you grind your own beans, which means buying a grinder as well as whatever you're using to make coffee, which can add up to a hundred dollars or so. In contrast, tea can be made with just a ten dollar kettle.
A good certified drip brewer that brews fast enough to not make the coffee bitter easily costs a couple of hundred for the cheap models.
That said, one of the best methods of making great tasting coffee is using a kettle. It requires more attention to detail for the coffee to not turn out bad, and more work, especially cleaning, which is the main reason why it's fallen out of popularity. I don't see the average modren man making clearing skins or spending five minutes with a wire brush cleaning an S-shaped spout every morning.
He's talking about what it costs him. Make a pot of coffee yourself and the price per cup is about 20 cents.
That depends on the coffee, the cost of electricity, and how strong and bitter you like your coffee. While I drink most of my coffee at work, I also spend around $20 a week on coffee beans for the 2-person household morning coffee, from a store where pretty much all coffee beans costs the same. Because the second best[*] way to reduce bitterness while still having a strong coffee is to use a fast brewer that reduces the time the grounds are exposed to hot water, it also means using more beans. And the price goes up.
[*]: The best way is to avoid New World and lowland grown coffee.
If making bitter swill is acceptable, the cost can be kept low. For someone who only drinks one cup a day, I guess enjoying coffee isn't a big part of their life, and you can get away with it. But for people who really enjoy good coffee, this is not a working option.
There's a line between being frugal and being miserly, and I think we know which side Kevin O'Leary falls on.
So long as the parent is fair and not a complete douchebag, the child will be given a number.
That may be fair, but it teaches nothing. Exercising the ability to think about what the family can afford is far more educational than just comparing numbers. If saying $100 and the kid then asking for something that's $99.99, that would still indicate that it's greed, and not thought and consideration. Rewarding greed is not a good thing, IMHO. While not saying any fixed numbers, and the kid wishing for something that's $120, while the budget has to be stretched a bit to cover it, shows that the kid has engaged the mind at least somewhat and tried to find out what could be afforded. And wishing for something around $60 shows that they likely weren't greedy, and that should be rewarded.
Wow. You and I must live in different universes. I presume you don't have a daughter between 4 and 10 years old. A Barbie Dream House is the sine qua non of girlhood. Parental refusal to buy one constitutes the worst form of child abuse. A girl without one simply has no reason to live.
I wholeheartedly agree with the last sentence. Unfortunately, helping them end their life is considered filicide, and not a viable option in the current socioclimate.
I opt for teaching the tykes through practical exercises that greed does not pay off: "You get to wish for one major present which you will get if it fits within the household gift budget. If it's too expensive, you get nothing, nada. Not something cheaper instead, but nothing, because we don't reward greed. You get to decide what you ask for, so choose wisely. A hint for how much we can afford is the presents you have been given in earlier years." If they still unreasonably ask for a $1000 gift and your gift budget can't easily handle that, stand by your word and give them zilch.
You can see how non automatic it is because slashdot, which is written in Perl, is pretty much guaranteed to corrupt unicode characters in comments even though slashdot is is utf8.
Slashdot had UTF-8 support for a short while a decade or so ago. It was turned back off again, because the perl support was too good, allowing things like right-to-left spaces, which the crowd here naturally pounced on. Turning it back on is easy enough, but unless someone spends a lot of time hardening the system, it will get abused again.
As for your perl em-dash problem, why do you need to know the length, if it's a separator? Use the built-in functions that can deal with a separator of any length, and you should not have to write specific handling.
Why the awkward $delim_len? Because if the hyphen is a U+ 2013 EN DASH the length is 2.
But then it isn't a hyphen.
Decouple your mind from visual representations. In perl, there are even special functions and methods for handling separators, making it very easy to use any delimiters or set of delimiters you define. The typical way to handle this would be with split and join.
"Bad programmers can write bad programs" is a tautology.
No, it isn't. Linguistically there's nothing tautological about "A can B", no matter what the relation between A and B is.
The problem with perl is that it makes it (really) hard for good programmers to make (and MAINTAIN) good programs.
There are many problems with perl, but unless you define what a "good program" is, this is meaningless. Perl gives programmers more rope than most languages. How they use that rope is up to them.
causes others to follow Russia and run their own set of servers.
Others already do. There's the ORSN (Open Root Server Network) effort, which copies the root zone information from ICANN, but in case of suspected problems (read: manipulation), will run their own unadulterated copies. Quite a few ISPs in Europe use the ORSN root server list instead of the IANA/ICANN/IETF one, both for reliability and locality.
If you run your own nameserver, all you need to do is replace the hint file with one from http://www.orsn.org/roothint/r... If you don't, you can point your DNS server entry to one or more of the ones in the Wikipeda list referenced above.
Caveat: It is not known how good or fast ORSN is at detecting unwanted changes, so it may still provide hijacked results, or do so for some time before switching into independent mode.
I'm sure they are wanting to do this only to increase their capabilities to conduct offensive operations in the informational space without getting caught.
This would only bring the capabilities back to par with the US/Israel alliance which already "conducts offensive operations in the informational space". It's a catch-up in the arms race, not a leap ahead.
The domain name system being a vulnerability when under a single controller is not a new thing, and worries people in the West too. Efforts like Alternic were doomed to fail because there's no way to make people use it. At least countries have some clout and can make sure that its ISPs and OS/device vendors will use a different root server, or even re-route requests.
Supercookies survive new requests. You have to not just establish a new connection, but disable/clear/enable HSTS for the site between each request. Which browser lets you do that?
No, thanks, I prefer HTTP for all traffic where I don't log in or access or submit something that isn't public knowledge. For most of what I access, I don't mind if others get the data; I only mind whether the can tie the connections to me and aggregate and/or sell data.
Another common use case is that you as a company might want to present a different view of a site to your employees.
This is best done with authentication. Present the public view until the user has logged in as an employee. That way, even telecommuting employees will get the employee view.
Yes, but the site might be an external site. Like if someone internal goes to http://www.dell.com/, they can be sent to an internal site that fetches information from Dell's portal but shows the corporate pricing. Or presents a different www.google.com front page that aggregates google's search with an internal search. Or...
Newsflash, there is no *client* certificate in an HTTPS transaction
I never said that there is, so you're attempting to whack a strawman again here.
But you're also wrong - there is a session key[*] pair, which is established at connection time. Look up "Diffie-Hellman" and "forward secrecy". Without that, but just server keys, anyone could just replay any traffic and be able to decrypt anything the server sends with the server's public key. The session keys not only prevent replay eavesdropping, but uniquely identifies the client for as long as the session lasts. If a client sends a request for resourceA from one IP and for resourceB from another IP, the server knows it's the same client. If a client strips all cookies or other identifiable headers, it still knows it's the same client.
[*]: A certificate is just a key with a signature.
only if you take the extra step to also redirect any and all dns queries on your private network to your own dns server(s) (or drop them if not destined for your dns server).
what will you do if sally from accounting has put 8.8.8.8 as their first resolver?!
On a private network, you control not only the DNS results, but also routing and address space. That's what makes it a private network.
It's not uncommon to block every outgoing request that isn't proxied. Sally's DNS requests won't work, but her web access still will, because it's the proxy server that looks up the addresses, from the DNS servers the proxy server is configured to use. So her request for http://www.sar.com/ may do what she thinks, but her request for http://www.gimpoutfits.biz/ may lead her to a different site altogether.
I'm not entirely sure what "hiding who accesses the endpoint from the endpoint itself." means, but please explain how HTTPS doesn't do that.
HTTPS doesn't hide anything from the endpoint. That should be obvious?
However, it does largely defeat the multipathing, proxy caching and rewriting possible with HTTP, all of which helps hide who accesses an endpoint, as well as automatically adding an immutable identifier; the session key.
When I access http://www.fbi.gov/ and the proxy I use serve it from cache, the site won't even know that I accessed it. And when I ask for http://ww.cia.gov/page1 and http://www.cia.gov/page2 and the request comes from two different IPs, the site doesn't know that it's the same client accessing both pages. And when I access http://www.inflatableunicorns.... and my proxy deletes tracking information from the header (including IP address and browser fingerprints), they don't know that I'm the same person who visited last week. And they won't know that I looked at adcampaign.jpg either, because it can be served from a cache.
Now enter HTTPS, and how it changes this by trying to ensure a 1:1 connection.
Then consider what Google's business is, and whether it's in their interest to obtain as much accurate information as possible about who visits and who sees which ads, and how to aggregate and sell that data. That they push hard for the technology that helps their business model should not come as a surprise, nor should it be taken as them having your best interest in mind.
And consider the interest of the three letter agencies who sit at the endpoints and sees all the HTTPS data and metadata after it has been decrypted by the server. Do you think they want more accurate tracking capabilities or not?
If you can hide something from the client in HTTPS, you can also hide it in HTTP.
The problem isn't someone hiding something from the client - it's the ability (or lack thereof) to hide things from the server. HTTPS largely ensures a 1:1 session with a known identifier. HTTP can be served from cache, or modified on the fly to hide information from the server.
These days, the server is your enemy - they're the ones collecting, aggregating and selling information on you. Google's (and the TLAs) goal is to make this information gathering more comprehensive and trustworthy. That's why they want HTTPS/SPDY/HSTS - don't for a second think that they have your best interest at heart. That's only how they sell it to the unwashed masses.
A browser that assumes that it's on Internet when it isn't is at fault, not those who run their own network. And don't forget Postel's law. This is not being liberal in what you accept.
I really never thought I'd never see the day when Slashdot would deteriorate so far that your posts on this subject wouldn't be nodded down to oblivion immediately. Do you even really believe the bullshit you are spewing in this thread or are you trolling?
Given that (a) I actually said why, and all that you do is spewing "You're wrong na-na-na-na bullshit" with no explanation whatsoever, and (b) far more people have marked you as a foe on Slashdot than me, I think this speaks for itself. Most people here are able to judge posts based on what information or interesting points the posts provide, and not just who shouts the loudest.
Slashdot Mirror
As long as you know how to pour ("attention to details", I guess), you absolutely don't need the hipster nonsense kettles with the silly spouts.
A several hundred year old design with a spout that prevents ground and sludge from being poured with the coffee is hardly hipster nonsense...
Using filers inside a kettle, on the other hand, borders on hipsterism. How ... special.
I think you may confuse acidic with bitter?
You still get the acids with a fast brew cycle, but the bitter taste takes longer to extract from the grounds. A slow dripper with low temperature (i.e. your typical $30 brewer) extracts very little acid, but a lot of bitterness.
For acidity, the beans matter a lot too. African highland beans are high in mineral acids (mainly phosphoric acid) while South American beans are high in organic acids (mainly acetic acid).
I make espresso each morning. It literally takes me 60 seconds to grind the beans, fill the carrier and press the shot.
Don't see any faster or cheaper option.
Factor in cleaning time.
Even if you like filtered coffee (which is about the cheapest to produce) then you get a much better cup if you grind your own beans, which means buying a grinder as well as whatever you're using to make coffee, which can add up to a hundred dollars or so. In contrast, tea can be made with just a ten dollar kettle.
A good certified drip brewer that brews fast enough to not make the coffee bitter easily costs a couple of hundred for the cheap models.
That said, one of the best methods of making great tasting coffee is using a kettle. It requires more attention to detail for the coffee to not turn out bad, and more work, especially cleaning, which is the main reason why it's fallen out of popularity. I don't see the average modren man making clearing skins or spending five minutes with a wire brush cleaning an S-shaped spout every morning.
He's talking about what it costs him. Make a pot of coffee yourself and the price per cup is about 20 cents.
That depends on the coffee, the cost of electricity, and how strong and bitter you like your coffee.
While I drink most of my coffee at work, I also spend around $20 a week on coffee beans for the 2-person household morning coffee, from a store where pretty much all coffee beans costs the same. Because the second best[*] way to reduce bitterness while still having a strong coffee is to use a fast brewer that reduces the time the grounds are exposed to hot water, it also means using more beans. And the price goes up.
[*]: The best way is to avoid New World and lowland grown coffee.
If making bitter swill is acceptable, the cost can be kept low. For someone who only drinks one cup a day, I guess enjoying coffee isn't a big part of their life, and you can get away with it. But for people who really enjoy good coffee, this is not a working option.
There's a line between being frugal and being miserly, and I think we know which side Kevin O'Leary falls on.
So long as the parent is fair and not a complete douchebag, the child will be given a number.
That may be fair, but it teaches nothing.
Exercising the ability to think about what the family can afford is far more educational than just comparing numbers. If saying $100 and the kid then asking for something that's $99.99, that would still indicate that it's greed, and not thought and consideration. Rewarding greed is not a good thing, IMHO.
While not saying any fixed numbers, and the kid wishing for something that's $120, while the budget has to be stretched a bit to cover it, shows that the kid has engaged the mind at least somewhat and tried to find out what could be afforded. And wishing for something around $60 shows that they likely weren't greedy, and that should be rewarded.
Wow. You and I must live in different universes. I presume you don't have a daughter between 4 and 10 years old. A Barbie Dream House is the sine qua non of girlhood. Parental refusal to buy one constitutes the worst form of child abuse. A girl without one simply has no reason to live.
I wholeheartedly agree with the last sentence. Unfortunately, helping them end their life is considered filicide, and not a viable option in the current socioclimate.
I opt for teaching the tykes through practical exercises that greed does not pay off:
"You get to wish for one major present which you will get if it fits within the household gift budget. If it's too expensive, you get nothing, nada. Not something cheaper instead, but nothing, because we don't reward greed. You get to decide what you ask for, so choose wisely. A hint for how much we can afford is the presents you have been given in earlier years."
If they still unreasonably ask for a $1000 gift and your gift budget can't easily handle that, stand by your word and give them zilch.
You can see how non automatic it is because slashdot, which is written in Perl, is pretty much guaranteed to corrupt unicode characters in comments even though slashdot is is utf8.
Slashdot had UTF-8 support for a short while a decade or so ago. It was turned back off again, because the perl support was too good, allowing things like right-to-left spaces, which the crowd here naturally pounced on.
Turning it back on is easy enough, but unless someone spends a lot of time hardening the system, it will get abused again.
As for your perl em-dash problem, why do you need to know the length, if it's a separator? Use the built-in functions that can deal with a separator of any length, and you should not have to write specific handling.
Why the awkward $delim_len? Because if the hyphen is a U+ 2013 EN DASH the length is 2.
But then it isn't a hyphen.
Decouple your mind from visual representations.
In perl, there are even special functions and methods for handling separators, making it very easy to use any delimiters or set of delimiters you define. The typical way to handle this would be with split and join.
"Bad programmers can write bad programs" is a tautology.
No, it isn't. Linguistically there's nothing tautological about "A can B", no matter what the relation between A and B is.
The problem with perl is that it makes it (really) hard for good programmers to make (and MAINTAIN) good programs.
There are many problems with perl, but unless you define what a "good program" is, this is meaningless.
Perl gives programmers more rope than most languages. How they use that rope is up to them.
causes others to follow Russia and run their own set of servers.
Others already do. There's the ORSN (Open Root Server Network) effort, which copies the root zone information from ICANN, but in case of suspected problems (read: manipulation), will run their own unadulterated copies. Quite a few ISPs in Europe use the ORSN root server list instead of the IANA/ICANN/IETF one, both for reliability and locality.
If you run your own nameserver, all you need to do is replace the hint file with one from http://www.orsn.org/roothint/r...
If you don't, you can point your DNS server entry to one or more of the ones in the Wikipeda list referenced above.
Caveat: It is not known how good or fast ORSN is at detecting unwanted changes, so it may still provide hijacked results, or do so for some time before switching into independent mode.
I'm sure they are wanting to do this only to increase their capabilities to conduct offensive operations in the informational space without getting caught.
This would only bring the capabilities back to par with the US/Israel alliance which already "conducts offensive operations in the informational space". It's a catch-up in the arms race, not a leap ahead.
The domain name system being a vulnerability when under a single controller is not a new thing, and worries people in the West too. Efforts like Alternic were doomed to fail because there's no way to make people use it. At least countries have some clout and can make sure that its ISPs and OS/device vendors will use a different root server, or even re-route requests.
The SSL Session ID is deleted once you close the browser.
You've never heard of TLS Session Resumption nor supercookies?
With Chrome, it's hard to avoid either.
Why do you care? And what makes you think your proxy provider isn't doing just that?
Privacy is a bigger thing for me than security.
And I have met my proxy provider, and I am he.
Supercookies survive new requests. You have to not just establish a new connection, but disable/clear/enable HSTS for the site between each request. Which browser lets you do that?
No, thanks, I prefer HTTP for all traffic where I don't log in or access or submit something that isn't public knowledge. For most of what I access, I don't mind if others get the data; I only mind whether the can tie the connections to me and aggregate and/or sell data.
If you control the cache, you can use it to cache https.
Not with HSTS (see TFA). Well, you can cache it, but it won't be valid for the client. That makes Google happy.
Established at connection time = different for each connection = not persistent = not a viable method of tracking. Follow?
HSTS (and SPDY and HTTP/2.0) add persistency and allow for supercookies as a viable method of tracking, but only when using HTTPS. Follow?
Caches don't cache elements which may change frequently.
They cache whatever you set them to cache.
I know, strange concept, that the server isn't in control. That's what I like about http.
This is best done with authentication. Present the public view until the user has logged in as an employee. That way, even telecommuting employees will get the employee view.
Yes, but the site might be an external site. Like if someone internal goes to http://www.dell.com/, they can be sent to an internal site that fetches information from Dell's portal but shows the corporate pricing. Or presents a different www.google.com front page that aggregates google's search with an internal search. Or...
Newsflash, there is no *client* certificate in an HTTPS transaction
I never said that there is, so you're attempting to whack a strawman again here.
But you're also wrong - there is a session key[*] pair, which is established at connection time. Look up "Diffie-Hellman" and "forward secrecy". Without that, but just server keys, anyone could just replay any traffic and be able to decrypt anything the server sends with the server's public key. The session keys not only prevent replay eavesdropping, but uniquely identifies the client for as long as the session lasts. If a client sends a request for resourceA from one IP and for resourceB from another IP, the server knows it's the same client. If a client strips all cookies or other identifiable headers, it still knows it's the same client.
[*]: A certificate is just a key with a signature.
only if you take the extra step to also redirect any and all dns queries on your private network to your own dns server(s) (or drop them if not destined for your dns server).
what will you do if sally from accounting has put 8.8.8.8 as their first resolver?!
On a private network, you control not only the DNS results, but also routing and address space. That's what makes it a private network.
It's not uncommon to block every outgoing request that isn't proxied.
Sally's DNS requests won't work, but her web access still will, because it's the proxy server that looks up the addresses, from the DNS servers the proxy server is configured to use. So her request for http://www.sar.com/ may do what she thinks, but her request for http://www.gimpoutfits.biz/ may lead her to a different site altogether.
I'm not entirely sure what "hiding who accesses the endpoint from the endpoint itself." means, but please explain how HTTPS doesn't do that.
HTTPS doesn't hide anything from the endpoint. That should be obvious?
However, it does largely defeat the multipathing, proxy caching and rewriting possible with HTTP, all of which helps hide who accesses an endpoint, as well as automatically adding an immutable identifier; the session key.
When I access http://www.fbi.gov/ and the proxy I use serve it from cache, the site won't even know that I accessed it. And when I ask for http://ww.cia.gov/page1 and http://www.cia.gov/page2 and the request comes from two different IPs, the site doesn't know that it's the same client accessing both pages. And when I access http://www.inflatableunicorns.... and my proxy deletes tracking information from the header (including IP address and browser fingerprints), they don't know that I'm the same person who visited last week. And they won't know that I looked at adcampaign.jpg either, because it can be served from a cache.
Now enter HTTPS, and how it changes this by trying to ensure a 1:1 connection.
Then consider what Google's business is, and whether it's in their interest to obtain as much accurate information as possible about who visits and who sees which ads, and how to aggregate and sell that data. That they push hard for the technology that helps their business model should not come as a surprise, nor should it be taken as them having your best interest in mind.
And consider the interest of the three letter agencies who sit at the endpoints and sees all the HTTPS data and metadata after it has been decrypted by the server. Do you think they want more accurate tracking capabilities or not?
If you can hide something from the client in HTTPS, you can also hide it in HTTP.
The problem isn't someone hiding something from the client - it's the ability (or lack thereof) to hide things from the server.
HTTPS largely ensures a 1:1 session with a known identifier.
HTTP can be served from cache, or modified on the fly to hide information from the server.
These days, the server is your enemy - they're the ones collecting, aggregating and selling information on you. Google's (and the TLAs) goal is to make this information gathering more comprehensive and trustworthy. That's why they want HTTPS/SPDY/HSTS - don't for a second think that they have your best interest at heart. That's only how they sell it to the unwashed masses.
A browser that assumes that it's on Internet when it isn't is at fault, not those who run their own network.
And don't forget Postel's law. This is not being liberal in what you accept.
I really never thought I'd never see the day when Slashdot would deteriorate so far that your posts on this subject wouldn't be nodded down to oblivion immediately. Do you even really believe the bullshit you are spewing in this thread or are you trolling?
Given that (a) I actually said why, and all that you do is spewing "You're wrong na-na-na-na bullshit" with no explanation whatsoever, and (b) far more people have marked you as a foe on Slashdot than me, I think this speaks for itself.
Most people here are able to judge posts based on what information or interesting points the posts provide, and not just who shouts the loudest.