One launch failure and you call the contract awarders bozos? The contract is to deliver stuff. A failed launch and loss of orbital vehicle is immaterial, except for the loss of cargo. The contract still stands and Orbital will have to deliver, kabooms or no kabooms. Maybe, as the autocorrect suggests, next time they should deliver kabobs instead of kabooms.
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.
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... 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. 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.
My issue is that every once in a while I need a reboot, and waiting minutes between the time the kernel boots and the rest of it is up is entirely unnecessary. It's a case of a premature pessimization wrought by the anachronistic combination of init and serial rc scripts present on every fucking distro out there save for ones that do systemd properly. That's my point. Even then I have to set up "commercial" software manually for systemd since it insists on silly serial startup of sub-services, with no dependency management. All because the fucking software vendors that claim RHEL 7 "support" don't really mean that they support all of it, just the minimum necessary to get their crap to work eventually, if you wait long enough after reboot that is. You know, they support it with an asterisk. Wink wink, you understand, but you can always pay one of their solution providers $250/hr to maybe do a "hotfix" for you, if you buy 25hrs of their time first, customarily of course. Sigh.
On my particular server, it takes 30 seconds from cold boot till the bootloader starts running. With systemd I have everything running in another 45-50 seconds - and that's from mechanical hard drives. Without systemd it takes 3+ minutes after sshd is up, and to get to that point, on RHEL 6, takes 30 seconds after the kernel has booted - primarily due to numerous network interfaces this system has. Shutdown is similarly long - again due to things being turned of serially, not in parallel. So, without systemd a reboot is approx. 7 minutes of downtime. With systemd it's less than 2 minutes. I should be able to bring it closer to 1 minute with further tweaks. The RHEL-6 style serial rc scripts + init make the boot-up on this thing look like an IPL on an IBM mainframe.
It doesn't matter for us if a server failure takes down one critical system or multiple ones. People with access to the server have physical keys that work whether the keyfobs work or not, and whether the building's thermostats are polled and updated according to the time of day or not. It's a small business and we don't have the tens of thousands of dollars needed to set up a truly foolproof no-downtime, always-available setup. We've had 3 Dell servers over the years, and none have failed hard - we've had occasional failures of redundant pieces, such as hard drives and power supplies - those were all hot-swappable with no downtime. Maybe a RAM module had failed long ago, but I don't recall anymore - it'd have been redundant ECC RAM anyway, where if a bank is down you need to replace it during a planned downtime, but things keep on running. The previous server can run RHEL 7, so I might attempt a failover solution of some sort, but it wasn't a priority so far. I could reimage a new server and have everything up and running in ~2 hours after getting one out of a box, and the on-site service plan covers getting the replacement parts/new server. That's as good of an uptime guarantee as you will ever get with a small budget. And the people who can do a restore live 15 minutes away or less.
What wat? Just look at the link in the fine article. It's not to any official openbsd repo, because it's not even CVS, and OpenBSD uses CVS (yes, they do). That's wat. Again, how stupid can one be?
Exactly. The editors should be ashamed. The post was carefully engineered to promote someone's private fork. OpenBSD uses WebCVS for crying out loud! How stupid can people be?!
Neither can you implement CurrentC. Given enough money, I'm sure you could implement either one.
For some issuing banks, it's already trivial enough to generate a virtual credit card number using a web service (even if you have to screen-scrape), and that's all you need to expose the number via NFC. A friend of mine did a demo of such a wallet running using a little ARM microcontroller and talking over a SPI-interfaced Wi-Fi dongle to his Citi credit card account to generate virtual card numbers on-the-fly.
That's what runs on our RHEL server, thank you very much. Is that so hard to understand? The whole point of doing it all on one physical server is to keep the costs down and make management easy. I've forgotten to list our door control system, too, never mind the various inter- and intranet services that we run.
Oh ok, you're trolling.
If I have one OS image, I only do the update once on test, once in production. If I had 10 appliance-style VMs, I'd need to update those individually, so now instead of a simple checkpoint-update on the test machine followed by checkpoint-update on the production machine, I have to get a management solution that'd let me automate all this on multiple VMs. Suddenly a simple act of updating a server snowballs into a yet another piece of "enterprise" software we have to pay for, and that slows down the anachronistic serial init+rc scripts boot process of RHEL 6.
I'm merely stating how things are when you actually run a handful of enterprisey pieces of software that all insist that their "support" for RHEL still allows them to force you to use the bundled copies of a whole bunch of things already provided by the distribution. Because, you know, Zimbra can't use the postfix, apache httpd, amavis, tomcat or openldap that comes with RHEL, for example, and that has already started up anyway and is used by other services. That's just one example, everyone seems to be just as bad.
You don't even need to use a mobile wallet, just use NFC, and if it doesn't work (it won't!) say "oops, my magstripe is all worn out, ta-ta, see you tomorrow".
I think that's bullshit. When you accept credit card payments, you get a merchant account with a bank, and you get a fee schedule with that. The fees are tied to the IIN prefix that signifies the card brand (JCB, Visa, Discover, Amex, MasterCard,...). The mobile wallets use either Visa or MC virtual credit card numbers with respective IIN, so to the merchant it appears as if you've used a NFC MC or Visa. There's no way for a merchant to even know that you're using a mobile wallet - it works the same as the NFC chips that come standard inside of credit cards offered by more and more banks.
Apple gets paid by agreements with credit card organizations and/or some large issuing banks.
They can't only block wallets. They can either support NFC or not support NFC. Apple's NFC system emulates what an NFC-chipped credit card would do. I'm using NFC from the credit cards since the magstripe never lasts me until I receive a replacement card, and it's a bit too much hassle to have to call the bank to reissue a card. I happen to shop at CVS, and I've already told them that I'll be transferring all of my business to a grocery-store-based pharmacy if they don't bring NFC back. And I don't even use Apple Pay. Their move is dickish. They basically want to somehow get an extra income stream out of the mobile wallet payments, and I say fuck you to that.
Apple Pay's interface with your CC account is proprietary. Its interface with the retailer is most definitely non-proprietary, even if the standards aren't particularly open.
Exactly, and the reason it works this way is that Apple Pay looks like a regular NFC credit card to the retailer's systems. The only special thing that Apple Pay does is the generation of a one-time virtual credit card number that only works for that one transaction. The backends translate this into a transaction on your funding CC number.
They didn't merely shut down Apple Pay/Google Wallet, because there's nothing specific to those NFC systems. They've wholesale shut down the standard NFC payments. Many of my cards have NFC chips in them, and they flat out don't work - precisely because the Apple Pay and Google Wallet act just as if you had a real credit card with an NFC chip on it. Except that the account number is single-use.
I do feel at some point a new "OS" will come out that is designed only to run on VM's and contains none of the extra OS parts to support any hardware but a VM machine
You mean, like the stuff IBM's Rochester platforms (AS/400) has had for 20 years now with their Machine Interface?
That's not entirely true. There's lots of such resources that are left alone mainly due to reasons of environmental or urban protection. Colorado would enjoy its boom heyday again if we were to go back to "horse-and-buggy economy".
I hope you're not serious. Sure, museum artifacts last longer, but if you're after preservation they're useless for their intended purpose. A book that you can't read isn't good for much.
Sure it's possible, but if that happens, all of the living things will be permanently deleted as well. The surface-level effects of solar storms aren't on semiconductors at all, but on long metallic structures, a.k.a. power lines. Heck, they only manifest themselves because current AC long-haul systems are DC-coupled. All it takes to make the power grid laugh at geomagnetic storms is to add capacitive coupling at one end of each line. That's it. You open the circuit for the low-frequency currents and the problem is solved. The transformers get damaged by geomagnetic-storm induced DC/low-freq currents because those currents easily saturate the cores, and now instead of a transformer you've got a resistor bank, and the overcurrent protection devices are designed for AC and act as short-circuits at DC - they mechanically open, but the DC arc keeps on going, so the fact that they are open is irrelevant. If you ever look at a circuit breaker or a switch, the units with a given DC current rating are an order of magnitude larger in volume than the units rated for a given AC current.
You don't have to be a hipster to appreciate old wood. It's simply more dimensionally stable than new wood. Same goes for most other materials - they age those piano frames for the same reason. If you need dimensionally stable wood (as much as a given wood species can be), you need old wood, pure and simple.
Mobile electronics, especially thin ones, don't use any capacitors that could dry out. The ones that do dry out are the aluminum electrolytic types. Modern mobile stuff is all ceramic capacitors with a few tantalums sprinkled here and there, if at all. The only real concern is solder whisker growth and finite data retention times of flash memory. I'd expect a 100 year old battery-less iPad to be perfectly electrically OK and ready to have its firmware and storage re-flashed:) Perhaps we need a hardwire logic paper tape reader with a JTAG interface.
I don't know what sort of futuristic hardware you're running, 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. The BIOS times are negligible compared to all the other userland crap that has to start up. 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.
I don't know where you get your Dell components, but I've had only good luck with eBay - they usually are quite cheap when the market gets flooded with off-lease corporate systems. Sure it won't be that rosy for a limited-market gamer/workstation system, but still, Dell is possibly the most affordable PC brand when it comes to aftermarket replacement parts.
Slashdot Mirror
One launch failure and you call the contract awarders bozos? The contract is to deliver stuff. A failed launch and loss of orbital vehicle is immaterial, except for the loss of cargo. The contract still stands and Orbital will have to deliver, kabooms or no kabooms. Maybe, as the autocorrect suggests, next time they should deliver kabobs instead of kabooms.
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.
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... 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. 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.
My issue is that every once in a while I need a reboot, and waiting minutes between the time the kernel boots and the rest of it is up is entirely unnecessary. It's a case of a premature pessimization wrought by the anachronistic combination of init and serial rc scripts present on every fucking distro out there save for ones that do systemd properly. That's my point. Even then I have to set up "commercial" software manually for systemd since it insists on silly serial startup of sub-services, with no dependency management. All because the fucking software vendors that claim RHEL 7 "support" don't really mean that they support all of it, just the minimum necessary to get their crap to work eventually, if you wait long enough after reboot that is. You know, they support it with an asterisk. Wink wink, you understand, but you can always pay one of their solution providers $250/hr to maybe do a "hotfix" for you, if you buy 25hrs of their time first, customarily of course. Sigh.
On my particular server, it takes 30 seconds from cold boot till the bootloader starts running. With systemd I have everything running in another 45-50 seconds - and that's from mechanical hard drives. Without systemd it takes 3+ minutes after sshd is up, and to get to that point, on RHEL 6, takes 30 seconds after the kernel has booted - primarily due to numerous network interfaces this system has. Shutdown is similarly long - again due to things being turned of serially, not in parallel. So, without systemd a reboot is approx. 7 minutes of downtime. With systemd it's less than 2 minutes. I should be able to bring it closer to 1 minute with further tweaks. The RHEL-6 style serial rc scripts + init make the boot-up on this thing look like an IPL on an IBM mainframe.
It doesn't matter for us if a server failure takes down one critical system or multiple ones. People with access to the server have physical keys that work whether the keyfobs work or not, and whether the building's thermostats are polled and updated according to the time of day or not. It's a small business and we don't have the tens of thousands of dollars needed to set up a truly foolproof no-downtime, always-available setup. We've had 3 Dell servers over the years, and none have failed hard - we've had occasional failures of redundant pieces, such as hard drives and power supplies - those were all hot-swappable with no downtime. Maybe a RAM module had failed long ago, but I don't recall anymore - it'd have been redundant ECC RAM anyway, where if a bank is down you need to replace it during a planned downtime, but things keep on running. The previous server can run RHEL 7, so I might attempt a failover solution of some sort, but it wasn't a priority so far. I could reimage a new server and have everything up and running in ~2 hours after getting one out of a box, and the on-site service plan covers getting the replacement parts/new server. That's as good of an uptime guarantee as you will ever get with a small budget. And the people who can do a restore live 15 minutes away or less.
That's just someone's private repo. You've fallen for clickbait. Nothing to see here.
What wat? Just look at the link in the fine article. It's not to any official openbsd repo, because it's not even CVS, and OpenBSD uses CVS (yes, they do). That's wat. Again, how stupid can one be?
Exactly. The editors should be ashamed. The post was carefully engineered to promote someone's private fork. OpenBSD uses WebCVS for crying out loud! How stupid can people be?!
Neither can you implement CurrentC. Given enough money, I'm sure you could implement either one.
For some issuing banks, it's already trivial enough to generate a virtual credit card number using a web service (even if you have to screen-scrape), and that's all you need to expose the number via NFC. A friend of mine did a demo of such a wallet running using a little ARM microcontroller and talking over a SPI-interfaced Wi-Fi dongle to his Citi credit card account to generate virtual card numbers on-the-fly.
What?
That's what runs on our RHEL server, thank you very much. Is that so hard to understand? The whole point of doing it all on one physical server is to keep the costs down and make management easy. I've forgotten to list our door control system, too, never mind the various inter- and intranet services that we run.
Oh ok, you're trolling.
If I have one OS image, I only do the update once on test, once in production. If I had 10 appliance-style VMs, I'd need to update those individually, so now instead of a simple checkpoint-update on the test machine followed by checkpoint-update on the production machine, I have to get a management solution that'd let me automate all this on multiple VMs. Suddenly a simple act of updating a server snowballs into a yet another piece of "enterprise" software we have to pay for, and that slows down the anachronistic serial init+rc scripts boot process of RHEL 6.
I'm merely stating how things are when you actually run a handful of enterprisey pieces of software that all insist that their "support" for RHEL still allows them to force you to use the bundled copies of a whole bunch of things already provided by the distribution. Because, you know, Zimbra can't use the postfix, apache httpd, amavis, tomcat or openldap that comes with RHEL, for example, and that has already started up anyway and is used by other services. That's just one example, everyone seems to be just as bad.
I might just go and give it a try :)
You don't even need to use a mobile wallet, just use NFC, and if it doesn't work (it won't!) say "oops, my magstripe is all worn out, ta-ta, see you tomorrow".
I think that's bullshit. When you accept credit card payments, you get a merchant account with a bank, and you get a fee schedule with that. The fees are tied to the IIN prefix that signifies the card brand (JCB, Visa, Discover, Amex, MasterCard, ...). The mobile wallets use either Visa or MC virtual credit card numbers with respective IIN, so to the merchant it appears as if you've used a NFC MC or Visa. There's no way for a merchant to even know that you're using a mobile wallet - it works the same as the NFC chips that come standard inside of credit cards offered by more and more banks.
Apple gets paid by agreements with credit card organizations and/or some large issuing banks.
They can't only block wallets. They can either support NFC or not support NFC. Apple's NFC system emulates what an NFC-chipped credit card would do. I'm using NFC from the credit cards since the magstripe never lasts me until I receive a replacement card, and it's a bit too much hassle to have to call the bank to reissue a card. I happen to shop at CVS, and I've already told them that I'll be transferring all of my business to a grocery-store-based pharmacy if they don't bring NFC back. And I don't even use Apple Pay. Their move is dickish. They basically want to somehow get an extra income stream out of the mobile wallet payments, and I say fuck you to that.
Apple Pay's interface with your CC account is proprietary. Its interface with the retailer is most definitely non-proprietary, even if the standards aren't particularly open.
Exactly, and the reason it works this way is that Apple Pay looks like a regular NFC credit card to the retailer's systems. The only special thing that Apple Pay does is the generation of a one-time virtual credit card number that only works for that one transaction. The backends translate this into a transaction on your funding CC number.
They didn't merely shut down Apple Pay/Google Wallet, because there's nothing specific to those NFC systems. They've wholesale shut down the standard NFC payments. Many of my cards have NFC chips in them, and they flat out don't work - precisely because the Apple Pay and Google Wallet act just as if you had a real credit card with an NFC chip on it. Except that the account number is single-use.
I do feel at some point a new "OS" will come out that is designed only to run on VM's and contains none of the extra OS parts to support any hardware but a VM machine
You mean, like the stuff IBM's Rochester platforms (AS/400) has had for 20 years now with their Machine Interface?
That's not entirely true. There's lots of such resources that are left alone mainly due to reasons of environmental or urban protection. Colorado would enjoy its boom heyday again if we were to go back to "horse-and-buggy economy".
I hope you're not serious. Sure, museum artifacts last longer, but if you're after preservation they're useless for their intended purpose. A book that you can't read isn't good for much.
Sure it's possible, but if that happens, all of the living things will be permanently deleted as well. The surface-level effects of solar storms aren't on semiconductors at all, but on long metallic structures, a.k.a. power lines. Heck, they only manifest themselves because current AC long-haul systems are DC-coupled. All it takes to make the power grid laugh at geomagnetic storms is to add capacitive coupling at one end of each line. That's it. You open the circuit for the low-frequency currents and the problem is solved. The transformers get damaged by geomagnetic-storm induced DC/low-freq currents because those currents easily saturate the cores, and now instead of a transformer you've got a resistor bank, and the overcurrent protection devices are designed for AC and act as short-circuits at DC - they mechanically open, but the DC arc keeps on going, so the fact that they are open is irrelevant. If you ever look at a circuit breaker or a switch, the units with a given DC current rating are an order of magnitude larger in volume than the units rated for a given AC current.
The cost of international ocean shipping is already laughably low, IMHO.
You don't have to be a hipster to appreciate old wood. It's simply more dimensionally stable than new wood. Same goes for most other materials - they age those piano frames for the same reason. If you need dimensionally stable wood (as much as a given wood species can be), you need old wood, pure and simple.
Mobile electronics, especially thin ones, don't use any capacitors that could dry out. The ones that do dry out are the aluminum electrolytic types. Modern mobile stuff is all ceramic capacitors with a few tantalums sprinkled here and there, if at all. The only real concern is solder whisker growth and finite data retention times of flash memory. I'd expect a 100 year old battery-less iPad to be perfectly electrically OK and ready to have its firmware and storage re-flashed :) Perhaps we need a hardwire logic paper tape reader with a JTAG interface.
I don't know what sort of futuristic hardware you're running, 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. The BIOS times are negligible compared to all the other userland crap that has to start up. 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.
I have no problem with distributing it across machines. You're welcome to foot the bill for the servers :)
I don't know where you get your Dell components, but I've had only good luck with eBay - they usually are quite cheap when the market gets flooded with off-lease corporate systems. Sure it won't be that rosy for a limited-market gamer/workstation system, but still, Dell is possibly the most affordable PC brand when it comes to aftermarket replacement parts.