3,561 karma · joined May 21, 2013
Even the TTL on a.dns.whatever is set to 1min, a lot of clients ignore the TTL and use the cached value for minutes to days after TTL expiration.
"Apple awarded patent for geo-fencing profile changes to stop you texting in the theater"
https://www.engadget.com/2012/08/28/apple-geofence-profile-p...
[1] https://blog.cloudflare.com/universal-ssl-encryption-all-the...
You've just cut the number of people who can do it your way down to <1000 people (or may as well). No normal person, who wants to learn how to setup a mailserver and be successful at it, is going to drop ~$5k on a server or know people who run T1/T2 datacenters and are willing to pop you in a cage for free.
Your last sentences dismisses everyone who doesn't do things to your impossible standards as a waste.
You're basically saying no one should run a mailserver, or learn how, or be given the opportunity to learn how. Which is sad.
The number of colo providers who refuse to allow customers like VPS hosting companies (who buy rooms not just rent a piddly little 2U from a shared cabinet), is pretty small.
All in, your advice isn't tenable for the majority of technophiles, let alone your slightly-more-technical-than-average user who wants to setup a mailserver. The barrier to entry, your way, is insurmountable.
Maybe it's time for a startup in the "DIY mailserver" space, that offers clean IPs for personal use mailservers and hand-holds through the process?
Eh...this is pretty much bullshit. Unless you're running your own, good-reputation AS (or happen to know someone running a clean AS who can either lend you an IP or announce a clean block for you), the /25|/29 assigned to you by your colo provider has just as good a chance as being dirty as that VPS providers.
Your colo provider is also more than likely happily delegating blocks to one of those cheap VPS providers out of the same larger netblock your IP. Chances are even good that you'll be given a /26 or a /29 that used to be used by one of the VPS providers.
If you see a provider offering "up to 256 clean IPs!!!", those aren't clean IPs. Those are, at best, greylisted IPs bought on the cheap and at worst /22's rented from poor rep /16's and rebadged in the hope no one will notice
~all will result in your email being bounced around until accepted even if the IP doesn't match DNS records (more or less).
-all will result in hardfail if rejected by any TO mailserver.
https://web.archive.org/web/20150818043020/https://www.googl...
[1] http://leasewebnoc.com/en/networkstatus/latency-and-packet-l...
Though, amusingly enough, you could use a Google Voice number and there was no limit to the number of accounts one number could activate (at least not that I noticed).
1 http://timesofindia.indiatimes.com/tech/tech-news/Google-Yah...
Chargebacks are frequently last resorts for dealing with unscrupulous businesses or places that just don't give a shit once they've sold you what they want to sell you.
That said, chargebacks can also be used vindictively and/or fraudulently. And Visa/MC/etc could do a better job in dispute handling.
Also, worth noting, since most places are integrating payments through, e.g., Stripe, the requirements on the gateway server are much lower.
Don't get me wrong I like ZFS/btrfs; I adore snapshot send/receive. It at times though really handicaps itself.
It turns out that some raid controllers (Including the very popular LSI variety) + certain kernel versions result in pools and drives being dropped from the array for no discernible reason. Nothing [useful] to logs, just reboot and pray
Non-ECC RAM is just asking for trouble in any circumstance where you care about both data integrity and IOPS. Bitflips can and will get you, now they won't wind up hosing your entire pool (most likely) like some apocryphal stories suggest. But, you'll get bad data replicated and the possibility of borking some other sector during the 'recovery' process from the bitflip.
When you're in a large enough pool (PB-scale) this becomes even more painful...
Process shrink requires a lot of resources and R&D spending, but surely they could have benefited from not using 2008 ARM cores in 2016?
Palindromic elements are most closely related to what the linked paper is about. Basically, instead of existing as a normal double helix, the two strands separate and bind with the palindrome on the same strand; like making an X with DNA: https://en.wikipedia.org/wiki/Palindromic_sequence .
Ultimately, this is a crappy press release for a paper that, as _of points out, is scientifically correct but otherwise dull. The paper is going back to first principles, as it were, for DNA and looking at factors in DNA alone that contribute to its function (well, 'normal', non-methylated, potentially histone associated DNA).
From the paper:
> Analysis of two high resolution nucleosome maps revealed
> strong signals that—even though they do not constitute a
> definite proof—are at least consistent with such a view.
Also, the premise of this paper is clearly something only a physicist would think was interesting. And I'm not the least bit surprised this wound up in PLoS.
This just in: Modeling DNA using what we already knew about DNA confirms what we already knew about DNA.
-----
Edit: OK, I've gone back and actually read the whole paper. I can't say I'm particularly swayed by this paper and I'm not entirely sure the point. But, in a pattern I'm seeing throughout biology, a non-biologist modeler just realized that bio is cool and spent the weekend modeling something. Overall, I'm not sure what this brings to the table that merits being published?
Here's my reading of the main points:
1. Some DNA sequences are bendier than others [Not a finding of the paper, already known]
2a. There are histone binding sites and "promoters" for nucleosome formation [already known]
2b. Through modeling, Eslami-Mossallam et al., claim a major factor in nucleosome binding is whether the DNA can (thermodynamically) easily bend around the histone complex. OK, fine, the models are maybe more specific but this preference (and the motifs that comprise the hotspots) were more or less known.
3. DNA sequence determines the physical and genetic properties... Yes, we know.
4. The degeneracy of the genetic code allows it to encode additional information. We already knew this, in fact, we know the mechanical properties of RNA encode functional roles (See, programmed ribosomal frameshifts and the DNApol gmaa/tau subunits)
5. [The real shocker] DNA in real life organisms encodes both genes and its own structure.
The actual spec though, AFAIK, has no limit.