Of all the stupid features from Chrome to pick up, the version numbers is, by far, the dumbest. Has anyone considered how stupid a version number in the high double digits might be? Firefox 81 seems kind of clunky, doesn't it?
Yes, it does. However, "Firefox 451", "Firefox 666", and "Firefox 911" (as in Porsche, not terrorism) seem kinda catchy to me, so maybe they should skip double digits and go straight to triple.
Do we forget about Sanford Wallace so soon?
Or Jeremy Jaynes?
Use authenticated smtp - its at port 584
Of course, the server to server communication all runs on 25 still..
You're thinking of 587, which is for MUA submission. This is not for server to server SMTP communication. This will not help the OP.
A lot of companies offer static ips for which you can set all the reverse dns & email information, and they are also out of their normal subscriber pool, thus allowing you to send emails from the computer behind it. The cost of that option is usually lower than 5$ per ip per month around here.
It's $10/month extra for a single static IP atop aDSL from CenturyTel here in rural Northwest Missouri. They have a local monopoly but so far their pricing is reasonable and the service is top notch--not a single outage in the past year. CenturyTel doesn't offer custom rDNS, period, neither for small business nor residential accounts. So far this hasn't been a problem. No reputable DNSBL will list an IP strictly due to generic rDNS. And CenturyTel doesn't register the parent block with the Spamhaus PBL nor any other "DUL" type DNSBLS. Neither my IP nor parent net have been listed by any reputable DNSBL. I noticed the parent net was listed on, IIRC, one of the super aggressive fiveten lists some time ago, but that didn't obviously affect delivery as nobody in their right mind outright blocks using these fiveten lists. I registered my IP with dnswl.org quite some time ago and have a 'medium' rating, which helps with delivery in cases where receivers do block based on things like generic rDNS.
221.216.41.65.list.dnswl.org. 43200 IN A 127.0.6.2
So far I've had zero problems with outbound delivery over this CenturyTel aDSL. Having a static IP is more important for deliverability than custom rDNS, but it's good to have both if you can get them. If you have static IPs and are being listed in "policy" DNSBLs, you need to talk to your ISPs and get that straightened out. If you have static IPs and you're being listed by trap driven DNSBLs, then the problem isn't with "what type of service you have" but with spam emission from zombie infected PCs behind your NAT. In this case YOU need to egress filter TCP 25 so nothing can send outbound SMTP but your mail server.
Maybe yes, maybe no. The big loser in this would be Intel. I'm not sure of the % of Dell computers that ship with AMD CPU's but it's certainly less than 25%. Dell is big enough to hurt Intel if they switch to AMD.
Which is why this "story" is purely rumor. This is simply a move by Dell to get _much_ better pricing out of Intel. Dell has no intention of actually buying AMD. They wouldn't know how to run the combined company if they did. Look at Dell's roots. Dell is a build-to-order firm, not a bottom-to-top manufacturing company.
Just wait until "ipv6 conversion specialists" are charging you $450 an hour to make sure your business is not floundering because you ignored the problem until it was an emergency.
Would you mind describing such an "emergency" situation, in detail? The only "emergency" scenario I can think of here is if your ISP/upstream dictated that within, say 90 days, they would no longer route your IPv4 traffic. The flaw in assuming such a scenario is that no ISP/upstream has a positive financial stake in doing this. They gain nothing by taking away your IPv4 abilities. In addition, if said ISP/upstream really was determined to do this, they'd simply send out an engy to install a v6/v4 gateway router. Problem solved, no material change for the customer. Note this last point carefully, because this is what the US "IPv6 conversion" will look like at almost all organizations, and most orgs worldwide with a substantial v4 installed base.
Note the U.S. government for example, and it's millions of v4 devices. If they started a wholesale conversion to v6 tomorrow, how many years, and how many 10s of billions of dollars would be consumed before the project is completed?
The people screaming like Henny Penny have no clue what kind of costs are involved in such a conversion to v6. And apparently they don't realize that most organizations that actually need large blocks of public addresses already have more than they need. Look at all the
To make more addresses available for new users (China, worldwide wireless phone carriers), what the IETF should have done before creating this new whiz-bang v6 stack is to convert the multicast and "future use" subnets (no one uses multicast anyway) to standard subnets. Changing all the v4 stacks to recognize these subnets as normal routable nets would yield an additional 536,870,912 usable addresses, and would be a much easier change to implement--would be a simple patch to all existing v4 stacks. For devices such as network printers et al inside the perimeter, one wouldn't even need to change the firmware.
That's called a feedback loop, or FBL. These have been around a long time. Most ISPs and gorilla mailers have been using them for many years. They aren't a magic bullet against spam--far from it. An FBL is simply analogous to walking over to your neighbor's house and telling him his son just threw a rock through your window. The dad isn't able to keep tabs on his kid all the time. Same with an ISP, freemailer, or in this case, Amazon. The FBL is simply an extra set of eyes and ears.
Grötschel, an expert in optimization, observes that a benchmark production planning model solved
using linear programming would have taken 82 years to solve in 1988, using the computers and the linear
programming algorithms of the day. Fifteen years later – in 2003 – this same model could be solved in
roughly 1 minute, an improvement by a factor of roughly 43 million. Of this, a factor of roughly 1,000 was
due to increased processor speed, whereas a factor of roughly 43,000 was due to improvements in algo-
rithms! Grötschel also cites an algorithmic improvement of roughly 30,000 for mixed integer programming
between 1991 and 2008.
The prof is fibbing. The gains are mostly in the big on-die L2 cache with its fat, core clocked dedicated backside bus (thanks to Intergraph, and Intel for stealing it from them, then AMD, IBM, et al). The prof simply shrunk the code and data set to fit (mostly or wholly) in the 512KB/1MB cache of their 2003 era Athlon XP/Pentium IV. As with most apps, it's all in the ca$he baby, all in the ca$he.
SMTP needs a ground up re-write, and it will need it just as much (if not more) after IPV6 is deployed.
SMTP isn't the problem and is not in need of a ground up rewrite. The problem is social, between spammers and suckers, their victims. As has been shown via NNTP, instant messaging, and Facebook spam et al, there is no technology immune to spam. Spam will be with us as long as suckers exist, and there are people willing to exploit those suckers. Yes, basically for eternity.
There will start to be IPv6 dnsbls and mail OPs will start keeping IPv6 local block lists. It's the same old game with a new numbering scheme. As for multilayer NAT I don't see it being a problem WRT SMTP. As others have stated it will be relegated to consumer broadband ISP space and possibly colocation centers, which most mail OPs already outright SMTP block (if they're smart).
1: it's a dick-wagging contest to have the best supercomputer in the world..
Absolutely correct. This was clearly demonstrated by the accelerated funding and freebie process that occurred when NASA was building its first SGI Altix monster, including emergency meetings with the Governor or California's office, the DOE directors office, Intel, and SGI. The build of that machine would have normally taken a year using the normal method of assembly, construction, and testing. They cut it to less than six months with one goal in mind, and it wasn't science. It was to get a sufficient number of Linpack runs in, and tune for a final couple of "peak" runs simply so they could send results to Dongarra before the deadline for the upcoming TOP 500 list.
They thought they were going to take the #1 spot, because they weren't paying attention to their "competition", which IIRC included the first BlueGene machine from IBM (which took the #1 spot on that list). The NASA "Columbia" Altix supercomputer ended up at #3 on that list. Intel and SGI lost a *bunch* of money on that system just to get the #1 spot on the list. And they didn't. Meaning they lost all that money for nothing. For Intel this didn't mean much. For SGI, well, we all know Rackable bought them for only $45 million--less than the price of the Columbia machine. This wasn't the first "deeply discounted" system SGI shipped, and when you add up all these deals, you understand their near bankruptcy situation, and sale for a song to Rackable. That was a very sad deal...
i cannot believe that IBM or other U.S. vendors instead of Sony would not have been capable of crafting such a system... quite telling, IMO
They have, almost 5 years ago, actually. You are simply uninformed, haven't been paying attention:
http://www-03.ibm.com/press/us/en/pressrelease/19198.wss
http://www-03.ibm.com/systems/bladecenter/hardware/servers/qs22/index.html
And the IBM Cell blade has a Cell chip, the PowerXCell 8i, with 1 extra SPE, 5 times the double precision floating point performance, and with the Infiniband HCA, over 50 times faster network communications.
Where have you been these past 5 years?
RoadRunner, http://www.lanl.gov/discover/roadrunner_fastest_computer
has over 13,000 PowerXCell 8i chips which are 4 times faster than the PS3 Cell chip on FP code. RR executes Linpack at 1.04 PetaFLOPS/s, just over double what AFRL is claiming for their little bullshit 1760 Cell cluster. If AFRL is quoting PEAK hardware performance, their 1760 PS3s would hit a mere 180 TFLOPS/s, far short of that 500 figure. The head nodes they mention would add another 10 TFLOPS/s peak. They didn't specify the number and type of GPUs in the cluster. Even so, they're still not going to hit 500 TFLOPS/s, nowhere close to it running any application, and not close to it if quoting PEAK hardware numbers.
Those Air Force boys must be smoking some good weed these days to hallucinate that 500 TFLOPS/s figure.
Regardless of what you install there's no guaranteed way to stop your kid from stumbling upon boobs on the internet. Plus who's to say it's something to worry about at all. They certainly didn't traumatize me.
What happens when the kid has already turned off Google Safe Search, then searches for "rooster" as they discussed chickens and roosters in class that day, at age 5. Rooster gives "cock" as a synonym, so he searches "cock". Then he hits the images button. Some of what he sees _will_ be traumatizing and will prompt questions to the parents. This is a far cry from coming across an issue of Playboy and seeing boobs as you and I did as youngsters. Google and the web are a game changer here and the potential for trauma is high, as well as other consequences.
all the Candian jokes are nice and all.. but this really was about trying to make people think CERN is the only thing going on in HEP or nuclear physics. Not so, and this is not a first as RHIC was there first. Glad to see CERN is catching up though.
I thought the big deal with the LHC is that it was supposed to give us the Higgs Boson, as no other collider on earth was powerful enough to create the Higgs. Enough about this QGP junk. Where's our Higgs Boson?
If your SAN array(s) are of any size (10TB+) with lots of drives (8 or more) you should take another look at XFS. The version of RHEL you were using is eons old now, shipped with kernel 2.6.18 from 2003, and probably didn't have the 2007 fixes. Also, if you were running your / filesystem on XFS, that's not recommended, because most Linux distros don't have the right integration for doing so, as you learned. Run / on EXT2/3 and your data filesystems on XFS. / filesystems aren't write transaction heavy, and don't experience lots of random IO, merely log writes, so you get zero benefit from XFS, and you can experience integration headaches, depending on your distro.
XFS is currently the most heavily developed FS on the planet, more than BTRFS. It also has superior performance to all other filesystems with almost every workload. Even more so with the recent delay log option. When configured and managed properly, it is also one of the most robust filesystems available. It is very widely deployed, especially on massive DB servers, due to its superior performance with O_DIRECT.
If you had corruption issues, not merely trunc'd files, in the past two years, then you were running an OS without the 2007 patch.
Were there fewer fools, knaves would starve. - Anonymous
