Can you name another hypervisor that will happily allow you to nest ESXi, and then within that XenServer? Or Hyper-V (which will generally refuse to even install on another hypervisor)?
Sure. VirtualBox does that just fine. So does kvm. I imagine it might even be possible with most Xen installs (as its possible with OpenStack, albeit performance is Bad) though it wasn't the last time I checked with XenServer, which is strictly speaking still Xen, albeit a shitty Xen.
So, that's pretty much everything except for Citrix and Microsoft hypervisors.
Where have we heard this before? Oh right, by the Jews in Germany, the Polish, etc. etc. directly prior to and somewhat during WWII. "They are our people, they would never do this to us!"
There were similar sentiments prior to the US Civil War, and, well, pretty much every genocide and civil war.
The only people who call MS support are MSPs and shops which depend on Microsoft's products working on their servers. They don't call for support on desktop issues, usually - it's usually more cost effective to just wipe it and put a newly imaged system out. No, it's the 'big ticket' systems - mail, DNS, web servers, etc. - that get all the support calls to MS.
Yes, it would be much better to simply allow things to settle down and let the little tyrant continue the deathcamp conditions prevalent throughout NK.
Either that or we should let him have the first shot. Because that would be the responsible thing to do, right?
(Do we really want him firing off his dirty bombs into SK, Japan, or who knows where else? )
Because I can buy 10 1GB/s cards for less than $100. No, they're not Intel cards. But how much demand is there for standalone Ethernet cards anymore? There's probably more market for them in the SMB sector than there is for home users, I'd wager.
And no, I really don't remember how insanely expensive 1gigE was when it hit the market. I first started getting gigE equipment in about 2001, 2002 - which was basically right after it was commercially available/mass produced. It was only a year or two old at the time, and you could get the chips on cheap motherboards from pretty much every vendor.
Likewise, buying anything more than a 1Gb ethernet card is absurdly expensive, still. Why can't I get a decent low-end single port 10Gigabit card for under $300 yet?
This competition used to be on slashdot almost every year (dating back to 2005, apparently). I'd thought it went back further than that, but that's still 8 years.
And yet, Debian, Ubuntu, RedHat, et al package 2.2 or (in the case of RHEL) 2.3 still. Why?
If the developers won't support what's being packaged for common use (even "how do I?" type questions get answered with "upgrade"), then how is the end user supposed to get any support?
I believe I've talked to you personally on the IRC channel and remember you being helpful. But you were by far the exception in that regard.
A big part of why Cyrus has its lunch eaten by Dovecot is because moving from Cyrus to anything else is just as easy, if not easier than, upgrading CyrusIMAP to a later version. Cyrus upgrade to a later version: I've more than likely got to not only upgrade my distribution but also pull down a 3rd party repository or build from source. As an added "gotcha", documentation for migration from Cyrus to anything else (well, courier or dovecot) is unimaginably better than Cyrus upgrade documentation - and markedly less complex with fewer corner cases. I've been down this road before myself, twice, and gave Cyrus good faith investigation prior to doing the migrations (I've got 3+ years Cyrus admin experience and less than a year on Dovecot/Courier). If I'm going to go to the headache of upgrading and migrating to a newer distro (as is the case when you inherit the usually-ancient Cyrus box), why not get something that has proper, standardized Maildir support and won't rape itself in rare circumstances (power outages, hardware failure)?
And dovecot is simply easier to administrate than Cyrus, largely due to the "separate metadata" issue. Night and day: I can just drop a single email they accidentially deleted from yesterday and call it good with dovecot; with cyrus, I've got to restore the whole directory and rebuild it (in all likelihood).
Yes, it's easier to get 3rd party tools which are, for all intents and purposes, sysadmin hack jobs (imapsync, IMAP Tools) working between two disparate MSAs than it is to actually upgrade Cyrus. And that I can use 'supported', non-PPA, non-3rd party packages to do so? Score.
The reason for not looking at Cyrus is, in part, because you actually have to look at the version. I've dealt with IIRC version 1.9 up through 2.2 something or other. But that's besides the point; there is a reason why RedHat has moved from Cyrus years ago, and why you won't find it : the developers don't support it unless you are on the very latest version. There are a myriad of other reasons, but of major significance:
* The tools are not well documented * the code is poorly internally documented and is mostly an unknown kludge with few developers * it uses a proprietary mail store * metadata is stored independently from the data ('for performance' they say - a problem 10+ years ago but no longer, really) * it is designed for a very narrow use case (large scale distributed installations) * there are myriad problems with upgrading due to minor db changes etc. along the way * its developers/ML/IRC channel won't help you unless you're on the current developers snapshot, or something equally asinine. * did I mention it's poorly documented? * versions offered by distros are old and crusty * nobody uses it anymore? * hardly anyone knows it
How long ago did you try it? I had similar problems very briefly when I tried it at around 0. 5.8 I believe. Performance is much better now.
Personally, I've got 3 ZoL systems here at home: a Phenom II x3 with 16GB of RAM (which is my main VM host), an AMD Bobcat with 8GB (storage/backup mainly), and an AMD XP 3200+ with 8GB of RAM (secondary/failover VM host) - all run virtualization extensions, and of the half dozen VMs which are getting used regularly (and another 8 which are always on serving various network functions - logging, SMTP, monitoring, DNS/dhcp, etc.). I've got an SSD as ZIL, and that may be part of the reason why it performs as well as it does - all of the systems are lightning fast and responsive.
It does, with a few caveats: namely, you need to have one of about 3 disk controllers to make it stable. That's the biggest one. And preferably, run it from something which has been specifically designed for ZFS, like FreeNAS instead of as 'freebsd' itself, since that's just a moving target...
This is largely inconsequential. Netflix, Prime, et al have been dropping storage systems into ISP datacenters for years. The ISP benefits because their upstream pipe is less saturated (they only need to keep their local topography 'fast', which costs a lot less) and the content provider benefits because they don't have to pay for the bandwidth to push the content to the customer at all anymore. This is how eg. Akamai operates.
Most CPUs have hardware exensions for eg. AES these days. It's easy to offload that and, often, it makes sense to have a single point at the edge of the network where that's all done (if your backend servers are numerous enough). I wouldn't be surprised if some of the DRM methods got put into silicon sooner than later...
That said, my experience has been that the biggest 'waste' of CPU cycles (and general performance) has been Indian developers who are not held responsible for their excessive use (aka abuse) of hardware. You need HOW MUCH RAM for that?! I'm sorry, I know you're writing in Java/.NET/whatever, but multiple hosts with 32GB of RAM getting maxed out by your java apps is not reasonable.
I'm being exceptionally harsh to Indian devs, because I've only seen them get away with it. Seems everyone else cares about the hardware cost, but it's only Indian developers who's development hours are more valuable than the hardware costs... maybe they're graded on quality based on number of buffer overruns and gigs of RAM used?
mbox has not been well regarded for 10 years. Maildir or Maildir+, please. And avoid cyrusIMAP at all costs.
If possible, everything mail related should be saved as Maildir or, secondly, Microsoft's OST format (which has a pretty good history of being readable).
I recently had to go back 5 years to retrieve an email as evidence in my pending divorce. "I never said that!" - like hell you didn't, I've got it right here (and here, and here, and here). She wanted to play hardball, so hardball it was.:(
I've had to go back 6+ months to retrieve important mail for myself for work and other personal matters as well. Every written correspondence with my ex-wife was in email - some damning, as above, but all of our "love letters" when we were courting. Wouldn't you want to show that to your kids one day, maybe?
I'm pretty sure he was talking about the (more common) filesystem corruption. BAM, you lose a single file (not uncommon) and that's your mbox? You're done.
This is a good recommendation, but it's got a couple "gotchas" along the road. Is he going to push it to the cloud (ie his current IMAP system, quite possibly losing access to it?
As a mail administrator (cough), I've had to do all sorts of conversions. It can be a sticky mess, and mail migrated from one client to another sometimes won't preserve all the IMAP tags (or client specific tags).
IMAP as a temporary conversion medium is most certainly going to be required, even if it's just through a google account.
I would strongly, strongly recommend he take a look at the most excellently functional IMAP Tools by Rick Sanders, who has been most helpful to me in the past when I've needed features or stumbled upon bugs or missing features. It'll do things like mbox/Maildir, etc. cross-conversion, if he wants to keep things local, or he can push it up to IMAP. There's also imapsync, but my experience is that it's significantly lesser: it's more error prone, doesn't do full conversions (IMAP tags often/usually get lost), lacks half the functionality of IMAPTools, and more likely to produce a WTF situation when it does error.
As for general approach, I personally keep everything in Maildir, segregated by year, on my file server. I can access this through a dovecot setup I've got which is really just plane jane; I've got over 100GB of mail at this point, though I too lost much of my mail from the 90s. I keep the mail system in my MUA, but unsubscribe from the archived years.
Commercial viability? No way. I wouldn't be surprised if most of their stops were required simply to 'top off' their batteries on the ground. And they'll be using a hell of a lot of fuel - in the form of electricity from batteries, which isn't measured in drops.
Also: a person make it across the US in a car in half that time, with a similar number of stops. This is, like you said, a gimmick. I'd be curious to see someone use a similar airframe (ultralight) and get across the US at a higher speed, with fewer stops, using a small gas engine - it's probably possible. That little area doesn't supply enough electricity to powerful much of anything usefully via PV, and PV cells are still quite heavy. You can run a pair of two single cylinder ICEs for a long time on 50 pounds of fuel, and I'm sure their PV setup's batteries alone are several times that.
Oh, and they probably use the grid to charge their batteries before liftoff. But that's not important.
I wonder, though: how fast could a person parasail across the US? I'm guessing that, with the right equipment, they could average at least 20mph. In the grand scheme of things, that's not that much worse than 43mph.
That wasn't 'early slavery'. Slavery existed long before that and it was often brutal. Take pretty much any religious text, they make note of slavery and slave conditions quite often.
* Fix USB device enumeration, you know, like you said you would in 8.1 * Either remove or update storage controller drivers which are no longer maintained and have been * replace sysinstall outright with something which is more likely to work consistently * fix the release cycle to have something between "cutting edge requiring a regular rebuild of the system" and "stale binaries released when the release goes STABLE, and more often than not made unavailable completely as soon as they become stable and/or vulnerable". * Would also be nice if they could make it so the all-too-common upgrade problem where you start an upgrade, but a dependency gets changed while you're upgrading and you end up half-broken (requiring you to run 2+ freebsd machines per release if you want to run one in a production state).
Of course, I'd submit these officially, but like is typical with FreeBSD, "it's your fault, there is no problem, X works fine, moving on" is likely to be the response (if there is one at all).
Yeah. I gotta love the rationale on this one. It's absurd:
It is thought that the Arctic ice loss adds heat to the ocean and atmosphere
Oh, really? You mean that's not a disprovable hypothesis, based solely on understanding of the conservation of energy?
Guess what: you put ice in a container (like, oh, a glass, a cold cellar, or the atmosphere), and it will cool off that container, absorbing heat (you know, a form of energy) for the purposes of the physical conversion back to water. This is why days in the 60+s still feel colder during the winter than a 60 degree day after, say, another 60 degree day during the summer. The ground, and the snow/ice on top of it, is melting and taking all the heat from the air.
My favorite thing about IT is getting a position where the employer knows things are falling apart around them. They don't have a preconception about "just keeping things running" - thijngs have been increasingly unworkable for some time. You get to go in there and basically cut off the fat. One of the last positions I had was such a position: I reduced the physical server count by half, most of which were simply turned off, and many were virtualized. Network infrastructure (as well as 10+ years of bad racking and cabling) was redone in a mad dash during a massive power outage that had a known 'fix by' date, working by flashlight and diesel generator.
The results were appreciable. They were able to have half-assed monkeys run the show for years afterwards without serious mishap, whereas prior to my arrival they'd been having serious problems almost daily. (And, no, it wasn't just me being awesome and slash/burning things, I had a lackey and another competent admin to help).
No, they're not long term positions (because you get bored and work yourself out of a job), but they're seriously rewarding.
Slashdot Mirror
Can you name another hypervisor that will happily allow you to nest ESXi, and then within that XenServer? Or Hyper-V (which will generally refuse to even install on another hypervisor)?
Sure. VirtualBox does that just fine. So does kvm. I imagine it might even be possible with most Xen installs (as its possible with OpenStack, albeit performance is Bad) though it wasn't the last time I checked with XenServer, which is strictly speaking still Xen, albeit a shitty Xen.
So, that's pretty much everything except for Citrix and Microsoft hypervisors.
Where have we heard this before? Oh right, by the Jews in Germany, the Polish, etc. etc. directly prior to and somewhat during WWII. "They are our people, they would never do this to us!"
There were similar sentiments prior to the US Civil War, and, well, pretty much every genocide and civil war.
The only people who call MS support are MSPs and shops which depend on Microsoft's products working on their servers. They don't call for support on desktop issues, usually - it's usually more cost effective to just wipe it and put a newly imaged system out. No, it's the 'big ticket' systems - mail, DNS, web servers, etc. - that get all the support calls to MS.
Yes, it would be much better to simply allow things to settle down and let the little tyrant continue the deathcamp conditions prevalent throughout NK.
Either that or we should let him have the first shot. Because that would be the responsible thing to do, right?
(Do we really want him firing off his dirty bombs into SK, Japan, or who knows where else? )
The problem is, that is precisely what OpenNebula (ONE) is, as well, at least in part. :P
Because I can buy 10 1GB/s cards for less than $100. No, they're not Intel cards. But how much demand is there for standalone Ethernet cards anymore? There's probably more market for them in the SMB sector than there is for home users, I'd wager.
And no, I really don't remember how insanely expensive 1gigE was when it hit the market. I first started getting gigE equipment in about 2001, 2002 - which was basically right after it was commercially available/mass produced. It was only a year or two old at the time, and you could get the chips on cheap motherboards from pretty much every vendor.
So what exactly is Nebula? That article is horrible.
Is it just me, or does this new 'cloud' tool have absolutely nothing to do with OpenNebula (which abbreviates itself ONE), a competitor to OpenStack?
Likewise, buying anything more than a 1Gb ethernet card is absurdly expensive, still. Why can't I get a decent low-end single port 10Gigabit card for under $300 yet?
You must be new here.
This competition used to be on slashdot almost every year (dating back to 2005, apparently). I'd thought it went back further than that, but that's still 8 years.
And yet, Debian, Ubuntu, RedHat, et al package 2.2 or (in the case of RHEL) 2.3 still. Why?
If the developers won't support what's being packaged for common use (even "how do I?" type questions get answered with "upgrade"), then how is the end user supposed to get any support?
I believe I've talked to you personally on the IRC channel and remember you being helpful. But you were by far the exception in that regard.
A big part of why Cyrus has its lunch eaten by Dovecot is because moving from Cyrus to anything else is just as easy, if not easier than, upgrading CyrusIMAP to a later version. Cyrus upgrade to a later version: I've more than likely got to not only upgrade my distribution but also pull down a 3rd party repository or build from source. As an added "gotcha", documentation for migration from Cyrus to anything else (well, courier or dovecot) is unimaginably better than Cyrus upgrade documentation - and markedly less complex with fewer corner cases. I've been down this road before myself, twice, and gave Cyrus good faith investigation prior to doing the migrations (I've got 3+ years Cyrus admin experience and less than a year on Dovecot/Courier). If I'm going to go to the headache of upgrading and migrating to a newer distro (as is the case when you inherit the usually-ancient Cyrus box), why not get something that has proper, standardized Maildir support and won't rape itself in rare circumstances (power outages, hardware failure)?
And dovecot is simply easier to administrate than Cyrus, largely due to the "separate metadata" issue. Night and day: I can just drop a single email they accidentially deleted from yesterday and call it good with dovecot; with cyrus, I've got to restore the whole directory and rebuild it (in all likelihood).
Yes, it's easier to get 3rd party tools which are, for all intents and purposes, sysadmin hack jobs (imapsync, IMAP Tools) working between two disparate MSAs than it is to actually upgrade Cyrus. And that I can use 'supported', non-PPA, non-3rd party packages to do so? Score.
The reason for not looking at Cyrus is, in part, because you actually have to look at the version. I've dealt with IIRC version 1.9 up through 2.2 something or other. But that's besides the point; there is a reason why RedHat has moved from Cyrus years ago, and why you won't find it : the developers don't support it unless you are on the very latest version. There are a myriad of other reasons, but of major significance:
* The tools are not well documented
* the code is poorly internally documented and is mostly an unknown kludge with few developers
* it uses a proprietary mail store
* metadata is stored independently from the data ('for performance' they say - a problem 10+ years ago but no longer, really)
* it is designed for a very narrow use case (large scale distributed installations)
* there are myriad problems with upgrading due to minor db changes etc. along the way
* its developers/ML/IRC channel won't help you unless you're on the current developers snapshot, or something equally asinine.
* did I mention it's poorly documented?
* versions offered by distros are old and crusty
* nobody uses it anymore?
* hardly anyone knows it
How long ago did you try it? I had similar problems very briefly when I tried it at around 0. 5.8 I believe. Performance is much better now.
Personally, I've got 3 ZoL systems here at home: a Phenom II x3 with 16GB of RAM (which is my main VM host), an AMD Bobcat with 8GB (storage/backup mainly), and an AMD XP 3200+ with 8GB of RAM (secondary/failover VM host) - all run virtualization extensions, and of the half dozen VMs which are getting used regularly (and another 8 which are always on serving various network functions - logging, SMTP, monitoring, DNS/dhcp, etc.). I've got an SSD as ZIL, and that may be part of the reason why it performs as well as it does - all of the systems are lightning fast and responsive.
It does, with a few caveats: namely, you need to have one of about 3 disk controllers to make it stable. That's the biggest one. And preferably, run it from something which has been specifically designed for ZFS, like FreeNAS instead of as 'freebsd' itself, since that's just a moving target...
This is largely inconsequential. Netflix, Prime, et al have been dropping storage systems into ISP datacenters for years. The ISP benefits because their upstream pipe is less saturated (they only need to keep their local topography 'fast', which costs a lot less) and the content provider benefits because they don't have to pay for the bandwidth to push the content to the customer at all anymore. This is how eg. Akamai operates.
Most CPUs have hardware exensions for eg. AES these days. It's easy to offload that and, often, it makes sense to have a single point at the edge of the network where that's all done (if your backend servers are numerous enough). I wouldn't be surprised if some of the DRM methods got put into silicon sooner than later...
That said, my experience has been that the biggest 'waste' of CPU cycles (and general performance) has been Indian developers who are not held responsible for their excessive use (aka abuse) of hardware. You need HOW MUCH RAM for that?! I'm sorry, I know you're writing in Java/.NET/whatever, but multiple hosts with 32GB of RAM getting maxed out by your java apps is not reasonable.
I'm being exceptionally harsh to Indian devs, because I've only seen them get away with it. Seems everyone else cares about the hardware cost, but it's only Indian developers who's development hours are more valuable than the hardware costs... maybe they're graded on quality based on number of buffer overruns and gigs of RAM used?
mbox has not been well regarded for 10 years. Maildir or Maildir+, please. And avoid cyrusIMAP at all costs.
If possible, everything mail related should be saved as Maildir or, secondly, Microsoft's OST format (which has a pretty good history of being readable).
I recently had to go back 5 years to retrieve an email as evidence in my pending divorce. "I never said that!" - like hell you didn't, I've got it right here (and here, and here, and here). She wanted to play hardball, so hardball it was. :(
I've had to go back 6+ months to retrieve important mail for myself for work and other personal matters as well. Every written correspondence with my ex-wife was in email - some damning, as above, but all of our "love letters" when we were courting. Wouldn't you want to show that to your kids one day, maybe?
I'm pretty sure he was talking about the (more common) filesystem corruption. BAM, you lose a single file (not uncommon) and that's your mbox? You're done.
This is a good recommendation, but it's got a couple "gotchas" along the road. Is he going to push it to the cloud (ie his current IMAP system, quite possibly losing access to it?
As a mail administrator (cough), I've had to do all sorts of conversions. It can be a sticky mess, and mail migrated from one client to another sometimes won't preserve all the IMAP tags (or client specific tags).
IMAP as a temporary conversion medium is most certainly going to be required, even if it's just through a google account.
I would strongly, strongly recommend he take a look at the most excellently functional IMAP Tools by Rick Sanders, who has been most helpful to me in the past when I've needed features or stumbled upon bugs or missing features. It'll do things like mbox/Maildir, etc. cross-conversion, if he wants to keep things local, or he can push it up to IMAP. There's also imapsync, but my experience is that it's significantly lesser: it's more error prone, doesn't do full conversions (IMAP tags often/usually get lost), lacks half the functionality of IMAPTools, and more likely to produce a WTF situation when it does error.
As for general approach, I personally keep everything in Maildir, segregated by year, on my file server. I can access this through a dovecot setup I've got which is really just plane jane; I've got over 100GB of mail at this point, though I too lost much of my mail from the 90s. I keep the mail system in my MUA, but unsubscribe from the archived years.
Commercial viability? No way. I wouldn't be surprised if most of their stops were required simply to 'top off' their batteries on the ground. And they'll be using a hell of a lot of fuel - in the form of electricity from batteries, which isn't measured in drops.
Also: a person make it across the US in a car in half that time, with a similar number of stops. This is, like you said, a gimmick. I'd be curious to see someone use a similar airframe (ultralight) and get across the US at a higher speed, with fewer stops, using a small gas engine - it's probably possible. That little area doesn't supply enough electricity to powerful much of anything usefully via PV, and PV cells are still quite heavy. You can run a pair of two single cylinder ICEs for a long time on 50 pounds of fuel, and I'm sure their PV setup's batteries alone are several times that.
Oh, and they probably use the grid to charge their batteries before liftoff. But that's not important.
I wonder, though: how fast could a person parasail across the US? I'm guessing that, with the right equipment, they could average at least 20mph. In the grand scheme of things, that's not that much worse than 43mph.
If you have to ask, or if there's question in your mind, you probably are.
That wasn't 'early slavery'. Slavery existed long before that and it was often brutal. Take pretty much any religious text, they make note of slavery and slave conditions quite often.
Oh, I only have a couple:
* Fix USB device enumeration, you know, like you said you would in 8.1
* Either remove or update storage controller drivers which are no longer maintained and have been
* replace sysinstall outright with something which is more likely to work consistently
* fix the release cycle to have something between "cutting edge requiring a regular rebuild of the system" and "stale binaries released when the release goes STABLE, and more often than not made unavailable completely as soon as they become stable and/or vulnerable".
* Would also be nice if they could make it so the all-too-common upgrade problem where you start an upgrade, but a dependency gets changed while you're upgrading and you end up half-broken (requiring you to run 2+ freebsd machines per release if you want to run one in a production state).
Of course, I'd submit these officially, but like is typical with FreeBSD, "it's your fault, there is no problem, X works fine, moving on" is likely to be the response (if there is one at all).
Yeah. I gotta love the rationale on this one. It's absurd:
It is thought that the Arctic ice loss adds heat to the ocean and atmosphere
Oh, really? You mean that's not a disprovable hypothesis, based solely on understanding of the conservation of energy?
Guess what: you put ice in a container (like, oh, a glass, a cold cellar, or the atmosphere), and it will cool off that container, absorbing heat (you know, a form of energy) for the purposes of the physical conversion back to water. This is why days in the 60+s still feel colder during the winter than a 60 degree day after, say, another 60 degree day during the summer. The ground, and the snow/ice on top of it, is melting and taking all the heat from the air.
My favorite thing about IT is getting a position where the employer knows things are falling apart around them. They don't have a preconception about "just keeping things running" - thijngs have been increasingly unworkable for some time. You get to go in there and basically cut off the fat. One of the last positions I had was such a position: I reduced the physical server count by half, most of which were simply turned off, and many were virtualized. Network infrastructure (as well as 10+ years of bad racking and cabling) was redone in a mad dash during a massive power outage that had a known 'fix by' date, working by flashlight and diesel generator.
The results were appreciable. They were able to have half-assed monkeys run the show for years afterwards without serious mishap, whereas prior to my arrival they'd been having serious problems almost daily. (And, no, it wasn't just me being awesome and slash/burning things, I had a lackey and another competent admin to help).
No, they're not long term positions (because you get bored and work yourself out of a job), but they're seriously rewarding.