Wikipedia:Reference desk/Archives/Computing/2015 August 20

= August 20 =

Screen that would consume less energy with black background
Does any laptop screen consumes less power if you have a black background? That means, can any laptop screen turn pixels off, when the only thing you want is black? --YX-1000A (talk) 07:30, 20 August 2015 (UTC)


 * Your regular LCD screen lights up its pixels with a full screen backlight (most commonly an aray of LEDs), that doesn't care what colour pixels are shining through it, it'll light the screen with the same brightness across the display. The only screen technology I know of that doesn't do this is OLED where the pixels themselves emit light, and thus black pixels aren't lit up at all. However, OLED displays are expensive and a laptop with an OLED screen would be very costly right now, if they do exist. It's worth noting however that even with an LED backlit LCD screen the power usage demanded by the backlight is very small 81.138.15.171 (talk) 08:26, 20 August 2015 (UTC)


 * See and . Apparently most LCD/LED panels need slightly more power for black than for white. A number of sources say that this is inherent in the nature of LCD, but I think that's wrong: the liquid crystal layer doesn't block light, it just rotates the polarization, so you can swap black and white by changing the alignment of the polarizing layers on either side. It may be that most manufacturers choose to make white cheaper because most screens display more white than black these days.
 * Some LED-backlit TVs can selectively dim the backlight in parts of the screen. They do it to improve the contrast ratio, but it may also save power. I don't know whether any laptop screens do this. -- BenRG (talk) 10:01, 20 August 2015 (UTC)


 * It isn't necessarily the LED light that consumes much of the power. It you really want to see for your specific TV (because everyone wants anecdotes, not data), get something like a Kill-a-watt power meter. Run your TV for an hour and look at the power consumption. Then, turn it off and let it sit for an hour. Look at the power consumption. My old LCD TV was 110W when on and 130W when off (yes - more when off - checked repeatedly to prove it was a crap TV). My new TV is 190W when on and 70W when off - but it is plasma, not LCD. By looking at the "on" vs "off" consumption, you will see the maximum amount of power used by the LEDs. The difference isn't all the power used by the LEDs, but it is an upper limit. I expect you will find it to be very small (or negative, like my old TV). 209.149.114.69 (talk) 16:21, 20 August 2015 (UTC)

Do web servers these days tend not to accept telnet conversations?
I was using an Introduction to Apache book from 2003 that had a subsection entitled "Do It Yourself HTTP" which said "Connect via telnet to www.apache.org (or your favorite Web site) at port 80, and type . Press the Enter key twice. You will get the response shown in Listing 1.3..." and the listing shows a bunch of stuff like date, server, cache-control, expires, more stuff, and then the HTML of the page. But when I tried using Microsoft telnet, it never responded. I tried putty and at least saw they responded with 400 Bad Request, same with another telnet program called EasyTerm that the book recommended that still exists. I got the same results of failure with a number of other websites. Do most web servers these days refuse telnet connections? 20.137.7.64 (talk) 13:07, 20 August 2015 (UTC)


 * A server can't tell the difference (because there isn't a difference) between a socket connection opened by a telnet client and by a web browser; so it's not in a position to discriminate. But what happens when you push the ENTER key may vary between clients - HTTP expects header lines separated by carriageReturn+lineFeed. and the header closing with a blank line (so that's why the book says to push ENTER twice). But an telnet client (which equally doesn't know it's doing http) might only send a CR or a LF when the enter key is pressed. And some HTTP servers might "help" by bending the rules and listening only for the LF. You might find a configuration setting in the Microsoft telnet client which allows you to set what byte sequence it transmits when enter is pressed; "line termination" is the usual term for this. -- Finlay McWalterᚠTalk 14:02, 20 August 2015 (UTC)
 * I think the telnet protocol requires Enter to be transmitted as CRLF, though it isn't entirely clear to me. In any case, the real problem is that telnet ≠ raw TCP (see my reply below). -- BenRG (talk) 17:30, 20 August 2015 (UTC)


 * If you telnet to apache.org on port 80 and type GET / HTTP/1.0 and press enter twice, you will get the web page code. If you get 400 Bad Request, you typed something wrong. To verify, I just did it from my Linux box, from a Oracle appliance, from a telnet app on my Android phone, and from Putty on a Windows machine. All worked fine. 209.149.114.69 (talk) 14:04, 20 August 2015 (UTC)
 * PuTTY telnet on Windows doesn't work for me: it sends a bunch of control codes on connect (which is encouraged by the telnet spec: "Option requests are likely to flurry back and forth when a TELNET connection is first established"...). Apache returns 400 Bad Request because the request started with control codes instead of GET. You can't rely on arbitrary telnet clients working for this, just the ones people used historically to get around the nonexistence of netcat. -- BenRG (talk) 17:30, 20 August 2015 (UTC)


 * Maybe I shouldn't have mentioned the GET line, because I'm not even getting to that point. I can't connect at all. When I type  on the cmd line, or   after specifically running telnet, it hangs for about a minute before saying connection refused. And with putty, if I enter www.apache.org in the host box, and enter 80 in the port box, and select the telnet radio button, and select the close on: never radio button so I can read what shows up in the terminal window after it fails, and then press the Open button, I get the 400 Bad request before I ever even got to having a terminal to type the Get command into. But of course I have Internet (I can ping it, open it in a browser, and I'm typing here on this Internet website) 20.137.7.64 (talk) 14:09, 20 August 2015 (UTC)


 * I tried it in Microsoft telnet on Windows 10, and it does work - but it doesn't display "connected to", and it doesn't locally echo the characters you're typing, so you're typing in the blind. I think you are getting connected, but because of the lack of these messages you're mistaking that for a lack of a connection. You can overcome the echo problem by entering SET LOCALECHO before the OPEN line, but not I think the former. -- Finlay McWalterᚠTalk 14:36, 20 August 2015 (UTC)


 * OK, thanks. It looks like I was connected while I only saw "connecting...". I typed my GET line and pressed enter twice and saw a bunch of HTML whoosh across the screen and by the time it stopped, I could see that most all of it looked like it was from the intended site. Unfortunately, Microsoft's terminal window when in telnet doesn't have a large enough buffer to be able to scroll all the way back up for sites with a lot on them. So I tried it telnetting to www.something.com, and it worked. I'm using Windows 7, btw. 20.137.7.64 (talk) 14:50, 20 August 2015 (UTC)


 * Web/HTTP servers have never spoken the telnet protocol. Some telnet clients (apparently including Microsoft's) don't send any telnet control messages as long as you type only ASCII characters and Enter, and hence may work. Some (including PuTTY) do send control messages and hence won't work. People used telnet for this purpose historically only because they lacked better tools. In this modern age, you should use putty -raw or ncat --crlf. (plink -raw doesn't send CRLF on Enter, probably because it's designed for piping binary data, so it probably won't work.)


 * Thanks! I just wanted to see the text for myself that the figure showed doing a GET to www.apache.org and doing raw with putty worked. Better buffer than Microsoft. 20.137.7.64 (talk) 17:15, 20 August 2015 (UTC)


 * Yeah, this is the result of a historical legacy that tends to confuse people who learn about it today. Telnet is ancient in computing terms. It dates back to the 1960s, and was one of the first things used on ARPANET. The basic architecture of telnet involves simply hooking up a byte stream to TCP. Back in the day, the stream would be passed to the physical terminal the user was sitting at. Because of this, it's often possible to use a telnet client as a rudimentary raw TCP client. But as noted above, and in the telnet article, this was never explicitly the goal of telnet, so it's not mandatory that a client work in such a fashion, and there are plenty of corner cases with encodings and control characters and all that. Ideally you want to use something like netcat that is explicitly designed to be a raw client. --108.38.204.15 (talk) 19:16, 20 August 2015 (UTC)

I took a TCP/IP programming course at university once, and one of the exercises was to write a UNIX C program talking to a server operated by the instructor and obeying its commands. When I first opened a Telnet connection to the server, it immediately responded with "Sorry, I don't like Telnet clients, or the like" and closed the connection. Doing the entire TCP/IP connection by hand in C code worked. How was the server able to distinguish between a Telnet client and a TCP/IP client written by hand? J I P &#124; Talk 19:40, 21 August 2015 (UTC)

Blocking email attachments on an iPhone 4s running iOS 8.3
I have a friend overseas for whom I have asked questions here before. My friend has an extremely expensive data plan (a recent unsolicited 3MB image attachment cost $4.10 for the size of the file and time sent downloading--this is about one week's budget for discretionary spending). The state has a phone monopoly, so switching providers or plans is not an option.

What my friend is wondering is, on an iPhone 4s running iOS 8.3 with the default email app, is there some way to block emails with attachments?

The problem at this point is that only after a huge file is downloaded does my friend become aware that there is a huge attachment. Any information on if blocking such emails or the attachments ahead of time would be appreciated. Thanks. μηδείς (talk) 21:21, 20 August 2015 (UTC)
 * There seems to be some suggestions that might work here. Vespine (talk) 23:01, 20 August 2015 (UTC)


 * Here's instructions to prevent loading of remote images in email - not quite the same, but will save on data usage. Here's another relevant thread . It might be easier to avoid the iOS mail.app in favor of the Gmail app, which has more control over this sort of thing . SemanticMantis (talk) 14:11, 21 August 2015 (UTC)


 * Unfortunately this person (a former regular here) does not have general web access or the ability to sign up for gmail. I have no idea about iPhones, as I have a tracfone for emergencies, and do not text or browse, just talk on the phone.  I'll see if I can get the actual name of what was described as the default email app above.  The link Vespine gave (which gives the same info as SM's first link) applies to Macs, not iPhones, although I thought it looked promissing.  I'll update as soon as I can get the name.  Thanks for the help so far. μηδείς (talk) 22:21, 21 August 2015 (UTC)
 * i'm a little confused... what attachments are we talking about? I have an iphone and granted I have a gmail account set up on it, but I don't see why that would have different settings to any other email provider. My email does not download attachments automatically, whether it is a large image or a pdf file, I have to click the pdf file to down load it, it doesn't just download by it self, and as for images, there IS a setting, under settings > mail, contacts and calendars, there is an option called "load remote images", mine is off.. Vespine (talk) 06:01, 25 August 2015 (UTC)