Yes, but the question is whether this has been a pattern or a first offence. If this was the first time the person did something like this, it's arguably even worse. Usually if you are a maintainer in good standing, a single questionable design choice in a pull request wouldn't be met with that much vitriol. You have proven yourself to put out generally good work, but you mucked up once. A rejection with a counter-proposal saying 'this is not readable, I counter propose' would be enough to get the picture...
Knowing that no matter my reputation, I do one thing that Linus doesn't like and it could result in insta-rant I could see as discouraging for those used to more level headed discourse.
However, I restate that if I had to choose between passionate, rant-ready maintainer enforcing a consistent design versus all-welcoming maintainer that allows things to point of chaos, I'd pick the rants.
At least without context, the tone seems a bit severe for the rejection, and could bolster the case of those that argue that a violent shaming is a risk of submitting code, even if it would be your first 'mistake'.
I personally prefer this over some other projects that would merge functional, but ugly code for the sake of not scaring folks away from contributing and not having 'it doesn't work' argument to respond with, but there could be a happy medium.
but yet he allowed the crap that is systemd in the house
Linus doesn't have control over places that systemd are 'in the house'. The biggest notable chunk that would be even remotely perceived as letting systemd into the kernel is kdbus, and that hasn't been merged. Even then, I have heard arguments that it isn't particularly systemd specific. Knowing about dbus, makes me shudder about the concept of kdbus, but folks assure me I don't understand kdbus, which I confess could be true.
Linus basically doesn't have much to say about systemd today, it's beyond the scope of his attention. He has mentioned he is at least not horribly opposed to it, but neither has he gave it a huge endorsement either. He has ranted about code that came to the kernel from at least one of systemd's notable contributors, but not about the concept/project as a whole.
But all that aside, no one should treat Linus' word as the one true word of the whole ecosystem. If he loves it, hates it, or does not care, either way the larger community has to decide.
nVidia is investing in making Linux drivers, that is how they are 'there'. Now how much of it pertained to desktop gaming versus how much gaming benefits from them having to do drivers anyway for workstation and HPC. The point stands that in spite of some folks demanding a purist open source experience, reality is a compromise.
actually has to pay the full marketing cost to keep the same level of customer inquiries
But that's just not true. Let's say Ford stopped advertising today. In 5 years time, would people still have awareness of Ford? Of course they would, they are an established name that is ubiquitous. That's not to say there would be no ill effects, but once a brand is known, it is not trivially forgotten, so long as they keep doing their business. Here was a no-name company had effectively zero brand awareness for what they do. Then they got brand awareness through an incidental channel, but that will fade. However a critical mass of customers will sustain the brand strength once acquired, so long as those clients aren't given a good reason to jump ship and the company keeps doing it's job. Word of mouth sustains elevated interest when there are actually clients. It will never ever be possible to show causation of the actual strategy rather than the incidentals of the strategy.
Exacerbating the issue as you go out a few years is that a nearly infinite other set of factors will play their roles making the ability to guess the effects even more and more tenuous.
For this to be informative, it would have to happen to a lot of companies and their business results measured in aggregate, mitigating the effect of common other factors as much as possible.
When they copy/paste snippet of article that has 4 as superscript, but present it as plain text, and they don't bother editing at all because that would be work.
Even after the media attention has died out, the awareness of the company has been catapulted forward in irrevocable way. No one knew who they were before, now they are known for their media attention getting pay policy, and now people actually know who they are for the business they do. So long as their service makes business sense, awareness acquired under one strategy is not that unreasonable to retain just by 'doing your job'.
Not saying it's a bad idea or can't help or that it's a good idea and can't hurt, just saying this case is a lost cause for a controlled understanding of the impact of this strategy absent of the media attention no matter how close you look and long you wait.
Note that from the perspective of their strategy on the x86 hardware front, I'm bearish. From the perspective of will HP manage to find some other completely distinct strategy to leverage their name to be a business, I'm not so sure. Again, look at IBM. Their x86 server business tanked, but that had little bearing on their aggregate business results (though those are relatively troubled as well). IBM started selling cash register type equipment, and now they have 0 footprint in the market. Predicting their exit from their original market and shorting their stock based on that would have been unwise.
A public cloud business, regardless of technical ability and capability, just doesn't align with HP's current goals well. It's a thankless low margin business from the start, which is not the sort of thing for HP to 'fix' what investors perceive as their challenges. It's also a good way to piss off potential clients that end up competing, though that's mitigated by HP's complete inability to get any market share.
As far as openstack goes, I'd say it is afflicted by the curse of getting buzz from businesses too early in it's life. Now it's a sort of unholy mess of stuff polluted by a lot of conflicting corporate interests, and no good outlook to redo some of those decisions. Linux is an example of fortunate interaction with business interests. It got established before toxic business interests came along, and so fundamental architecture wasn't so much at the whim of those interests. Also, it is more strongly led, whereas openstack is just a sort of amalgamation of code running largely amok without structured checks and balances (in relative terms, there are worse projects that are pretty ubiquitous too, but not so high profile).
Yes, HP's mistake was even trying (and I would extend that to IBM too). I think they are reasonable business endeavors overall, but IBM and HP are in a position to be crucified by shareholders that are spoiled and expecting gigantic margins out of those brands. Investing to try to satisfy those investors through going toe to toe with Amazon, widely known for willing to operate on no to negative margin.
I think Dell and to some extent Lenovo are advantaged here. Dell by being private don't have to answer to historically spoiled shareholders, despite the reality changing. Lenovo is public, but expectations are lower, which provides an interesting sort of freedom to not bend over backwards to do stupid stuff to satisfy dumb shareholders. It's still a viable business to be in, but the nature of business results just don't resemble the expectations of an IBM or HP shareholder.
Either way it's a shell game for the investors. The problem of being a publicly traded company in this position is that they have to do things to appease shareholders that are actually pretty dumb.
Case in point here, splitting their enterprise x86 stuff from their PC stuff is mind numbingly stupid as hell. IBM did it and it seriously screwed up their x86 server stuff. You can do a bit better than break even on consumer space, but in the process you have massive negotiating power with component vendors. Intel wants in on a tablet play, sure, but need price breaks on Xeons for the opportunity. Hynix wants to sell modules into your laptops? Sure, but need a price break on RDIMMs.
Splitting it up may help to settle disputes about who is doing what margin-wise versus revenue wise versus total profit, but it's pretty good way to cripple your supplier negotiating power, which is really what matters here.
emby backend, kodi front end for media. Ripped from DVD and blu rays using makemkv and handbrake (the former I've found to be needed after trying to use only handbrake for a while) mythbackend, and I still use myth frontend. Tried to use the kodi frontend but it would never shut the hell up about notifications and it seems not to be configurable, and kodi's seek to a video from mythtv is terrible compared to mythfrontend.
There's also a netflix subscription in play, though increasingly less time is spent. It's frustrating as shows disappear in the midst of being watched, or a season is unavailable, or if I want to revisit a series again. It's all you can watch renting which is sometimes nice, but getting as close to 'owning' as the media companies allow is better (at least having something they cannot 'revoke' my ability to watch).
I can't believe how many people continue to hold on to the concept that once unit testing is added to a project, suddenly the code is bulletproof and cannot be broken without detection. I'm doubly astonished when they hold on to that thought even in the face of bugs cropping up when put to use.
That's not to say the strategy is totally without merit, but it should be considered a mitigation of risk rather than a removal of risk.
True, I generally put in an apologetic comment pointing out the duplication and why and how I tried to make it so that it won't get duplicated more than the one incident for this specific reason.
Automated testing is valuable, but not perfect in practice. For most real code, you cannot hit every possible set of inputs, and settle for only the ones folks realize are 'interesting' (given that for much code, the set of inputs is in fact theoretically unlimited). Generally those tests accumulate over time as real-world defects drive recognition of "oh, yeah, another 'interesting' case we didn't consider before". 'Comprehensive' is generally not a possible absolute goal. I know a lot of folks who genuinely believe now that we have a paradigm of automated unit tests and test driven development, there is no longer a need for maintenance branches or more real world testing than what happens in response to a commit. Amazingly, this frequently continues even after several instances in their 'comprehensively covered' unit test project having reported bugs when going to production, dismissing those bugs as 'really freak situations'. It doesn't help that people celebrate declaration of '100% covered' in unit tests, as if that is some milestone that makes bugs totally impossible then.
Now it can be that for a very simple function, the practical risk of missing unanticipated scenarios is low. However, I was speaking to a function that you end up duplicating and refactoring without perturbing the original instance, instead of refactoring that too. In that scenario, if it does *almost* what you need but not quite, it's almost certainly in the class of functions that existing unit tests do not provide 100% coverage.
If you break critical production code that has been doing it's job for several years, not because it had a different problem that was trying to be fixed, not because it is slow, but because it would be 'cleaner' to be refactored, then you will likely be rightfully fired for a poor judgement call.
Also agreed about too many classes. People think they make nice modular things by having short classes, but I just went through an exercise of pouring through about a dozen mind numbingly tedious files to find the single line of code that actually did something rather than just do a few pointlessly segregated checks or providing an alternative function for what '+=' already did or coercion into some datatype only to have it coerced back 'just in case' that middle layer might one day have another developer that would naturally think of it another way...
Adding another variant, when you have an existing function that you never expected to reuse part of, suddenly interested in a twist on it. The 'proper' answer is to refactor so that it is shared code, but the code being reused is something that's not changed in 3 years and never had an issue under impressive load. So I could either refactor including changing working code, or duplicate. I'll duplicate. Now my duplicate may break out the relevant code so that if such a circumstance arise later, that the duplication won't happen twice, but I would rather a duplicate exist than risk any change to proven code.
This here is my pet peeve of most 'modern' code projects, an insane call stack. Sometimes there's good reason, but often it's simply because the project is badly duct taped together rather than carefully thought out.
Exacerbated in a lot of cases even more by having multiple over the network calls to chain several of these sorts of atrocities together. I have seen a team charged with being a sort of single middleware for a pretty straightforward sort of job self-create 4 distinct processes that each get involved in every transaction, traversing not only multiple server side languages (python, perl, groovy, and java), and multiple frameworks of each language (django, another home grown python thing, spring), each layer imposing their own HTTP based api, and two of them having their own SQL datastore and a third also having a distinct datastore, just not SQL.
Not only for yourself, but for your children. Someone who is brought up in the context of conspicuous wealth seems at risk to *never* form/understand relationships outside of that context.
Or not even temporarily rich. I know someone who could barely make ends meet who spent new-car scale money on a 15 year old Mercedes, despite it being horrendously unreliable and actually not at very luxurious or in any way good even compared to a more recent economy sedan. However they just loved the fact their vehicle had a Mercedes logo on it. I was baffled at their decision to do that rather than spend significantly less on a 2-3 year old mainstream sedan or about the same for a brand new sedan.
I suspect the concept he refers to is to loan money more informally, without any sort of interest. I would say it's probably a precarious situation for someone of wealth to 'loan' money to a less fortunate friend. If they really need money, a gift of money to help them out or more directly helping them with the expensive issue at hand. If it's a 'I'd like to start up this *great* idea for a business I have', that's a situation that is hard to 'win' on, and it would be more appropriate for them to get a business loan just like everyone else in that position would do. If it's loan, then there's awkwardness and resentment around repayment (why should someone who is poorer give back money to a richer person). If it is buying a stake in the business, then the same awkwardness can result... Being a shareholder and a friend at the same time does not make for a comfortable dynamic. Of course, saying yes under any terms and saying no both lead to an awkward circumstance.
I have observed that to be true going to a gathering held by a wealthy friend of mine. He is wealthy, but most people attending were not. Also, most people there are people he had known since high school, prior to him getting wealthy.
Of course, if you are born into wealth, your upbringing may not afford you that option, since everyone new and old may know you as 'wealthy' and have the potential for ulterior motives that go with it.
However, it's not wealth that is really isolating, it's the lifestyle choice. Again referencing my wealthy friend, he will show up at gatherings we less-than-wealthy folks hold. People are there who don't know him and aren't aware of his wealth don't give him any particularly special regard because he'll show up in some average looking sedan in average apparel and only once have I known him to tell a story that made it obvious to folks unaware of his income situation that he must be wealthy (involving his dealings with a more famously wealthy individual). It's quite possible to be wealthy and pretty anonymous in your wealth for the most part if you choose. Of course, again, folks who grow up wealthy may not actually understand how to conduct themselves or enjoy such a lifestyle in that way.
Yeah, that's the interesting thing. If you just follow the desktop parts, performance has been modestly improving and power consumption is dipping. Meanwhile on the server side, power consumption has been more steady and the core count has been going drastically up. Sure workloads that don't scale to many cores aren't getting that much of a boost (and that is the state of most desktop platforms), but areas with multithreaded workload and/or consolidated bunch of single threaded workload have continued to benefit from advances.
Slashdot Mirror
Problem being that if you do not take care of your security, you are also likely to not take care of your own security in your cloud instances.
For example, not too long ago some company got bit by leaving something wide open in how they set up their EC2 instances.
You cannot sprinkle on security as an afterthought either way, security is a factor that must be kept in mind as you do the design.
Yes, but the question is whether this has been a pattern or a first offence. If this was the first time the person did something like this, it's arguably even worse. Usually if you are a maintainer in good standing, a single questionable design choice in a pull request wouldn't be met with that much vitriol. You have proven yourself to put out generally good work, but you mucked up once. A rejection with a counter-proposal saying 'this is not readable, I counter propose' would be enough to get the picture...
Knowing that no matter my reputation, I do one thing that Linus doesn't like and it could result in insta-rant I could see as discouraging for those used to more level headed discourse.
However, I restate that if I had to choose between passionate, rant-ready maintainer enforcing a consistent design versus all-welcoming maintainer that allows things to point of chaos, I'd pick the rants.
At least without context, the tone seems a bit severe for the rejection, and could bolster the case of those that argue that a violent shaming is a risk of submitting code, even if it would be your first 'mistake'.
I personally prefer this over some other projects that would merge functional, but ugly code for the sake of not scaring folks away from contributing and not having 'it doesn't work' argument to respond with, but there could be a happy medium.
but yet he allowed the crap that is systemd in the house
Linus doesn't have control over places that systemd are 'in the house'. The biggest notable chunk that would be even remotely perceived as letting systemd into the kernel is kdbus, and that hasn't been merged. Even then, I have heard arguments that it isn't particularly systemd specific. Knowing about dbus, makes me shudder about the concept of kdbus, but folks assure me I don't understand kdbus, which I confess could be true.
Linus basically doesn't have much to say about systemd today, it's beyond the scope of his attention. He has mentioned he is at least not horribly opposed to it, but neither has he gave it a huge endorsement either. He has ranted about code that came to the kernel from at least one of systemd's notable contributors, but not about the concept/project as a whole.
But all that aside, no one should treat Linus' word as the one true word of the whole ecosystem. If he loves it, hates it, or does not care, either way the larger community has to decide.
nVidia is investing in making Linux drivers, that is how they are 'there'. Now how much of it pertained to desktop gaming versus how much gaming benefits from them having to do drivers anyway for workstation and HPC. The point stands that in spite of some folks demanding a purist open source experience, reality is a compromise.
actually has to pay the full marketing cost to keep the same level of customer inquiries
But that's just not true. Let's say Ford stopped advertising today. In 5 years time, would people still have awareness of Ford? Of course they would, they are an established name that is ubiquitous. That's not to say there would be no ill effects, but once a brand is known, it is not trivially forgotten, so long as they keep doing their business. Here was a no-name company had effectively zero brand awareness for what they do. Then they got brand awareness through an incidental channel, but that will fade. However a critical mass of customers will sustain the brand strength once acquired, so long as those clients aren't given a good reason to jump ship and the company keeps doing it's job. Word of mouth sustains elevated interest when there are actually clients. It will never ever be possible to show causation of the actual strategy rather than the incidentals of the strategy.
Exacerbating the issue as you go out a few years is that a nearly infinite other set of factors will play their roles making the ability to guess the effects even more and more tenuous.
For this to be informative, it would have to happen to a lot of companies and their business results measured in aggregate, mitigating the effect of common other factors as much as possible.
When they copy/paste snippet of article that has 4 as superscript, but present it as plain text, and they don't bother editing at all because that would be work.
Even after the media attention has died out, the awareness of the company has been catapulted forward in irrevocable way. No one knew who they were before, now they are known for their media attention getting pay policy, and now people actually know who they are for the business they do. So long as their service makes business sense, awareness acquired under one strategy is not that unreasonable to retain just by 'doing your job'.
Not saying it's a bad idea or can't help or that it's a good idea and can't hurt, just saying this case is a lost cause for a controlled understanding of the impact of this strategy absent of the media attention no matter how close you look and long you wait.
Note that from the perspective of their strategy on the x86 hardware front, I'm bearish. From the perspective of will HP manage to find some other completely distinct strategy to leverage their name to be a business, I'm not so sure. Again, look at IBM. Their x86 server business tanked, but that had little bearing on their aggregate business results (though those are relatively troubled as well). IBM started selling cash register type equipment, and now they have 0 footprint in the market. Predicting their exit from their original market and shorting their stock based on that would have been unwise.
A public cloud business, regardless of technical ability and capability, just doesn't align with HP's current goals well. It's a thankless low margin business from the start, which is not the sort of thing for HP to 'fix' what investors perceive as their challenges. It's also a good way to piss off potential clients that end up competing, though that's mitigated by HP's complete inability to get any market share.
As far as openstack goes, I'd say it is afflicted by the curse of getting buzz from businesses too early in it's life. Now it's a sort of unholy mess of stuff polluted by a lot of conflicting corporate interests, and no good outlook to redo some of those decisions. Linux is an example of fortunate interaction with business interests. It got established before toxic business interests came along, and so fundamental architecture wasn't so much at the whim of those interests. Also, it is more strongly led, whereas openstack is just a sort of amalgamation of code running largely amok without structured checks and balances (in relative terms, there are worse projects that are pretty ubiquitous too, but not so high profile).
Yes, HP's mistake was even trying (and I would extend that to IBM too). I think they are reasonable business endeavors overall, but IBM and HP are in a position to be crucified by shareholders that are spoiled and expecting gigantic margins out of those brands. Investing to try to satisfy those investors through going toe to toe with Amazon, widely known for willing to operate on no to negative margin.
I think Dell and to some extent Lenovo are advantaged here. Dell by being private don't have to answer to historically spoiled shareholders, despite the reality changing. Lenovo is public, but expectations are lower, which provides an interesting sort of freedom to not bend over backwards to do stupid stuff to satisfy dumb shareholders. It's still a viable business to be in, but the nature of business results just don't resemble the expectations of an IBM or HP shareholder.
Either way it's a shell game for the investors. The problem of being a publicly traded company in this position is that they have to do things to appease shareholders that are actually pretty dumb.
Case in point here, splitting their enterprise x86 stuff from their PC stuff is mind numbingly stupid as hell. IBM did it and it seriously screwed up their x86 server stuff. You can do a bit better than break even on consumer space, but in the process you have massive negotiating power with component vendors. Intel wants in on a tablet play, sure, but need price breaks on Xeons for the opportunity. Hynix wants to sell modules into your laptops? Sure, but need a price break on RDIMMs.
Splitting it up may help to settle disputes about who is doing what margin-wise versus revenue wise versus total profit, but it's pretty good way to cripple your supplier negotiating power, which is really what matters here.
emby backend, kodi front end for media. Ripped from DVD and blu rays using makemkv and handbrake (the former I've found to be needed after trying to use only handbrake for a while)
mythbackend, and I still use myth frontend. Tried to use the kodi frontend but it would never shut the hell up about notifications and it seems not to be configurable, and kodi's seek to a video from mythtv is terrible compared to mythfrontend.
There's also a netflix subscription in play, though increasingly less time is spent. It's frustrating as shows disappear in the midst of being watched, or a season is unavailable, or if I want to revisit a series again. It's all you can watch renting which is sometimes nice, but getting as close to 'owning' as the media companies allow is better (at least having something they cannot 'revoke' my ability to watch).
I don't think this would be as thrilling of a James Bond movie as License to Kill....
I can't believe how many people continue to hold on to the concept that once unit testing is added to a project, suddenly the code is bulletproof and cannot be broken without detection. I'm doubly astonished when they hold on to that thought even in the face of bugs cropping up when put to use.
That's not to say the strategy is totally without merit, but it should be considered a mitigation of risk rather than a removal of risk.
True, I generally put in an apologetic comment pointing out the duplication and why and how I tried to make it so that it won't get duplicated more than the one incident for this specific reason.
Automated testing is valuable, but not perfect in practice. For most real code, you cannot hit every possible set of inputs, and settle for only the ones folks realize are 'interesting' (given that for much code, the set of inputs is in fact theoretically unlimited). Generally those tests accumulate over time as real-world defects drive recognition of "oh, yeah, another 'interesting' case we didn't consider before". 'Comprehensive' is generally not a possible absolute goal. I know a lot of folks who genuinely believe now that we have a paradigm of automated unit tests and test driven development, there is no longer a need for maintenance branches or more real world testing than what happens in response to a commit. Amazingly, this frequently continues even after several instances in their 'comprehensively covered' unit test project having reported bugs when going to production, dismissing those bugs as 'really freak situations'. It doesn't help that people celebrate declaration of '100% covered' in unit tests, as if that is some milestone that makes bugs totally impossible then.
Now it can be that for a very simple function, the practical risk of missing unanticipated scenarios is low. However, I was speaking to a function that you end up duplicating and refactoring without perturbing the original instance, instead of refactoring that too. In that scenario, if it does *almost* what you need but not quite, it's almost certainly in the class of functions that existing unit tests do not provide 100% coverage.
If you break critical production code that has been doing it's job for several years, not because it had a different problem that was trying to be fixed, not because it is slow, but because it would be 'cleaner' to be refactored, then you will likely be rightfully fired for a poor judgement call.
Also agreed about too many classes. People think they make nice modular things by having short classes, but I just went through an exercise of pouring through about a dozen mind numbingly tedious files to find the single line of code that actually did something rather than just do a few pointlessly segregated checks or providing an alternative function for what '+=' already did or coercion into some datatype only to have it coerced back 'just in case' that middle layer might one day have another developer that would naturally think of it another way...
Adding another variant, when you have an existing function that you never expected to reuse part of, suddenly interested in a twist on it. The 'proper' answer is to refactor so that it is shared code, but the code being reused is something that's not changed in 3 years and never had an issue under impressive load. So I could either refactor including changing working code, or duplicate. I'll duplicate. Now my duplicate may break out the relevant code so that if such a circumstance arise later, that the duplication won't happen twice, but I would rather a duplicate exist than risk any change to proven code.
a call stack 20 layers deep.
This here is my pet peeve of most 'modern' code projects, an insane call stack. Sometimes there's good reason, but often it's simply because the project is badly duct taped together rather than carefully thought out.
Exacerbated in a lot of cases even more by having multiple over the network calls to chain several of these sorts of atrocities together. I have seen a team charged with being a sort of single middleware for a pretty straightforward sort of job self-create 4 distinct processes that each get involved in every transaction, traversing not only multiple server side languages (python, perl, groovy, and java), and multiple frameworks of each language (django, another home grown python thing, spring), each layer imposing their own HTTP based api, and two of them having their own SQL datastore and a third also having a distinct datastore, just not SQL.
Not only for yourself, but for your children. Someone who is brought up in the context of conspicuous wealth seems at risk to *never* form/understand relationships outside of that context.
Or not even temporarily rich. I know someone who could barely make ends meet who spent new-car scale money on a 15 year old Mercedes, despite it being horrendously unreliable and actually not at very luxurious or in any way good even compared to a more recent economy sedan. However they just loved the fact their vehicle had a Mercedes logo on it. I was baffled at their decision to do that rather than spend significantly less on a 2-3 year old mainstream sedan or about the same for a brand new sedan.
I suspect the concept he refers to is to loan money more informally, without any sort of interest. I would say it's probably a precarious situation for someone of wealth to 'loan' money to a less fortunate friend. If they really need money, a gift of money to help them out or more directly helping them with the expensive issue at hand. If it's a 'I'd like to start up this *great* idea for a business I have', that's a situation that is hard to 'win' on, and it would be more appropriate for them to get a business loan just like everyone else in that position would do. If it's loan, then there's awkwardness and resentment around repayment (why should someone who is poorer give back money to a richer person). If it is buying a stake in the business, then the same awkwardness can result... Being a shareholder and a friend at the same time does not make for a comfortable dynamic. Of course, saying yes under any terms and saying no both lead to an awkward circumstance.
I have observed that to be true going to a gathering held by a wealthy friend of mine. He is wealthy, but most people attending were not. Also, most people there are people he had known since high school, prior to him getting wealthy.
Of course, if you are born into wealth, your upbringing may not afford you that option, since everyone new and old may know you as 'wealthy' and have the potential for ulterior motives that go with it.
However, it's not wealth that is really isolating, it's the lifestyle choice. Again referencing my wealthy friend, he will show up at gatherings we less-than-wealthy folks hold. People are there who don't know him and aren't aware of his wealth don't give him any particularly special regard because he'll show up in some average looking sedan in average apparel and only once have I known him to tell a story that made it obvious to folks unaware of his income situation that he must be wealthy (involving his dealings with a more famously wealthy individual). It's quite possible to be wealthy and pretty anonymous in your wealth for the most part if you choose. Of course, again, folks who grow up wealthy may not actually understand how to conduct themselves or enjoy such a lifestyle in that way.
Yeah, that's the interesting thing. If you just follow the desktop parts, performance has been modestly improving and power consumption is dipping. Meanwhile on the server side, power consumption has been more steady and the core count has been going drastically up. Sure workloads that don't scale to many cores aren't getting that much of a boost (and that is the state of most desktop platforms), but areas with multithreaded workload and/or consolidated bunch of single threaded workload have continued to benefit from advances.