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.

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.

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.

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.

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.

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.

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.

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.

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.

This isn't that hard to understand.