You can't make people use a device by edict. Just because a sports team, a league, or a broadcaster has signed some contracts, it doesn't magically make their users productive on another device. Microsoft dropped the ball by not providing decent applications for their own platform themselves. They supposedly know how to write software, yet they steadfastly refuse to write apps for their mobile platforms that are good enough to make people switch. All it'd take is good apps, nothing more, nothing less.
For that kind of money, you could hire an equivalent of two full-time engineers for a year to design that thing from the scratch for you, and you'd probably get a couple of production units out of that deal, too. You'd need an ME to do thermal and case design, shouldn't take longer than a couple months for that. An EE to do any custom mezzanine boards that one might need + wiring and overall electrical design. Finally, a software guy to make a config console etc. I assume that project management is not included in this. Overall, a startup with people who know what the heck they're doing would need $500k to pull it off, if they're any good at it.
The demonstrated reliability, performance and cost of the Virgin's concept is a step back. I don't care how good it looks on paper, even though it really doesn't, in reality it's a poorly performing disaster. The biggest issue is that it was never meant to be used to reach orbital velocity. It's a ballistic taxi, made to skim the some cream in a currently unexploited pseudospace tourist segment. It's a commercial venture whose goals are not space R&D.
They'd need to scale the energy delivered to their vehicle by a factor of 100, just to reach the low orbit of the ISS. Read again: factor of 100. Now tell me how the heck do you plan to scale their weekend ride by that factor. Yeah, doesn't take a rocket scientist to understand that it's a pipe dream.
This would be fine and dandy if we didn't already have perfectly usable ways of getting into orbit. You seemingly insist that we should be doing historical reproductions.
Virgin's endeavor is about a factor 100 away, energetically, from achieving orbit, and another factor of 10-100 away from getting to elsewhere either inside or outside of the solar system. This helps keep things in perspective. It's not space tourism. It's a rollercoaster, and a poorly designed one at that. I was their fan until one fine day it dawned on me that their approach is all fluff and no substance simply due to the reality of the amount of energy you need to do anything substantial in space. Their approach doesn't scale. It's simply a ballistic flight that goes a couple times higher than the vomit comet.
It started with a premise that has been demonstrated to be a bunch of good wishes, nothing more. The supposed simplicity of the engine doesn't mean that it requires no care. Given the time it took them, I'd say that the concept as executed by them won't ever work and is a failure. Perhaps it would work for someone else, but not for them.
"I have an RHEL 6 system with multiple commercial Java applications." That's the difference you're looking for. I'm not running a barebones RHEL system. 95% of the resident set on that server is code that didn't come from any distro, it's the heaps of a multitude of JVMs and database servers that are bundled with commercial apps. Every one of those damn things takes at least 10 seconds to start up, and that's only if it's a simple thing. A full-stack application like Zimbra can be starting up for 40 seconds. There's also the issue of parallelizing the bring-up of network interfaces, which I did. For some reason a stock RHEL 6 takes 5+ seconds per network interface - I managed to parallelize that, too, and to set up dependencies between each interface and the services that use it. Since we isolate nodes on the internal network using tagged vlans, there's about 50 interfaces that have to be brought up, and most of them have no dependencies.
"If a service is critical, there should be a parallel server running it." Maybe in an alternate reality. Who can justify spending on a very decent server that is then vastly underutilized because you don't run everything you can on it? That "server" would be, at best, a VM. Of course a VM by itself doesn't fix the internal dependencies between elements of full-stack monolithic commercial apps.
It wouldn't matter if I used a pre-systemd Debian, since the serial shutdown of the commercial apps that I run would take 2 minutes. It's distro-independent after all, since all those apps are 3rd-party monoliths as far as the distro is concerned.
Again - we run a multitude of services - CRP/ERM, building automation, support for our own hardware, email (groupware), document management, phone system, security system, and a couple of other things, including support for our own R&D hardware labs. It's all on a stable, well-performing piece of hardware, that's well utilized with a bit of capacity to spare.
If you're a business, nothing is free. You have to spend the money, the question is how much do you spend and who are the checks written to. From the perspective of my business, not having free Linux is fairly immaterial, as the costs of supporting it and the multitude of applications we run on it far outstrip the cost of the OS. It really helps that we don't run it on big iron, but on plain old x86 hardware:)
I have an RHEL 6 system with multiple commercial Java applications. For some reason, every commercial Java application out there seems to bundle half of a linux distro with it: they insist on using their own instance of a web server, their own application server, their own database, their own mail daemon, etc. Starting those things serially is true insanity and takes forever.
With all of this stuff migrated to RHEL 7, tweaked so that there's no init + rc.d craziness left, a 4 minute boot-up turns into 1:30 boot-up. This is with spinning drives. I have another iteration of tweaks where I exposed all internal service dependencies inside each of those monolithic app monsters to systemd, and we can be up and running in 1:15. Looking at I/O statistics, with further judicious use of preloading we should cut it down to 1:00-1:05 after a clean shutdown. The shutdown times, usually well over 2 minutes long, are down to 30 seconds.
This is all measurable, no-bullshit, experimental data. We even managed not to have to touch any of the commercial app's rc scripts, I simply coded up the requisite systemd configurations for those services, based on the rc scripts. If there's any question as to systemd's effect on the application, or if we need to deal with vendor support, we can always start it up using the rc scripts.
So, I don't care about ideology behind systemd, and how it fits with someone's ideas about what Unix or a Linux distro should or shouldn't be. All I know is that it'd have taken me 5-10x as long to tweak the system rc.d scripts to parallelize them than it took me to "port" the commercial apps we use over to systemd. Of course the distribution's own services already use systemd, so I didn't have to touch that, only tweak a few things slightly to further leverage parallelism. It has saved us time and money, and the system availability is much better in face of the rare reboots. Everyone is happy. We're a small shop with a single server, and we use no virtualization nor any other enterprisey stuff. Just a plain old RHEL 7 running directly on hardware, with selinux turned on, with custom policies written for each of the commercial apps.
A lot of the "recommendations" I've got from "veteran" admins essentially reduced to throwing money and resources at the problem. That's IMHO a rather direct vindication of systemd: if it takes a SAN, multilevel storage and VMs just so that the damn init/rc.d-based system will boot in a reasonable amount of time, and all of that is taken care of by systemd, it'd be rather irresponsible for me to try and ignore systemd. In the name of what? Nothing I can think of. It's not like I can tell the management "hey, RHEL 7 comes with systemd, but I can keep using RHEL 6, not use systemd, and spend $25k+ for a SAN, VM and OS licenses, and the time to set it all up and document it all".
<rant> It takes some chutzpah for commercial vendors to claim RHEL 7 "support" in their solutions, if they support neither selinux nor systemd.</rant>
Linked clones come from the same original image, right? So if you have truly separate VMs (appliances), does that still work? We don't have a SAN, we don't otherwise need a SAN.
The architecture that we have works for us. It's cheap, reliable and very easy to set up and maintain.
What a lot of the comments above essentially degenerate to is: replace a free and simple to use solution, that costs little to maintain (systemd) with multiple $10k worth of overhead in terms of hardware and software. I'd say that all this is an excellent argument for systemd, not against it. If I can get most of the start-up-time benefits of a very expensive VM/SAN setup just by using systemd, it'd be crazy not to use it.
All those things you speak of are extra elements that someone has to maintain, set up, pay licenses for, they are extra points of failure, etc. All to replace a rather simple piece of open-source software. Sigh.
If those larger organisations can't use Ethernet for what Ethernet was designed to be used, it's their fucking problem, thank you very much. Substituting a "process" for thinking is a very, very slippery slope.
Besides, Ethernet is an excellent point-to-point medium.
I've had some fun running CP/M on a system with two 8" floppy drives. One fine day I discovered the BIOS constant table on the particular implementation I had (can't remember the name of the system, though), and started "playing" with it. One bit in one of the constants would force a head load-unload cycle between access to each sector. Formatting a disk sounded like a machine gun with a tad sluggish action:)
Somehow spaces in file names have not been a problem for my command line use on Unix for many years now, and I don't pay much attention to them. Perhaps, just perhaps, whoever grumbles about that doesn't know any better?
I don't have many grudges with CP/M, but I remember using PIP, CP/M's file copying utility, and thinking that its command line syntax was utterly stupid. I was a 6 year old kid back then. That's one of the few opinions I've carried for most of my life. Sure, once you tried out the various incantations it'd accept (or read the fine manual), it was something you could learn, and I quickly became proficient, but it was needlessly counterintuitive for no good reason at all. When I first tried using it, I expected something that later tuned out to be the syntax that Unix cp and DOS copy would accept: cp source destination. Somehow that seemed like a natural syntax, even though I used CP/M before I even knew that PC/DOS existed, and I'd have my hands on a Unix machine almost a decade later. I've used CP/M, PC/DOS and MS/DOS, VAX VMS and IBM CP/CMS before Unix in fact:) I still think that Rexx on CMS was very, very cool.
It's hard to claim whether something is possible or not if you don't even know what the text means in the first place. Taken at face value it reads like patent nonsense. So you have to "interpret" the text. Once you do that, all bets are off.
To me, the question of whether anything in the bible is accurate (scientifically, historically, etc.) is essentially moot. The text, as-is, is not usable in answering any such questions. It's almost meaningless in this respect.
The so-called big data can replicate the "data" to each node, thus alleviating the interconnect requirements - most "big data" analytics is highly parallelizable with no interconnect. When you're doing big matrix inversions, the communications needs scale with the number of matrix elements...
The crypto is for the spacecraft control and for the vehicle mission termination systems. All subject to export controls and possibly using classified protocols.
It's not even about who controls what - it's simply that all the risk is on OSC. They have to pay for the engines whether they blow up or not, but they will eventually go out of business if their launch vehicle keeps blowing up. The subcontractors have very little risk passed onto them.
Given that the fuel "pumps" on rockets are rather highly stressed turbopump units, there's no way to discount a mechanical failure there. It's awfully easy for a compressor or turbine disc spinning at 10k+ RPMs to rip everything nearby to shreds when it decides to shed a blade. Of course it could just as easily be a failure in the combustion chamber or the piping, but yeah, it was clearly a mechanical failure. I just don't understand why you so offhandedly discount a turbopump unit failing.
Everything depends on whether you can estimate mission failure probability from the engine failure alone. Other things can go wrong too. I'm always worried about the software destroying their mechanically perfectly functional rocket in the style of Ariane 5's maiden flight.
The fuel "delivery" system is basically pipes and tank pressurization, if any. The fuel and oxidizer pumps and turbines that power them are an essential part of the engine. We're not talking about cars with their puny ICEs that can run with a gravity-fed carburetor. For reference, the F9 v1.1 1st stage pumps have combined flow rate of 1500 L/second.
Slashdot Mirror
It already works. So what's your point?
You can't make people use a device by edict. Just because a sports team, a league, or a broadcaster has signed some contracts, it doesn't magically make their users productive on another device. Microsoft dropped the ball by not providing decent applications for their own platform themselves. They supposedly know how to write software, yet they steadfastly refuse to write apps for their mobile platforms that are good enough to make people switch. All it'd take is good apps, nothing more, nothing less.
For that kind of money, you could hire an equivalent of two full-time engineers for a year to design that thing from the scratch for you, and you'd probably get a couple of production units out of that deal, too. You'd need an ME to do thermal and case design, shouldn't take longer than a couple months for that. An EE to do any custom mezzanine boards that one might need + wiring and overall electrical design. Finally, a software guy to make a config console etc. I assume that project management is not included in this. Overall, a startup with people who know what the heck they're doing would need $500k to pull it off, if they're any good at it.
The demonstrated reliability, performance and cost of the Virgin's concept is a step back. I don't care how good it looks on paper, even though it really doesn't, in reality it's a poorly performing disaster. The biggest issue is that it was never meant to be used to reach orbital velocity. It's a ballistic taxi, made to skim the some cream in a currently unexploited pseudospace tourist segment. It's a commercial venture whose goals are not space R&D.
They'd need to scale the energy delivered to their vehicle by a factor of 100, just to reach the low orbit of the ISS. Read again: factor of 100. Now tell me how the heck do you plan to scale their weekend ride by that factor. Yeah, doesn't take a rocket scientist to understand that it's a pipe dream.
This would be fine and dandy if we didn't already have perfectly usable ways of getting into orbit. You seemingly insist that we should be doing historical reproductions.
Virgin's endeavor is about a factor 100 away, energetically, from achieving orbit, and another factor of 10-100 away from getting to elsewhere either inside or outside of the solar system. This helps keep things in perspective. It's not space tourism. It's a rollercoaster, and a poorly designed one at that. I was their fan until one fine day it dawned on me that their approach is all fluff and no substance simply due to the reality of the amount of energy you need to do anything substantial in space. Their approach doesn't scale. It's simply a ballistic flight that goes a couple times higher than the vomit comet.
It started with a premise that has been demonstrated to be a bunch of good wishes, nothing more. The supposed simplicity of the engine doesn't mean that it requires no care. Given the time it took them, I'd say that the concept as executed by them won't ever work and is a failure. Perhaps it would work for someone else, but not for them.
Because it costs way more than a basic license of RHEL, and I don't care for either one of them. Yeah, ZFS would be nice. Whatever.
"I have an RHEL 6 system with multiple commercial Java applications." That's the difference you're looking for. I'm not running a barebones RHEL system. 95% of the resident set on that server is code that didn't come from any distro, it's the heaps of a multitude of JVMs and database servers that are bundled with commercial apps. Every one of those damn things takes at least 10 seconds to start up, and that's only if it's a simple thing. A full-stack application like Zimbra can be starting up for 40 seconds. There's also the issue of parallelizing the bring-up of network interfaces, which I did. For some reason a stock RHEL 6 takes 5+ seconds per network interface - I managed to parallelize that, too, and to set up dependencies between each interface and the services that use it. Since we isolate nodes on the internal network using tagged vlans, there's about 50 interfaces that have to be brought up, and most of them have no dependencies.
"If a service is critical, there should be a parallel server running it." Maybe in an alternate reality. Who can justify spending on a very decent server that is then vastly underutilized because you don't run everything you can on it? That "server" would be, at best, a VM. Of course a VM by itself doesn't fix the internal dependencies between elements of full-stack monolithic commercial apps.
It wouldn't matter if I used a pre-systemd Debian, since the serial shutdown of the commercial apps that I run would take 2 minutes. It's distro-independent after all, since all those apps are 3rd-party monoliths as far as the distro is concerned.
Again - we run a multitude of services - CRP/ERM, building automation, support for our own hardware, email (groupware), document management, phone system, security system, and a couple of other things, including support for our own R&D hardware labs. It's all on a stable, well-performing piece of hardware, that's well utilized with a bit of capacity to spare.
If you're a business, nothing is free. You have to spend the money, the question is how much do you spend and who are the checks written to. From the perspective of my business, not having free Linux is fairly immaterial, as the costs of supporting it and the multitude of applications we run on it far outstrip the cost of the OS. It really helps that we don't run it on big iron, but on plain old x86 hardware :)
I have an RHEL 6 system with multiple commercial Java applications. For some reason, every commercial Java application out there seems to bundle half of a linux distro with it: they insist on using their own instance of a web server, their own application server, their own database, their own mail daemon, etc. Starting those things serially is true insanity and takes forever.
With all of this stuff migrated to RHEL 7, tweaked so that there's no init + rc.d craziness left, a 4 minute boot-up turns into 1:30 boot-up. This is with spinning drives. I have another iteration of tweaks where I exposed all internal service dependencies inside each of those monolithic app monsters to systemd, and we can be up and running in 1:15. Looking at I/O statistics, with further judicious use of preloading we should cut it down to 1:00-1:05 after a clean shutdown. The shutdown times, usually well over 2 minutes long, are down to 30 seconds.
This is all measurable, no-bullshit, experimental data. We even managed not to have to touch any of the commercial app's rc scripts, I simply coded up the requisite systemd configurations for those services, based on the rc scripts. If there's any question as to systemd's effect on the application, or if we need to deal with vendor support, we can always start it up using the rc scripts.
So, I don't care about ideology behind systemd, and how it fits with someone's ideas about what Unix or a Linux distro should or shouldn't be. All I know is that it'd have taken me 5-10x as long to tweak the system rc.d scripts to parallelize them than it took me to "port" the commercial apps we use over to systemd. Of course the distribution's own services already use systemd, so I didn't have to touch that, only tweak a few things slightly to further leverage parallelism. It has saved us time and money, and the system availability is much better in face of the rare reboots. Everyone is happy. We're a small shop with a single server, and we use no virtualization nor any other enterprisey stuff. Just a plain old RHEL 7 running directly on hardware, with selinux turned on, with custom policies written for each of the commercial apps.
A lot of the "recommendations" I've got from "veteran" admins essentially reduced to throwing money and resources at the problem. That's IMHO a rather direct vindication of systemd: if it takes a SAN, multilevel storage and VMs just so that the damn init/rc.d-based system will boot in a reasonable amount of time, and all of that is taken care of by systemd, it'd be rather irresponsible for me to try and ignore systemd. In the name of what? Nothing I can think of. It's not like I can tell the management "hey, RHEL 7 comes with systemd, but I can keep using RHEL 6, not use systemd, and spend $25k+ for a SAN, VM and OS licenses, and the time to set it all up and document it all".
<rant> It takes some chutzpah for commercial vendors to claim RHEL 7 "support" in their solutions, if they support neither selinux nor systemd.</rant>
Linked clones come from the same original image, right? So if you have truly separate VMs (appliances), does that still work? We don't have a SAN, we don't otherwise need a SAN.
The architecture that we have works for us. It's cheap, reliable and very easy to set up and maintain.
What a lot of the comments above essentially degenerate to is: replace a free and simple to use solution, that costs little to maintain (systemd) with multiple $10k worth of overhead in terms of hardware and software. I'd say that all this is an excellent argument for systemd, not against it. If I can get most of the start-up-time benefits of a very expensive VM/SAN setup just by using systemd, it'd be crazy not to use it.
All those things you speak of are extra elements that someone has to maintain, set up, pay licenses for, they are extra points of failure, etc. All to replace a rather simple piece of open-source software. Sigh.
If those larger organisations can't use Ethernet for what Ethernet was designed to be used, it's their fucking problem, thank you very much. Substituting a "process" for thinking is a very, very slippery slope.
Besides, Ethernet is an excellent point-to-point medium.
I've had some fun running CP/M on a system with two 8" floppy drives. One fine day I discovered the BIOS constant table on the particular implementation I had (can't remember the name of the system, though), and started "playing" with it. One bit in one of the constants would force a head load-unload cycle between access to each sector. Formatting a disk sounded like a machine gun with a tad sluggish action :)
Somehow spaces in file names have not been a problem for my command line use on Unix for many years now, and I don't pay much attention to them. Perhaps, just perhaps, whoever grumbles about that doesn't know any better?
I don't have many grudges with CP/M, but I remember using PIP, CP/M's file copying utility, and thinking that its command line syntax was utterly stupid. I was a 6 year old kid back then. That's one of the few opinions I've carried for most of my life. Sure, once you tried out the various incantations it'd accept (or read the fine manual), it was something you could learn, and I quickly became proficient, but it was needlessly counterintuitive for no good reason at all. When I first tried using it, I expected something that later tuned out to be the syntax that Unix cp and DOS copy would accept: cp source destination. Somehow that seemed like a natural syntax, even though I used CP/M before I even knew that PC/DOS existed, and I'd have my hands on a Unix machine almost a decade later. I've used CP/M, PC/DOS and MS/DOS, VAX VMS and IBM CP/CMS before Unix in fact :) I still think that Rexx on CMS was very, very cool.
Cha-ching. This also means that it can't be true, and it can't be anything in between. It's utterly useless in that sense.
It's hard to claim whether something is possible or not if you don't even know what the text means in the first place. Taken at face value it reads like patent nonsense. So you have to "interpret" the text. Once you do that, all bets are off.
To me, the question of whether anything in the bible is accurate (scientifically, historically, etc.) is essentially moot. The text, as-is, is not usable in answering any such questions. It's almost meaningless in this respect.
The so-called big data can replicate the "data" to each node, thus alleviating the interconnect requirements - most "big data" analytics is highly parallelizable with no interconnect. When you're doing big matrix inversions, the communications needs scale with the number of matrix elements...
The crypto is for the spacecraft control and for the vehicle mission termination systems. All subject to export controls and possibly using classified protocols.
It's not even about who controls what - it's simply that all the risk is on OSC. They have to pay for the engines whether they blow up or not, but they will eventually go out of business if their launch vehicle keeps blowing up. The subcontractors have very little risk passed onto them.
Given that the fuel "pumps" on rockets are rather highly stressed turbopump units, there's no way to discount a mechanical failure there. It's awfully easy for a compressor or turbine disc spinning at 10k+ RPMs to rip everything nearby to shreds when it decides to shed a blade. Of course it could just as easily be a failure in the combustion chamber or the piping, but yeah, it was clearly a mechanical failure. I just don't understand why you so offhandedly discount a turbopump unit failing.
Everything depends on whether you can estimate mission failure probability from the engine failure alone. Other things can go wrong too. I'm always worried about the software destroying their mechanically perfectly functional rocket in the style of Ariane 5's maiden flight.
The fuel "delivery" system is basically pipes and tank pressurization, if any. The fuel and oxidizer pumps and turbines that power them are an essential part of the engine. We're not talking about cars with their puny ICEs that can run with a gravity-fed carburetor. For reference, the F9 v1.1 1st stage pumps have combined flow rate of 1500 L/second.