Touch screen computer built into the wall with Internet access. Bookmarks to recipe websites, Food network, and a calendar/planning system for keeping track of food inventories. A small printer to print out labels for foods.
That's going to be "interesting" when it comes to the problem of keeping things clean, especially if you're frying anything. You'll be fighting a constant battle with airborne grease microdroplets settling out on everything.
But apart from that, nice choices. You're missing one vital thing though: masses of cupboards and drawers. Being able to put things away neatly is such a good thing. Also consider the benefits of having some shallow-depth cupboards: you can't get as much in them, but you can search them much more easily. (My favorite is the spice cupboard: a whole floor-to-ceiling job filled with spices and dried herbs, sitting there and tempting you to make awesomely tasty meals...)
Sounds like you picked a poor contractor. That sucks. It's worth getting to know your neighbors and asking if they've got any recommendations for people to employ (or who to avoid!) so as to get someone who actually knows what they're doing. The best case is if you can get someone who knows what they're doing and takes pride in doing a good job: they might not have the cheapest quote, but they usually do the job right the first time and that's worth a lot.
It's just the same in software development. You get what you (don't) pay for.
And btw, only idiot would use tabs instead of spaces, 3 spaces actually:P
An indent of 3 works really well for blog postings (or academic papers), where you've usually got to keep lines really short, but in production code the most common indent across lots of languages seems to be 4. (This is independent of the space/tab "debate".)
K&R is the ugliest style ever concieved, and the reason for NOT enforcing style as syntax is because better approached can, and have, evolved over time. The author doesn't realize that because he dismisses the very possibility of value up front. He is an idiot.
You've missed the point, which is that fighting over styles (where you can use software to enforce them instead) is stupid. The details of the style don't matter too much and different languages have definitely evolved in different directions, but throughout it is consistency, and tools to help you keep consistent, are the key.
Note that I've just started working with AWS, and I haven't double checked that S3 bandwidth is cheaper than E2 bandwidth.
The pricing rules aren't the same for the two services. IIRC, one charges by the GB and the other by the "million GET requests" (or something like that). Converting requires knowledge of your average data sizes.
But when - as in almost every case - the owner of the private property puts up a sign indicating that photography isn't allows on the premises, that's pretty damn straightforward.
Still doesn't grant the right to assault the photographer.
Actually, I think the major defect in X11 is the focus model and things like grabs that are a huge pain in the ass to work with, and make little sense in the modern world (which window gets an input event for a multi-touch gesture for example? Actually, there's an X extension for that now...). The protocol itself is pretty clean and not particularly inefficient. The issue with compositing is that it might involve a few extra context switches, triggering things like TLB flushes... of course, the last couple of generations of x86-64 chips have tagged TLBs (albeit only designed for virtualization) so in theory even that expense could be mitigated. And then the compositor is probably just bypassing most of X anyway nowadays, so someone got the bright idea to get rid of X. I suspect a compositor-specific protocol for X might solve a lot of the problems (because, well, window managers performing compositing instead of having external compositors hints at a flaw in the way compositing fits in the X architecture).
There are a few things that need sorting out. The keyboard handling code is... umm... "mysterious to mortals", and the whole business with visuals and colormaps has been outdated for well over a decade. But the big thing now is probably that window positions and sizes are described by a short; it's now becoming generally practical (if still a little expensive) to assemble a display that is larger than 32k pixels in some dimension, so now is the time to update the protocol to allow larger values for coordinates. Yes, it sounds trivial, but it permeates through the whole protocol itself, so fixing it will be disruptive and incompatible. But it needs doing.
The compositing problem is mostly due to the lack of a good way to do alpha blending of an image at speed. Some apps need closer integration, but they're a minority. (And for goodness' sake, font rendering belongs server side. If only I could be certain that it didn't have crippling bugs when rendering at angles other than the four cardinal directions...)
TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
That allows you to have a wonderfully secure conversation with whoever is snooping. Great step forward there!
It's important that clients verify the identity of the servers to which they connect, but they can do so in many ways. Public HTTPS does it in a particular pattern, but a self-signed certificate also works (provided you've distributed the server's public key to clients in a trusted way first). The problem with self-signed on the public HTTPS web is that there's too many sites for it to be at all practical for you to acquire all their self-signed public certificates before connecting to any of them; that advantage (of the CA system) ceases to be very relevant on a closed system such as an intranet, though larger intranets can go for things like a private CA.
Expired certificates or non-matching host certificates are a demonstration of poor deployment.
'Tis a jobs program, and nothing more. Even the congressmen who are against the idea of the TSA are busy spinning it as providing jobs to their constituents.
You could privatize the vast majority of the TSA without any ill-effects, keeping just a small rump whose job would be to test whether the privatized parts are still doing their security checks correctly. This is pretty much how airport security is handled in most of Europe; the security staff are employed by the airport (or, more usually, a specialist contractor) and there's just central validation that the checks being performed are adequate with respect to the threat.
Eventually Wayland will provide a better remote desktop experience than X.
Eventually we're all dead.
OK, that's slightly harsh. There's no believable roadmap for getting to where you're describing, so it might as well be a vaporware announcement. These things don't happen by magic. (The only way to get snappy GUIs over a network is to not ship pixel buffers around; that's the operation that is genuinely painful operation, whatever the rest of the protocol is like.)
Of course, what I (as someone involved in toolkit maintenance) want out of a replacement for X11 is to no longer have to deal with different window visuals or bit depths or window dimensions limited to 16-bit values. A richer model for remote composition would be nice, but the horrible pain (as a toolkit author) is elsewhere. A properly documented and sane system for input methods would be nice too, but I don't believe that will happen (based on too much experience).
The reason X11 is slow (or rather seems slow) is because X11 is an asynchronous API.
The issue is almost certainly due to client-side bitmap composition, where X11 is definitely slow. If you can write your GUI code to keep large data on the server and do the composition there, you avoid the problems and X11 (either with a modern network or locally) is fast. Assuming you grok asynchronous programming, of course, but that's not that hard. I remember using Tk back in 1995 and it felt fast then due to clever asynchronous programming (faster than LispWorks, which was a Motif-based monstrosity that encouraged going for a long coffee while booting the environment...) We now have much faster systems, so we have no excuse for slow GUIs. Except that transfer of bitmaps between client and server is slow; that's the one place in X11 where you really do need bulk data transfer.
Of course, most of the people bitching about "too slow for modern GUIs" are people who insist on using excessive graphical glitz. I really don't need my terminal windows to be translucent surfaces; it adds nothing valuable! (Putting the WM on the same system as the server — and so able to use local private APIs for window composition — is reasonable. Most apps aren't WMs.)
Ok, say you are a rich person. Would you rather a) live in a fancy house with slums all around where you need an armed guard whenever you have to travel outside of your closed complex, or b) live in a fancy house with decent houses all around you without there being any slums and without having to pay taxes to support people who don't work because the country is wealthy enough that everybody can make a decent living with a reasonable amount of effort?
To understand the mindset of the really wealthy, realize that if it meant that they had a fancier house, they'd choose option (a) above. The ability to be conspicuously much better than the people around you is exceptionally attractive due to the way that primate dominance hierarchies work; absolute wealth matters nowhere near as much as relative wealth.
You may know Visa and Mastercard, through their issuers, guarantee to protect their customers from most types of fraud. If you pay by Visa and are shipped a counterfeight product, you can fill out a form and get your money back. I suspect most would agree that's good for consumers. It means, however, that Visa is ultimately on the hook for the money.
Whether or not it is Visa (or MC) that are on the hook, or the participating bank (things get really complicated under the covers), it is a critical part of the credit card system that you can do these things, as they mean that you can trust the system itself much more. While hardly perfect, it does mean that you can stand a reasonable chance to get the goods or service as described; fraudsters and crappy genuine vendors have a much harder time of it than if it was done otherwise, and that encourages people to use their credit cards which in turn benefits the credit card company themselves most overall (from things like holding payments when en route between the various parties involved on the merchant side).
Yes, Visa and Mastercard are middle men, but the service they provide — a payments system that tends to prevent a lot of fraud and which is convenient and less risky in many situations by comparison with cash — is one that many find very worthwhile using.
Or you can just use a computer, which can be programmed to automatically calculate what the overall level of "insecurity" may be in each particular case, and condense it down to a simple "blue green yellow red" type indicator, to make it easy for the user to tell at a glance what the potential risk may be....instead of overwhelming the user with dialogs full of text which the user simply isn't going to understand. Why the hell should the browser even pop up a dialog? Just flash a big red warning in the corner of the address bar or something if the site security isn't up to snuff.
Mozilla Firefox is the worst example of stupidity in this case. Whichever developers decided it would be best to scare the shit out of the user and make him jump through hoops every time a certificate isn't perfect, out to be hauled out back, lined up, and summarily given a stern talking to. What horrible UI design.
The problem is this case (from the GP):
2. The issuer of the certificate is unknown to me (the browser). Insecurity risk: high on a public website, low on an internal site. Action: Highlight the issuer and the website that you were trying to connec tto User suggestion: if you recognize the issuer as someone you know (like your company) and you're connecting to the company's website, continue. If not, do not continue and disconnect your computer from the network.
The problem? Knowing whether a site is public or internal is rather hard to do. (For example, we use very many domains in our internal websites, especially ones that have substantial pieces that are also public.) I suppose you could do it by having some way of finding out (from DHCP? or maybe local DNS?) the address of a service that will describe what services are internal to you, but that's starting to get really complicated (and not widely deployed, which makes it a problem in practice).
Fortunately Carol already heard through the grapevine that Mallory is a sleazy whore, and refused to accept her certificate.
It's a good thing that certificates are only proof of identity, not proof of authority.
What the fuck difference does it make if my certificate is self signed or signed by an "authority"? What makes you think an "authority's" signature can't be faked, or backdoored?
I suggest you go away and actually try to fake or backdoor a digital signature (on something with a realistic key size and used in a proper protocol like SSL) before making that claim. While you can easily fake the Distinguished Name, the cryptographic part of the signature is really hard to fake; the easiest way to fool a client is to get it to trust a different trust root that you control so you can inject certs with the same DN as the real ones. Which is what TFA was originally about.
Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".
Operationally, a private CA works at least as well and provides an equivalent level of trust. The advantage is that the CA's private credentials can be kept offline in a safe most of the time, so they're much harder to lose, yet you don't need to futz around with adjusting clients so much when you create a new server certificate for operational use.
Slashdot Mirror
There's one sure fire way to get bureaucrats to shut up: threaten to cut their budget if they mention it again.
You can also suggest that they might need to relocate their department to Yellowknife or Iqaluit.
Touch screen computer built into the wall with Internet access. Bookmarks to recipe websites, Food network, and a calendar/planning system for keeping track of food inventories. A small printer to print out labels for foods.
That's going to be "interesting" when it comes to the problem of keeping things clean, especially if you're frying anything. You'll be fighting a constant battle with airborne grease microdroplets settling out on everything.
But apart from that, nice choices. You're missing one vital thing though: masses of cupboards and drawers. Being able to put things away neatly is such a good thing. Also consider the benefits of having some shallow-depth cupboards: you can't get as much in them, but you can search them much more easily. (My favorite is the spice cupboard: a whole floor-to-ceiling job filled with spices and dried herbs, sitting there and tempting you to make awesomely tasty meals...)
Sounds like you picked a poor contractor. That sucks. It's worth getting to know your neighbors and asking if they've got any recommendations for people to employ (or who to avoid!) so as to get someone who actually knows what they're doing. The best case is if you can get someone who knows what they're doing and takes pride in doing a good job: they might not have the cheapest quote, but they usually do the job right the first time and that's worth a lot.
It's just the same in software development. You get what you (don't) pay for.
And btw, only idiot would use tabs instead of spaces, 3 spaces actually :P
An indent of 3 works really well for blog postings (or academic papers), where you've usually got to keep lines really short, but in production code the most common indent across lots of languages seems to be 4. (This is independent of the space/tab "debate".)
Wait? Is that even right? Can = be used without escaping when it is outside of a capture or a positional assertion???
If it's POSIX REs, yes. PCRE, mostly (except for a few spots where the = is really part of a multi-character token). Other flavors, who knows?
K&R is the ugliest style ever concieved, and the reason for NOT enforcing style as syntax is because better approached can, and have, evolved over time. The author doesn't realize that because he dismisses the very possibility of value up front. He is an idiot.
You've missed the point, which is that fighting over styles (where you can use software to enforce them instead) is stupid. The details of the style don't matter too much and different languages have definitely evolved in different directions, but throughout it is consistency, and tools to help you keep consistent, are the key.
Note that I've just started working with AWS, and I haven't double checked that S3 bandwidth is cheaper than E2 bandwidth.
The pricing rules aren't the same for the two services. IIRC, one charges by the GB and the other by the "million GET requests" (or something like that). Converting requires knowledge of your average data sizes.
But when - as in almost every case - the owner of the private property puts up a sign indicating that photography isn't allows on the premises, that's pretty damn straightforward.
Still doesn't grant the right to assault the photographer.
Bad Apple now go to bed, no desert for you.
Not even the Mojave?
You mean Land of the Sheep, Home of the Slave....?
Don't worry! The sheep wave around their holy Atlas Shrugged copies and believe that it's only everyone else who are subjugated...
Actually, I think the major defect in X11 is the focus model and things like grabs that are a huge pain in the ass to work with, and make little sense in the modern world (which window gets an input event for a multi-touch gesture for example? Actually, there's an X extension for that now...). The protocol itself is pretty clean and not particularly inefficient. The issue with compositing is that it might involve a few extra context switches, triggering things like TLB flushes... of course, the last couple of generations of x86-64 chips have tagged TLBs (albeit only designed for virtualization) so in theory even that expense could be mitigated. And then the compositor is probably just bypassing most of X anyway nowadays, so someone got the bright idea to get rid of X. I suspect a compositor-specific protocol for X might solve a lot of the problems (because, well, window managers performing compositing instead of having external compositors hints at a flaw in the way compositing fits in the X architecture).
There are a few things that need sorting out. The keyboard handling code is... umm... "mysterious to mortals", and the whole business with visuals and colormaps has been outdated for well over a decade. But the big thing now is probably that window positions and sizes are described by a short; it's now becoming generally practical (if still a little expensive) to assemble a display that is larger than 32k pixels in some dimension, so now is the time to update the protocol to allow larger values for coordinates. Yes, it sounds trivial, but it permeates through the whole protocol itself, so fixing it will be disruptive and incompatible. But it needs doing.
The compositing problem is mostly due to the lack of a good way to do alpha blending of an image at speed. Some apps need closer integration, but they're a minority. (And for goodness' sake, font rendering belongs server side. If only I could be certain that it didn't have crippling bugs when rendering at angles other than the four cardinal directions...)
TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
That allows you to have a wonderfully secure conversation with whoever is snooping. Great step forward there!
It's important that clients verify the identity of the servers to which they connect, but they can do so in many ways. Public HTTPS does it in a particular pattern, but a self-signed certificate also works (provided you've distributed the server's public key to clients in a trusted way first). The problem with self-signed on the public HTTPS web is that there's too many sites for it to be at all practical for you to acquire all their self-signed public certificates before connecting to any of them; that advantage (of the CA system) ceases to be very relevant on a closed system such as an intranet, though larger intranets can go for things like a private CA.
Expired certificates or non-matching host certificates are a demonstration of poor deployment.
'Tis a jobs program, and nothing more. Even the congressmen who are against the idea of the TSA are busy spinning it as providing jobs to their constituents.
You could privatize the vast majority of the TSA without any ill-effects, keeping just a small rump whose job would be to test whether the privatized parts are still doing their security checks correctly. This is pretty much how airport security is handled in most of Europe; the security staff are employed by the airport (or, more usually, a specialist contractor) and there's just central validation that the checks being performed are adequate with respect to the threat.
The earth has had periods of MUCH warmer climates, and life thrived in all of them.
And I'm sure the bacteria will do just fine. You and me? That's rather less certain, and rather more important to us.
Eventually Wayland will provide a better remote desktop experience than X.
Eventually we're all dead.
OK, that's slightly harsh. There's no believable roadmap for getting to where you're describing, so it might as well be a vaporware announcement. These things don't happen by magic. (The only way to get snappy GUIs over a network is to not ship pixel buffers around; that's the operation that is genuinely painful operation, whatever the rest of the protocol is like.)
Of course, what I (as someone involved in toolkit maintenance) want out of a replacement for X11 is to no longer have to deal with different window visuals or bit depths or window dimensions limited to 16-bit values. A richer model for remote composition would be nice, but the horrible pain (as a toolkit author) is elsewhere. A properly documented and sane system for input methods would be nice too, but I don't believe that will happen (based on too much experience).
The reason X11 is slow (or rather seems slow) is because X11 is an asynchronous API.
The issue is almost certainly due to client-side bitmap composition, where X11 is definitely slow. If you can write your GUI code to keep large data on the server and do the composition there, you avoid the problems and X11 (either with a modern network or locally) is fast. Assuming you grok asynchronous programming, of course, but that's not that hard. I remember using Tk back in 1995 and it felt fast then due to clever asynchronous programming (faster than LispWorks, which was a Motif-based monstrosity that encouraged going for a long coffee while booting the environment...) We now have much faster systems, so we have no excuse for slow GUIs. Except that transfer of bitmaps between client and server is slow; that's the one place in X11 where you really do need bulk data transfer.
Of course, most of the people bitching about "too slow for modern GUIs" are people who insist on using excessive graphical glitz. I really don't need my terminal windows to be translucent surfaces; it adds nothing valuable! (Putting the WM on the same system as the server — and so able to use local private APIs for window composition — is reasonable. Most apps aren't WMs.)
Ok, say you are a rich person. Would you rather a) live in a fancy house with slums all around where you need an armed guard whenever you have to travel outside of your closed complex, or b) live in a fancy house with decent houses all around you without there being any slums and without having to pay taxes to support people who don't work because the country is wealthy enough that everybody can make a decent living with a reasonable amount of effort?
To understand the mindset of the really wealthy, realize that if it meant that they had a fancier house, they'd choose option (a) above. The ability to be conspicuously much better than the people around you is exceptionally attractive due to the way that primate dominance hierarchies work; absolute wealth matters nowhere near as much as relative wealth.
This is, of course, stupid. True though.
Play logical fallacy bingo! It also makes a great drinking game.
No, it doesn't. Your liver isn't up to that sort of punishment, not unless what you really ought to be doing is attending AA...
Tk or wxWidgets, are a bit behind the times in their capabilities and make it hard to get things to look modern.
Exactly what do you mean by modern?
He means "migraine-inducing and hard-to-use".
Then there are the rouge companies who refuse to even talk about licensing and sue directly - but they are hardly the norm.
But they have fabulous facial cosmetics!
Hydroxonium hydroxide is indeed a pest, being involved in a large number of chemical spills and a major cause of the Fukushima nuclear incident.
You may know Visa and Mastercard, through their issuers, guarantee to protect their customers from most types of fraud. If you pay by Visa and are shipped a counterfeight product, you can fill out a form and get your money back. I suspect most would agree that's good for consumers. It means, however, that Visa is ultimately on the hook for the money.
Whether or not it is Visa (or MC) that are on the hook, or the participating bank (things get really complicated under the covers), it is a critical part of the credit card system that you can do these things, as they mean that you can trust the system itself much more. While hardly perfect, it does mean that you can stand a reasonable chance to get the goods or service as described; fraudsters and crappy genuine vendors have a much harder time of it than if it was done otherwise, and that encourages people to use their credit cards which in turn benefits the credit card company themselves most overall (from things like holding payments when en route between the various parties involved on the merchant side).
Yes, Visa and Mastercard are middle men, but the service they provide — a payments system that tends to prevent a lot of fraud and which is convenient and less risky in many situations by comparison with cash — is one that many find very worthwhile using.
Or you can just use a computer, which can be programmed to automatically calculate what the overall level of "insecurity" may be in each particular case, and condense it down to a simple "blue green yellow red" type indicator, to make it easy for the user to tell at a glance what the potential risk may be....instead of overwhelming the user with dialogs full of text which the user simply isn't going to understand. Why the hell should the browser even pop up a dialog? Just flash a big red warning in the corner of the address bar or something if the site security isn't up to snuff.
Mozilla Firefox is the worst example of stupidity in this case. Whichever developers decided it would be best to scare the shit out of the user and make him jump through hoops every time a certificate isn't perfect, out to be hauled out back, lined up, and summarily given a stern talking to. What horrible UI design.
The problem is this case (from the GP):
2. The issuer of the certificate is unknown to me (the browser).
Insecurity risk: high on a public website, low on an internal site.
Action: Highlight the issuer and the website that you were trying to connec tto
User suggestion: if you recognize the issuer as someone you know (like your company) and you're connecting to the company's website, continue. If not, do not continue and disconnect your computer from the network.
The problem? Knowing whether a site is public or internal is rather hard to do. (For example, we use very many domains in our internal websites, especially ones that have substantial pieces that are also public.) I suppose you could do it by having some way of finding out (from DHCP? or maybe local DNS?) the address of a service that will describe what services are internal to you, but that's starting to get really complicated (and not widely deployed, which makes it a problem in practice).
Fortunately Carol already heard through the grapevine that Mallory is a sleazy whore, and refused to accept her certificate.
It's a good thing that certificates are only proof of identity, not proof of authority.
What the fuck difference does it make if my certificate is self signed or signed by an "authority"? What makes you think an "authority's" signature can't be faked, or backdoored?
I suggest you go away and actually try to fake or backdoor a digital signature (on something with a realistic key size and used in a proper protocol like SSL) before making that claim. While you can easily fake the Distinguished Name, the cryptographic part of the signature is really hard to fake; the easiest way to fool a client is to get it to trust a different trust root that you control so you can inject certs with the same DN as the real ones. Which is what TFA was originally about.
Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".
Operationally, a private CA works at least as well and provides an equivalent level of trust. The advantage is that the CA's private credentials can be kept offline in a safe most of the time, so they're much harder to lose, yet you don't need to futz around with adjusting clients so much when you create a new server certificate for operational use.