Prescriptively, maybe. But it is certainly grammatical in the sense that linguists normally use. "Try and" sounds perfectly natural to my own ears and it is regularly used by native English speakers.
I use a 43-inch 4K TV as a monitor located about 30 inches from my eyes. I've been using such for at least a decade, and would never return to a tiny porthole facing work of interest (such as a laptop, which is comically unsuited to serious, prolonged use).
I do use prescription glasses ground for that working distance and strongly recommend that (prescription lenses).
I recently (four weeks ago) had to replace the monitor/TV and spent more than a short while choosing comfortable typeface, font size, and RGB/BGR pixel ordering.
As some others have mentioned, if one's eyes are strained, corrections are warranted. I do not deliberately practice frequent distance gazing, but I suspect I do so unconsciously.
I've been using inexpensive ~40-inch-diagonal 4K (3840×2160) televisions as monitors for quite a few years and will continue to do so. Current one is TCL 43S405 (wife commandeered the Sony 43X800E). A single monitor makes for far less configuration fuss — multiple monitors coerce distinct assignments and as well introduce discontinuities in the midst of the workspace (of which I was once tolerant, but no longer). I have yet to try anything in the 50-inch diagonal range, which would likely work but the periphery might go largely unused.
Equifax Secure CA is the root CA for the certificate chain.
The intermediate CA (Google Internet Authority) issues the certificate for the end entity. Its CRL distribution point is http://crl.geotrust.com/crls/secureca.crl. There is no OCSP resource.
The relying party would validate the end-entity and intermediate CA certificates using CRLs (as no OCSP is available). These requests would be the only "data" sent as part of the certificate validation.
As the root CA is explicitly trusted (since it is present in the trust anchor compilation), it (Equifax Secure CA) is not contacted.
Explicitly removing trust for arbitrary root CAs (which can be prudent) will of course remove trust for end-entity certificates traceable to those CAs. Thus, if one removes trust for Equifax Secure Certificate Authority, one will no longer trust certificates issued by Google Internet Authority, such as the one used by https://play.google.com/store.
Trust via contemporary CA compilations and relying party PKI implementations is quite coarse. One essentially trusts all all CAs and subordinate certificates for a variety of purposes. Implementations vary in precision (or even presence) of revocation and constraint checking.
I don't think it's just a coincidence or necessarily a secret:
"Equifax Inc. (EFX), EBay Inc.'s (EBAY) PayPal and Intuit Inc. (INTU) have beguntrials to see whether social posts can help prove identities,and, in some cases, detect whether customers are lying abouttheir finances." http://finance.yahoo.com/news/facebook-posts-help-credit-bur...
Actually I remember blogging about this years ago, back when Myspace was at its peak. So it's not news. I'm just wondering if Google has revealed what data it reports to Equifax, if any. And if that's the case, I think the next question is: What sort of app activity will help improve your credit?
Also I'd like to see a "Certificate Cleaner" app that could just erase all the non-mandatory certificates. Or even better, show app-certificate associations so people could better decide which certificates they need/want/don't want. For my phone to "trust" 99 entities I've never heard of, without knowing what those certificates are for, that seems a little unsafe and irresponsible. If I didn't want choice or involvement I'd just buy an iPhone. At least I can see and disable the certificates and install another app store like F-Droid.
I use the following suffix to the /etc/ssh/sshd_config file:
…
72 #
73 # local tweaks
74 #
75 Protocol 2
76 PermitRootLogin no
77 Banner /etc/ssh/banner
78 UseDNS yes
79 MaxStartups 1
80 LoginGraceTime 15
81 PubkeyAuthentication yes
82 PasswordAuthentication no
83 ChallengeResponseAuthentication no
84 X11Forwarding yes
85 AllowTcpForwarding yes
86 DebianBanner no
87 Match Address 192.168.0.0/24,127.0.0.1,192.168.1.0/24
88 PasswordAuthentication yes
Line 82 should be commented out until you have generated an SSH key pair and placed the public key in ~/.ssh/authorized_keys, as it prevents logins using just a password. Lines 87-88 remove this restriction for local nets. Line 77 references a banner that you can provide which is presented upon SSH connection.
fail2ban with its default configuration will essentially just block objectionable SSH traffic. If you decide to extend it, create a /etc/fail2ban/jail.local file to supplement the default /etc/fail2ban/jail.conf file (the former augments the latter).
As others have mentioned, there are a number of resources available. Do not make all suggestions blindly: some are of questionable efficacy and complexity.
ufw will allow precise tuning of iptables. Watch /var/log/ufw.log for entries indicating traffic being dropped, either appropriately or not. Once more services are added (and secured), introduce related rules into ufw one by one. If your system is exposed to the general Internet, be particularly careful with such services' configurations.
The above minimal ufw commands will prevent many commonly used network services on the local network, such as CIFS. Some packages install custom ufw application definitions which can be listed with the ufw app list command (e.g., Postfix, Apache). Such applications usually open the services to all, as opposed to the just the local network.
