Yes, before I brought this question to Slashdot, I did my homework first. I've scoured logs, check RBLs, used wireshark, etc. It's definitely not a misconfiguration on my end or an issue with complaints resulting from spam.
One change you can make is to configure the outbound NAT from your mail server to appear to come from a different one of your static public IP addresses. Change your DNS to match, and see if that helps at all.
If it doesn't, then perhaps as others have said, you are collateral damage from nearby IP addresses. Has your IP block been allocated to you? If so, you can usually use the WHOIS info to convince the other end that you aren't related to the collateral IP address.
Deferred: 421 4.7.1 [TS03] All messages from XXX.XXX.XXX.XXX will be permanently deferred; Retrying will NOT succeed.
Not that this will likely help you, but you're probably completely screwed, since Yahoo doesn't even care they are intentionally violating the RFC.
All 4xx response codes are for messages that can't be delivered right now, but some condition change will allow them to be delivered. The text of their message implies that the response code should have been a 5xx. This sort of behavior is usually done in response to spam (foolishly, since most spambots never retry) in an attempt to waste the resources of the sending server by causing it to retry.
The Microsoft response might be legitimate if their systems think that you are sending "too much" e-mail.
My local brick and mortar store are automatically at a 7% price disadvantage because they have to include sales tax to items purchased where online retails don't.
No, your local brick and mortar store is at a 15-30% disadvantage simply because they charge a lot more for most things.
I just bought a gaming headset at a local B&M because I wasn't sure if it would work for me (comfort, quality, etc.) and wanted an easy return if I had to. For that, I paid 44% more than if I had purchase the item from Amazon. This is not an unusual situation, at least as far as tech is concerned, with Amazon, NewEgg, SuperBiiz, etc., all fighting for my online purchases.
Also, Amazon charges tax in my state, so that part doesn't even enter into the decision to buy online.
It's not just an issue of understanding, it's apathy and laziness.
Yes, laziness on the part of the programmers of the device.
The default password should allow you to access exactly one function on the device: the "pick a username and password for a new admin" feature. Once that finishes, either the default password is set to cat </dev/urandom > password_storage_file or else the default user is removed. In case you forget the username and password you set, the device can be reset to factory defaults using some sort of physical "reset" button.
Just because a door is unlocked does not mean you may walk inside, even if it is to tell the owner their door is unlocked.
This is a good analogy, because it is impossible to tell if a door is unlocked (or if a camera has the default username/password) without trying to open the door.
So, what your advice boils down to is that you never can accurately inform someone their door (system) is unlocked..
So you don't think that a combination of factors such as where you live, how much you get paid, relative market rates, current job market conditions, your recent payrises, your recent year end appraisal scores, where your partner works, your age, your time since last promotion or anything else the company has or can easily gain access to would be an indicator of how likely you are to leave?
Not for some jobs. In a lot of the tech world, the algorithm would be pretty much exactly as the GP listed, at least for talented people who are desired by employers.
And, what does the company do when "big data" says somebody is or isn't going to leave in the next year? If they use just that metric, the will find out that a lot of people who they thought weren't going to leave end up gone..."we don't need to give him that big of a raise...the computer says he won't leave anyway". Or, "hey, we better find a cheaper replacement for this guy, because he's leaving in the next year" will be a lot more likely than giving the guy what it takes to keep him.
Then, too, there's a lot of employees who won't ever leave their existing job because they can't do any better anywhere else. Sadly, many of those people are the ones that you might want to encourage to leave.
This is the first season that any electronic device could be used by coaches and players during an NFL game. They weren't using iPads before...they were using steno pads.
That's code for "we pay well under market", and are to be avoided.
One thing that hurts where I work is that we generally have 40-hour weeks, with at most 4-5 hours per month extra for maintenance (depending on the month, your group, ongoing projects, etc.).
So, although we do pay "under market value", the hourly wage is actually higher than a 50-hours-per-week-required job. Add in the fact that the commute is much better than most people's in this region, and you end up spending about 47 hours per week on "work" (including commute), compared to the area average of nearly 60.
You're not logging into each individual server and firing off Windows Update every Patch Tuesday. In fact if you're wasting your time doing crap like that I would argue you're not a very good system administrator, because you're not learning and growing, you're simply caring and feeding.
Until that one time the automated patching system causes the critical server to fail in some way that could have been easily cleared if a human was watching.
Seriously, we automate all the patching we can, but some of the bizarre software running on our VMs means they have to be rebooted manually so that if something screws up, it can be fixed fast. And, yes, I know that for any critical service, there should be some sort of clustering, but generally I'm taking about VMs that interact with specific scientific instruments, and the vendor doesn't support any kind of high-availability. We also can't afford to spend $5M on an extra piece of hardware so that we can have a dev environment to test patches before rolling out to production.
The real problem is that although the OS image is consistent, we have so many apps that are installed on just one VM, and that ends up making every VM unique.
You need a 4th one for the time. Without an accurate time reference, you can't determine distance to satellites.
Every GPS signal is the time...that's how it works.
The signal from different satellites (which includes the time, the satellite ID, and the satellite position) is enough by itself to give you everything you need, and by determining how long each signal took to reach the receiver, the position can be fixed.
You only need 3 satellites if your position is already generally known (i.e., what hemisphere), or if the receiver assumes you are reasonably close to sea level. With 4 satellites, you can get a fix with no previous knowledge of where you were. Four will also give you accurate altitude after a few iterations.
Good thing they patented it. Now nobody else will try to implement it.
Google's PageRank already implements some version of this, at the request of the **AA.
Basically, when Google receives a DMCA takedown for a site in its index (which it honors, even though it doesn't have to because it isn't hosting the content), that site gets down-ranked for at least some searches.
So, Disney—a member of the MPAA—now has a patent that gives Google a reason to stop doing what the MPAA asked it to do.
Even if Macs weren't so expensive, something cross-platform, like BASIC, would be better.
What made Hypercard so great is that it allowed you to build a fairly decent GUI with almost no work.
Although I agree that cross-platform is the way to go, without the ability to "draw" your windows and dialog boxes, it would be just like the original BASIC, where pretty much only geeks used it.
Visual Basic is a convoluted joke.
And yet, it's much closer to what a modern Hypercard should be like than most other dev environments.
3 IDENTICAL channels up front -- not two big "mains" and a ridiculously tiny "center." You need three of the same speaker up front
5. Surrounds identical to the front (or at least from the same family)
This isn't really necessary anymore. With DSP technology, I can have my A/V receiver match the rest of the speakers to any I pick as a reference. It's scary to hear how good it does, because the horn-loaded mains sound very different from the other speakers. I just have the system adjust everything to flat response, and it evens everything out.
All my surround speakers are matched, and I'll eventually match the front 3 to the rears, but it's not a priority right now.
All my audio gear is 10+ years old, some of it sourced from Craigslist.
How do you do multi-channel sound with hardware that doesn't understand any of the newer codecs? I know it's possible to run 7 analog cables from a device to the amp, but most amps have at most one such input. Even with in-device decoding and HDMI for PCM transport, I had to update to a A/V receiver with more HDMI inputs because many newer devices don't have any other output, and there's no way 10-year-old hardware will understand a new enough HDMI standard to work with new devices.
It takes commitment and a certain degree of crazy to make a proper home cinema.
I've been doing it for 28 years now (laserdisc & matrixed surround sound back then), so it's either become normal or is way past crazy.
Because the 128GB of flash in your phone isn't enough to cap a two hour movie without a network connection?
A very reasonable bitrate for 720p video results in about 2GB/hour (including 2-channel sound).
Even a relatively insane 8GB/hour (17Mbps) would fit on a 32GB device. If you do have the ability to add a 128GB micro-SD, then the bitrate could be so far beyond the actual quality offered by a handheld camera that the codec would literally be filling frames with NOPs to keep to the requested bitrate.
Of course, a consequence of phablets is that they're obnoxiously big to dig out of your pocket constantly
Yes, but the G2 is a 5.2" screen in a 5.5"x2.8" body, and is barely larger than the iPhone 6 (which has a 4.7" screen in a 5.4"x2.6" body). Screen size only puts the minimum limit on phone size, and doesn't always give you an idea of the real phone size.
I really don't understand people who put their phone in their pocket...I don't have a pocket that I always wear that will fit any phone comfortably and keep it safe, until phones are iPod Nano sized.
It hardly matters at all, since if you added the repository you probably set it up to prefer at least one package from there.
Yes, if a repository that you get a crucial package from is pwned, you are hosed.
But, by locking packages to a repository, you won't update openssh from "Joe's Repository for Cool Games", since the current version comes from a more official repository that hopefully will have better security (and more eyes on it).
Except that you still have to upgrade the distros that run on those VMs. So now we have to update 10+ systems instead of just one, and we need to pay someone for the server VM solution...
We set up a mirror of the repos that keeps a couple of old versions of each package. New packages are first added to the repo copy that development machines use. If all goes well there, then the packages are added to the production repo. With this setup, updates for Linux can be a cron job.
Yes, surely the VMs could start up in parallel, but I somehow doubt that it comes without its own performance penalties when all we have are spinning disks.
I understand...your lack of good a good architecture has forced you into your situation. It's not my fault that you didn't think ahead. By generally storing our VMs on shared spinning disk, we were able to allocate our limited SSDs to the systems with the highest requirements. Since then, we have added SSD cache to front all the spinning disks.
Surely there's memory deduplication, but all those images are still stored separately and all those extra pages have to be read from the spinning drives. So while we'd pay no RAM penalty for the fact that we'd be running 10 copies of RHEL on top of ESXi or KVM, at startup it'd still hammer the hard drives with redundant reads spread across all of the identical pages in those VM images. Unless ESXi or KVM somehow deduplicate the VM images on disk as well - do they? I can't bother to figure it out from the marketing fluff at the moment.
On-disk data de-duplication can be done at many levels...VMware can use linked clones, SANs can de-dupe, etc. If you don't know about these technologies, that explains why you ended up in the situation you are in.
I know people mention various race conditions, missing dependencies and such, but if those problems aren't known and solved then they are bugs and should be fixed.
When 3-year-old very repeatable bugs in systemd (and related apps) haven't even been assigned to a developer, I have no faith that any new, hard to track down bug will be fixed.
Back in the day, you didn't need to charge your phone every day. Now you do.
The LG G2 (the phone I have) was first released about 13 months ago. I charged mine today after over 72 hours on battery, which is typical.
When my phone doesn't last at least two days, I figure out what app went nuts and sucked down all the battery, because that's the only reason it doesn't last that long. Newer phones (like the LG G3, the Samsung S5, and the HTC One M8) all have better battery-saving algorithms than my phone.
Battery life for phones is getting better again, after 4-5 years of steep decline.
Tier 3 storage from well-known vendors is about $1/GB, plus yearly support costs. Sure, a consumer hard disk is only $0.05/GB, and even an enterprise SAS drive is only about $0.07/GB, but you need an array of these disks, along with the RAM, processors, RAID cards, networking gear, etc., to build up a large storage system.
At my work, we are building a storage array from parts, using only quality equipment with at least 3 year warranties on every part. We are paying $0.22/GB (which is a steal), but that doesn't cover the cost for the software (which is free as this is a proof of concept, but will cost about $0.10/GB per year if we eventually purchase it). That also doesn't include the cost for the rack, cooling, power, networking gear, etc. So, the real rock-bottom minimum with all costs included for reliable storage is about $0.25/GB for acquisition plus anywhere from $0.10 to $0.50 per GB per year maintenance.
Now, you could put all the data on tape for a lot less per GB, but you'd also lose almost all the ability to search, and would likely have to spend a lot of time on requests like "John Doe's IP address from Jan 12, 2014 to Mar 27, 2014".
We're tossing around some notions about different factors that make a 'package' or 'repository' trustworthy.
A very simple solution is to prohibit a package from Repository B from overwriting the already-installed same-named package from Repository A. Then, add a command line parameter to override the prohibition. I know that yum keeps track of which repo a package came from, and the user can set up this kind of protection, but it isn't the default.
This doesn't protect against installing malware if it's the first time you installed a package, and doesn't stop malware from making it's way into a "trusted" repository, but it does prevent the example from the GP.
Except that you have to directly _edit_ the LSB header in the MySQL script to add a new dependency. So if later a distribution update changes the MySQL script, you'd have to manually merge the changes.
Which would take a few minutes at most, and it would be rolled out via puppet to every applicable server. But, it doesn't have to be done, anyway, as a change to that header only takes effect when re-calculating the dependencies to produce the S## and K## files. If you don't rebuild the tree, all will work as it had before.
I don't know what sort of futuristic hardware you're running
Nothing special, but all our OS installs are stripped down to the bare minimum. Just today, I'm working with a vendor and they commented that the startup time for their JBoss app was only about a minute, where they were used to 3-5 minutes. This is a 4-core VM running on a X5690 host.
but the Dell OMSA itself took up to half a minute to start up when using the legacy rc.d system. Zimbra took even longer. Almost anything Java-based takes no less than 10 seconds to start up - jira, the CMS, another 20 seconds for the ERP, and all of those "solutions" insist on their own copy of JVM and of the application server, and they often need their own database, too.
There's your problem. Here, we'd run a few VMs, each doing one thing and doing it well. In particular, VMs remove the need to run any sort of hardware management software.
It takes about 3 minutes between the time sshd is available and most of everything else being up, and the server is a top-of-the line 2U Dell, 2 years old, with maxed out single socket (the other socket empty), maxed out RAM, and maxed out storage. In my systemd experiments, all of this can be parallelized, and that's where we're going, and everything is up in 30 seconds. At least we'll get good use of that single socket during boot-up.
Upstart offers pretty much the same parallel startup for multiple tasks.
I manage several hundred servers and I would love faster boot times. Nothing worse than wasting my time waiting for a machine to come back online.
It's these kinds of statements that show no knowledge of what part of the boot is the OS and what part is the hardware that make me cry about the current state of system administrators. If a significant time of your wait is for the OS to load, then you've configured your server wrong or are using toy hardware.
By far the largest amount of time taken in boot for servers is the hardware checks. For VMs, boot times are already less than 15 seconds, even including the "hardware check", so that's no big deal.
And, for systems that get rebooted once ever 3 months or so, even a minute isn't really a big deal. The only time I really care about boot times are when I'm running through a lot of reboots on the same system, which is usually only when it is first installed and I'm doing hardware config.
Slashdot Mirror
Yes, before I brought this question to Slashdot, I did my homework first. I've scoured logs, check RBLs, used wireshark, etc. It's definitely not a misconfiguration on my end or an issue with complaints resulting from spam.
One change you can make is to configure the outbound NAT from your mail server to appear to come from a different one of your static public IP addresses. Change your DNS to match, and see if that helps at all.
If it doesn't, then perhaps as others have said, you are collateral damage from nearby IP addresses. Has your IP block been allocated to you? If so, you can usually use the WHOIS info to convince the other end that you aren't related to the collateral IP address.
Yahoo spits out several messages:
Deferred: 421 4.7.1 [TS03] All messages from XXX.XXX.XXX.XXX will be permanently deferred; Retrying will NOT succeed.
Not that this will likely help you, but you're probably completely screwed, since Yahoo doesn't even care they are intentionally violating the RFC.
All 4xx response codes are for messages that can't be delivered right now, but some condition change will allow them to be delivered. The text of their message implies that the response code should have been a 5xx. This sort of behavior is usually done in response to spam (foolishly, since most spambots never retry) in an attempt to waste the resources of the sending server by causing it to retry.
The Microsoft response might be legitimate if their systems think that you are sending "too much" e-mail.
My local brick and mortar store are automatically at a 7% price disadvantage because they have to include sales tax to items purchased where online retails don't.
No, your local brick and mortar store is at a 15-30% disadvantage simply because they charge a lot more for most things.
I just bought a gaming headset at a local B&M because I wasn't sure if it would work for me (comfort, quality, etc.) and wanted an easy return if I had to. For that, I paid 44% more than if I had purchase the item from Amazon. This is not an unusual situation, at least as far as tech is concerned, with Amazon, NewEgg, SuperBiiz, etc., all fighting for my online purchases.
Also, Amazon charges tax in my state, so that part doesn't even enter into the decision to buy online.
It's not just an issue of understanding, it's apathy and laziness.
Yes, laziness on the part of the programmers of the device.
The default password should allow you to access exactly one function on the device: the "pick a username and password for a new admin" feature. Once that finishes, either the default password is set to cat < /dev/urandom > password_storage_file or else the default user is removed. In case you forget the username and password you set, the device can be reset to factory defaults using some sort of physical "reset" button.
Just because a door is unlocked does not mean you may walk inside, even if it is to tell the owner their door is unlocked.
This is a good analogy, because it is impossible to tell if a door is unlocked (or if a camera has the default username/password) without trying to open the door.
So, what your advice boils down to is that you never can accurately inform someone their door (system) is unlocked..
So you don't think that a combination of factors such as where you live, how much you get paid, relative market rates, current job market conditions, your recent payrises, your recent year end appraisal scores, where your partner works, your age, your time since last promotion or anything else the company has or can easily gain access to would be an indicator of how likely you are to leave?
Not for some jobs. In a lot of the tech world, the algorithm would be pretty much exactly as the GP listed, at least for talented people who are desired by employers.
And, what does the company do when "big data" says somebody is or isn't going to leave in the next year? If they use just that metric, the will find out that a lot of people who they thought weren't going to leave end up gone..."we don't need to give him that big of a raise...the computer says he won't leave anyway". Or, "hey, we better find a cheaper replacement for this guy, because he's leaving in the next year" will be a lot more likely than giving the guy what it takes to keep him.
Then, too, there's a lot of employees who won't ever leave their existing job because they can't do any better anywhere else. Sadly, many of those people are the ones that you might want to encourage to leave.
Given a choice, they'd still be using iPads.
This is the first season that any electronic device could be used by coaches and players during an NFL game. They weren't using iPads before...they were using steno pads.
That's code for "we pay well under market", and are to be avoided.
One thing that hurts where I work is that we generally have 40-hour weeks, with at most 4-5 hours per month extra for maintenance (depending on the month, your group, ongoing projects, etc.).
So, although we do pay "under market value", the hourly wage is actually higher than a 50-hours-per-week-required job. Add in the fact that the commute is much better than most people's in this region, and you end up spending about 47 hours per week on "work" (including commute), compared to the area average of nearly 60.
You're not logging into each individual server and firing off Windows Update every Patch Tuesday. In fact if you're wasting your time doing crap like that I would argue you're not a very good system administrator, because you're not learning and growing, you're simply caring and feeding.
Until that one time the automated patching system causes the critical server to fail in some way that could have been easily cleared if a human was watching.
Seriously, we automate all the patching we can, but some of the bizarre software running on our VMs means they have to be rebooted manually so that if something screws up, it can be fixed fast. And, yes, I know that for any critical service, there should be some sort of clustering, but generally I'm taking about VMs that interact with specific scientific instruments, and the vendor doesn't support any kind of high-availability. We also can't afford to spend $5M on an extra piece of hardware so that we can have a dev environment to test patches before rolling out to production.
The real problem is that although the OS image is consistent, we have so many apps that are installed on just one VM, and that ends up making every VM unique.
You need a 4th one for the time. Without an accurate time reference, you can't determine distance to satellites.
Every GPS signal is the time...that's how it works.
The signal from different satellites (which includes the time, the satellite ID, and the satellite position) is enough by itself to give you everything you need, and by determining how long each signal took to reach the receiver, the position can be fixed.
You only need 3 satellites if your position is already generally known (i.e., what hemisphere), or if the receiver assumes you are reasonably close to sea level. With 4 satellites, you can get a fix with no previous knowledge of where you were. Four will also give you accurate altitude after a few iterations.
Good thing they patented it. Now nobody else will try to implement it.
Google's PageRank already implements some version of this, at the request of the **AA.
Basically, when Google receives a DMCA takedown for a site in its index (which it honors, even though it doesn't have to because it isn't hosting the content), that site gets down-ranked for at least some searches.
So, Disney—a member of the MPAA—now has a patent that gives Google a reason to stop doing what the MPAA asked it to do.
Even if Macs weren't so expensive, something cross-platform, like BASIC, would be better.
What made Hypercard so great is that it allowed you to build a fairly decent GUI with almost no work.
Although I agree that cross-platform is the way to go, without the ability to "draw" your windows and dialog boxes, it would be just like the original BASIC, where pretty much only geeks used it.
Visual Basic is a convoluted joke.
And yet, it's much closer to what a modern Hypercard should be like than most other dev environments.
3 IDENTICAL channels up front -- not two big "mains" and a ridiculously tiny "center." You need three of the same speaker up front
5. Surrounds identical to the front (or at least from the same family)
This isn't really necessary anymore. With DSP technology, I can have my A/V receiver match the rest of the speakers to any I pick as a reference. It's scary to hear how good it does, because the horn-loaded mains sound very different from the other speakers. I just have the system adjust everything to flat response, and it evens everything out.
All my surround speakers are matched, and I'll eventually match the front 3 to the rears, but it's not a priority right now.
All my audio gear is 10+ years old, some of it sourced from Craigslist.
How do you do multi-channel sound with hardware that doesn't understand any of the newer codecs? I know it's possible to run 7 analog cables from a device to the amp, but most amps have at most one such input. Even with in-device decoding and HDMI for PCM transport, I had to update to a A/V receiver with more HDMI inputs because many newer devices don't have any other output, and there's no way 10-year-old hardware will understand a new enough HDMI standard to work with new devices.
It takes commitment and a certain degree of crazy to make a proper home cinema.
I've been doing it for 28 years now (laserdisc & matrixed surround sound back then), so it's either become normal or is way past crazy.
Because the 128GB of flash in your phone isn't enough to cap a two hour movie without a network connection?
A very reasonable bitrate for 720p video results in about 2GB/hour (including 2-channel sound).
Even a relatively insane 8GB/hour (17Mbps) would fit on a 32GB device. If you do have the ability to add a 128GB micro-SD, then the bitrate could be so far beyond the actual quality offered by a handheld camera that the codec would literally be filling frames with NOPs to keep to the requested bitrate.
The G2 is a 5.2" smartphone.
Of course, a consequence of phablets is that they're obnoxiously big to dig out of your pocket constantly
Yes, but the G2 is a 5.2" screen in a 5.5"x2.8" body, and is barely larger than the iPhone 6 (which has a 4.7" screen in a 5.4"x2.6" body). Screen size only puts the minimum limit on phone size, and doesn't always give you an idea of the real phone size.
I really don't understand people who put their phone in their pocket...I don't have a pocket that I always wear that will fit any phone comfortably and keep it safe, until phones are iPod Nano sized.
It hardly matters at all, since if you added the repository you probably set it up to prefer at least one package from there.
Yes, if a repository that you get a crucial package from is pwned, you are hosed.
But, by locking packages to a repository, you won't update openssh from "Joe's Repository for Cool Games", since the current version comes from a more official repository that hopefully will have better security (and more eyes on it).
Except that you still have to upgrade the distros that run on those VMs. So now we have to update 10+ systems instead of just one, and we need to pay someone for the server VM solution...
We set up a mirror of the repos that keeps a couple of old versions of each package. New packages are first added to the repo copy that development machines use. If all goes well there, then the packages are added to the production repo. With this setup, updates for Linux can be a cron job.
Yes, surely the VMs could start up in parallel, but I somehow doubt that it comes without its own performance penalties when all we have are spinning disks.
I understand...your lack of good a good architecture has forced you into your situation. It's not my fault that you didn't think ahead. By generally storing our VMs on shared spinning disk, we were able to allocate our limited SSDs to the systems with the highest requirements. Since then, we have added SSD cache to front all the spinning disks.
Surely there's memory deduplication, but all those images are still stored separately and all those extra pages have to be read from the spinning drives. So while we'd pay no RAM penalty for the fact that we'd be running 10 copies of RHEL on top of ESXi or KVM, at startup it'd still hammer the hard drives with redundant reads spread across all of the identical pages in those VM images. Unless ESXi or KVM somehow deduplicate the VM images on disk as well - do they? I can't bother to figure it out from the marketing fluff at the moment.
On-disk data de-duplication can be done at many levels...VMware can use linked clones, SANs can de-dupe, etc. If you don't know about these technologies, that explains why you ended up in the situation you are in.
I know people mention various race conditions, missing dependencies and such, but if those problems aren't known and solved then they are bugs and should be fixed.
When 3-year-old very repeatable bugs in systemd (and related apps) haven't even been assigned to a developer, I have no faith that any new, hard to track down bug will be fixed.
Back in the day, you didn't need to charge your phone every day. Now you do.
The LG G2 (the phone I have) was first released about 13 months ago. I charged mine today after over 72 hours on battery, which is typical.
When my phone doesn't last at least two days, I figure out what app went nuts and sucked down all the battery, because that's the only reason it doesn't last that long. Newer phones (like the LG G3, the Samsung S5, and the HTC One M8) all have better battery-saving algorithms than my phone.
Battery life for phones is getting better again, after 4-5 years of steep decline.
A gigabyte of storage costs less than five cents.
Tier 3 storage from well-known vendors is about $1/GB, plus yearly support costs. Sure, a consumer hard disk is only $0.05/GB, and even an enterprise SAS drive is only about $0.07/GB, but you need an array of these disks, along with the RAM, processors, RAID cards, networking gear, etc., to build up a large storage system.
At my work, we are building a storage array from parts, using only quality equipment with at least 3 year warranties on every part. We are paying $0.22/GB (which is a steal), but that doesn't cover the cost for the software (which is free as this is a proof of concept, but will cost about $0.10/GB per year if we eventually purchase it). That also doesn't include the cost for the rack, cooling, power, networking gear, etc. So, the real rock-bottom minimum with all costs included for reliable storage is about $0.25/GB for acquisition plus anywhere from $0.10 to $0.50 per GB per year maintenance.
Now, you could put all the data on tape for a lot less per GB, but you'd also lose almost all the ability to search, and would likely have to spend a lot of time on requests like "John Doe's IP address from Jan 12, 2014 to Mar 27, 2014".
We're tossing around some notions about different factors that make a 'package' or 'repository' trustworthy.
A very simple solution is to prohibit a package from Repository B from overwriting the already-installed same-named package from Repository A. Then, add a command line parameter to override the prohibition. I know that yum keeps track of which repo a package came from, and the user can set up this kind of protection, but it isn't the default.
This doesn't protect against installing malware if it's the first time you installed a package, and doesn't stop malware from making it's way into a "trusted" repository, but it does prevent the example from the GP.
Except that you have to directly _edit_ the LSB header in the MySQL script to add a new dependency. So if later a distribution update changes the MySQL script, you'd have to manually merge the changes.
Which would take a few minutes at most, and it would be rolled out via puppet to every applicable server. But, it doesn't have to be done, anyway, as a change to that header only takes effect when re-calculating the dependencies to produce the S## and K## files. If you don't rebuild the tree, all will work as it had before.
I don't know what sort of futuristic hardware you're running
Nothing special, but all our OS installs are stripped down to the bare minimum. Just today, I'm working with a vendor and they commented that the startup time for their JBoss app was only about a minute, where they were used to 3-5 minutes. This is a 4-core VM running on a X5690 host.
but the Dell OMSA itself took up to half a minute to start up when using the legacy rc.d system. Zimbra took even longer. Almost anything Java-based takes no less than 10 seconds to start up - jira, the CMS, another 20 seconds for the ERP, and all of those "solutions" insist on their own copy of JVM and of the application server, and they often need their own database, too.
There's your problem. Here, we'd run a few VMs, each doing one thing and doing it well. In particular, VMs remove the need to run any sort of hardware management software.
It takes about 3 minutes between the time sshd is available and most of everything else being up, and the server is a top-of-the line 2U Dell, 2 years old, with maxed out single socket (the other socket empty), maxed out RAM, and maxed out storage. In my systemd experiments, all of this can be parallelized, and that's where we're going, and everything is up in 30 seconds. At least we'll get good use of that single socket during boot-up.
Upstart offers pretty much the same parallel startup for multiple tasks.
I manage several hundred servers and I would love faster boot times. Nothing worse than wasting my time waiting for a machine to come back online.
It's these kinds of statements that show no knowledge of what part of the boot is the OS and what part is the hardware that make me cry about the current state of system administrators. If a significant time of your wait is for the OS to load, then you've configured your server wrong or are using toy hardware.
By far the largest amount of time taken in boot for servers is the hardware checks. For VMs, boot times are already less than 15 seconds, even including the "hardware check", so that's no big deal.
And, for systems that get rebooted once ever 3 months or so, even a minute isn't really a big deal. The only time I really care about boot times are when I'm running through a lot of reboots on the same system, which is usually only when it is first installed and I'm doing hardware config.
Nope, it was done while you were there, I was class of '95. Some "unofficial" splinter group of the SCCA group.
OK, I know of that group of people, but none of them well.
My roomie used to steal bikes.
Hey, I had a bike stolen around that time! Seriously, I did, but there were a lot of bikes that went missing in that town.