If I can pay my bills or buy something with Bitcoin, it's the exception and not the rule
That's a low bar to set. If you can get a price or invoice in BTC that gives you a month to pay it off, then I'll start considering it a viable 'currency'. Accepting bitcoin with just-in-time pricing is very low risk and it's cheap for a company to do that for publicity with no downside. A company need not believe in bitcoin in all to do it. A company believes in bitcoin if it will commit to a long term price for anything it supplies or purchases.
by your argument, dell selling computers in france and generating euros would be a sham because they then call their bank to convert to USD (their reporting currency) at some point.
If 'at some point' is 'when tax laws and reporting make it most effective' it is a bit different than 'at some point' being seconds after the sale, with quotes longer than 15 minutes being considered invalid.
Notably dell will announce products with MSRP in dollars, euros, pounds, etc. They will not do the same in BTC, they will instead do a just-in-time quote that is invalid about as quickly as they can get away with. There is no even vague assumption about BTC value from one hour to the next, unlike the other currencies.
"Actual" currency is just the middleman to trading goods and services.
But people 'save' currency and plan retirements around quantities of it and such. Value fluctuations are real and troublesome of course, but in general this works. I give a company 30,000 dollars and they will keep it in an account for some non-trivial time and report their quarterly success in terms of those figures. They will at least talk about the value of currency in a manner that assumes pretty much absolute stability over 3 months and even project their expectations for how much money they will get and spend over the next several years.
All the companies worth their salt that elect to engage in bitcoin in a way to get publicity, but none want to plan for the value of the 'currency' for more than 15 minutes. You won't see dell doing a promotional price in terms of the bitcoin value, but rather you get the price converted to bitcoin as you pay for it with a quote that is invalid 20 minutes later.
Long story short, MS has proved they can buy a large market, but cannot figure out how to make a profit after achieving that end.
xbox 360 enjoyed a very brief couple of years of profitability that waned too quick to pay for the losses suffered in the years prior. xbox one tried to cash in on some of the carefully cultivated brand value only to see a fickle market jump sides and show their really wasn't much persistent brand loyalty (a lesson that also bit Sony in the ass in PS3). It's the only way I can figure MS would offer a lower spec system at significantly higher cost, a hail mary for margins to see if they could hit the ground profitable since so many people seemed to 'love' their xbox 360.
Also, xbox did nothing to build up the 'microsoft' brand, it basically built a new brand 'xbox'. Attempts to leverage that outside of gaming have fallen flat, so they don't get any residual benefit from the business unit whatsoever.
I'm guessing xbox one will be the last venture for MS-owned gaming. I suspect they will sell the brand since it has undeniable value, but MS cannot figure out how to profit from that and so it is time for them to give up.
It's also time to give up on surface RT (I frankly thought it was a misguided attempt in the first place) and on being a hardware company in general. All surface, surface pro, and nokia did was alienate current and potential partners. Looking at the market trends it is clear that 'trying to do it the apple way' is the wrong way. Apple is the only one to even remotely make it work, and they are losing ground to Android at large. This is actually very similar to how MS surpassed Apple, through a large ecosystem of vendors competing against each other by leveraging a common arms dealer. Problem for MS is that Google monetizes the platform in a different way so the classic 'pay for your software license' model that MS is used to doesn't fly.
Or it could be a deviation that had little to no practical downside in selection since the world rarely went that weird in the past. It would explain why motion sickness is so prevelant, yet not close to universal. There may just have been very little selective pressure either way.
I think on the poison theory, if your senses are impacted, the ship has sailed on ejecting the poison.
If it was a selected-for trait, my completely unsubstantiated guess would be something about falling out of or maneuvering within trees. After all, people who get motion sick can get sick in excessively peculiar real-world motion without messing with reference points (e.g. some people do it on roller coasters without looking at the car that much, or on boats without looking at the floor).
I have high hopes that the movement won't bother me, I've never had a hint of the issues many report, though I haven't tried VR, per se.
I will say even if there is a problem for people who can stand it when it's a conventional screen but lose it at the threshold of VR, there is yet hope for FPS genre without cockpits. Imagine playing your game and the monitor having the appearance of a movie theater screen. An experience that is totally impractical in reality, but not really much of a big deal in VR. There is a lot of interest in things like VR Cinema and virtual desktop (https://developer.oculusvr.com/forums/viewtopic.php?f=29&t=8182). In both cases, the medium is still fundamentally not motion sensing or surrounding in any way, but the concept of playing with screen size, curvature, and distance freely all while not imposing any particular posture is quite appealing.
The part that I'm wondering about is with these new, ultra efficient companies that merge up like crazy how much work is there going to be for the rest of us to do? Between that an automation it just looks like we're running out of work to do..
I think that's a bit of overestimation of these 'new, ultra efficient' companies. The volume of IT work has increased a lot over the past couple of decades, despite a seemingly more homogenous IT world with fewer 'newer, ultra efficient' companies (compared to the state of things in the early 90s).
In practice, the industry has just been shuffling I think. Some key specific cases see some gains or else loudly think they got gains, but there are losers too.
Some areas that were more automation friendly actually get less automated (some expensive automation features are falling out of favor in some datacenters in favor of low lost local labor). Many of these have sensibilities of 'buy a whole new server' rather than trying to fix something, meaning more volumes for their server vendors.
In the rise of 'cloud' we see a phenomenon where a lot of companies end up paying twice. They outsource their needs, but find out their IT staff actually is still needed (since the cloud providers actually don't help on as much as the stack as would be needed, and even when they do, they don't find a lot of takers). So they end up funding more headcount for their provider without getting to significantly reduce their own (which frequently means increased actual IT cost).
This is a bit on the pessimistic side of things, but these phenomenon add up to the chase for the 'magic bullet' continually driving change but not necessarily workforce reduction.
The closest thing to concrete data about that whole situation could accurately describe: -Agency plugs in lenovo laptop with preload intact -Agency notes that a TCP SYN packet was sent to China, but not allowed to actually get there. -Agency says 'screw it' and bans it without further analysis
This could be nefarious or it could be checking for firmware or driver updates. There's no way to guess what really happened without details of any investigation coming to light.
Keep in mind that it was likely an activity driven by some agenda. Notably, these agencies start from a perspective of 'distrust china' and consider it their job to prevent that vendor selling into agencies. So they seek the flimsiest reason to hold up to impose a ban, which no one really objects too hard to since it's politically better to not source from China anyway. The agencies may not have detected a real threat, but they likely presume a real threat is a significant possibility that they have no way of practically detecting, so they run with this.
If there was an unambiguous backdoor seen, you bet your ass the agencies would be shouting from the rooftops. Instead, they are doing enough to keep it away from sensitive areas, but not so much to invite much scrutiny.
Finally, if China *really* wants backdoors, they don't need to actually have even slight ownership of the company. All the big companies gleefully hand over pretty much full control of their manufacturing and much of their hardware design, software, and firmware development to China anyway. The nationality of the CEO means approximately nothing in the scheme of state sponsored espionage.
Those early days are over and 3.x is intentionally designed to be more rational and consistent.
The issue being that is *always* the case. In the early python 2 days, they thought the 'early' days were over. I haven't dealt with python 3 with sufficient depth to be keenly aware of any real gotchas, but the fact they decided to add back in the explicit unicode syntax is a sign that they have at least continued to indulge in flux to fix bad design decisions. In that specific case, I don't see a downside for the increased ability to have python2/3 agnostic code so I won't declare any example of breaking 3.x series code with that. It seems clear to me that the python language can't quite exercise enough restraint in their enthusiasm for their vision of improved syntax and features to walk away confident that code won't break in a couple of 3.x generations.
It's almost like a curse, the more popular and energetic a language implementation is, the more likely it is to experience some incompatible evolution.
As the hip kids would say 'un-pythonic'. It's sort of like how perl can be perfectly readable until people go and start using all the language features in 'clever' ways. Making a dict on the fly and indexing it in the same statement is the sort of thing I could see rendering python code hard to read and follow...
Python is a language that has a fascinating tendency to break python on version upgrades. Yes, there is very clearly the python 2 to python 3, but even python 2.3 to python 2.6 can create worlds of headaches.
But then again no language is perfect. Old C code is frequently hard to build on modern compilers, perl had a very long history of not needing anything to be touched but some of the disilliusionment in prel 6 has caused even perl5 to get a bit fidgety as of late.
Why not hold people not claiming to be scientists to a higher standard? It's not like their science-but-don't-call-it-science experiments are any less potentially damaging than the same behavior done by a 'true scientist'.
I fail to see how it's that different than the manipulation that mass media does, who also do not get informed consent. There is the facet of it being more targeted, but the internet is already about targeted material (hopefully done with the best interest of the audience in mind, practically speaking with the best interests of the advertiser). They just stop short of calling it an 'experiment' (in practice, they are continually experimenting on their audience) and somehow by not trying to apply scientific rigor they get off the hook.
I'm not saying that Facebook is undeserving of outrage, I'm saying that a great deal of the media behavior is similarly deserving and somehow we are complacent with that situation.
My question is why is there particular outrage when they do it as part of a science experiment whereas it is widely acceptable to do the exact same thing in mass media to get revenue.
National and local news programs basically live and breath this sort of thing constantly. They schedule their reporting and editorialize in ways to boost viewership: stirring up anger, soothing with feelgood stories, teasing with ominous advertisements, all according to presumptions about the right way to maximize viewer attention and dedication. 'What everyday item in your house could be killing you right now, find out at 11'.
I don't have a Facebook account precisely because I don't like this sort of thing, but I think it's only fair to acknowledge this dubious manipulative behavior is ubiquitous in our media, not just as science experiments in Facebook.
If you deploy new software where it does not improve the user experience, then it's valid for the userbase to punish that move to a reasonable extent.
Not to the end result in this article of course, but sharing the pain inflicted by 'change for change's sake' with those who inflict it makes a lot of sense. Sometimes there are requirements to be fulfilled that do matter that make life harder for the users which justify inflicting pain upon the userbase, but in my experience the vast majority of change is a false sense that something must evolve or else it is dead. That sentiment should be punished.
So, in one die, it's a little interesting, though GPU stream processors and Intel's Phi would seem to suggest this is not that novel. The latter even let's you ssh in and see the core count for yourself in a very familiar way (though it's not exactly the easiest of devices to manage, it's still a very much real world example of how this isn't new to the world).
The 'not all cores are connected' is even older. In the commodity space, hypertransport and QPI can be used to construct topologies that are not full mesh. So not only is it not all cores on a bus, it is also not all cores mesh connected, the two attributes claimed as novel here.
Basically, as of AMD64 people had relatively affordable access to an implementation of the concept, and as of Nehalm both major x86 vendors had this concept in place. Each die included all the logic needed to implement a fabric, with the board providing essentially passive traces.
I assumed that was the sentiment of the engineers themselves.
I don't have a lot of contact with people in *this* field, but in other similarly niche fields with very concrete, yet limited demand (e.g. not aligned with the buzzwords deep in the muck where things *must* happen but 99.99% of the ecosystem take it for granted and doesn't want to actually touch it). In those fields, it was once upon a time not a 'given' and thus young blood was actively pushed in. Now it's a 'given' (despite requiring continuous evolution to keep things up), so the only people in the field are mostly retirement eligible people who have not retired. Overwhelmingly, the impression I get is that they are so *passionate* about the work that they can't bear to see it go untended.
Of course, some of those would declare that, but then even after a fluke young person interested in the work does come along, they still can't bring themselves to retire since the work is really simply enjoyable to them.
Personally, the moment I realistically could retire, I'm out. I love my work and all, but I love not working even more.
Perhaps, but from a 'we now support 40gb' statement, I don't see why that is accurate to distinguish 7.0 and 6.5 given that both included 40 gb drivers and all the reporting tools I knew already described 40 gb without issue...
For my personal workstation, I favor the Ubuntu cycle, though I know the cycle is too short for a lot of other scenarios. So RHEL more closely hits those sensibilities in schedule. Unfortunately I've become less and less enamored of the content of the ubuntu cycle as they seem to try to steer things toward things like Unity and Mir.
However, as you say, RHEL will go crazy back porting features to old codebases without an appropriate level of risk relayed. An update from 6.4 to 6.5 is a lot more drastic than a service pack for most competitors, and then RH will refuse to support 6.4 claiming that '6.5 is a safe update', even if some third party stack cannot work correctly with 6.5. I do believe RH has enough expertise to backport features better than anyone else, but it is a bad idea for *anyone* to do it. I wish Fedora and RH weren't so disparate and Fedora would behave more like a typical Ubuntu release in terms of how conservative it is and how change averse it should be post release.
This is precisely the point I keep in mind but always forget to explicitly say...
Where open source has great strength is where people have had to scratch their own itches. Now as more and more people's livelihoods become 'developer supporting *other* people's needs that I don't actually live with day to day', a lot of stuff is evolving in an unfortunate direction. Additionally, when someone *lives* inside a problem too much they lose touch with the relative importance and the degree to which others deal with it and understand a complex way to avoid a nuisance.
I don't know if they ever required WMI. I think wmi is still supposed to be right, but some calls just go direct. I rarely dabble in windows world, but it was things like enumerating network devices and disks. Once upon a time, if the wmi provider was messed up, my stuff did not work. Now the wmi calls can hang and stuff does work. I might have also changed calls, I'm a bit vague in my recollection. I tended to review the MS documentation and change things around when it looked like the documentation was preferring an alternative strategy. Mind you, when the wmi calls do work, they were as accurate, just in my scenario WMI could hang completely. I am in a position to see wmi hang more often than I think most others are (i.e. before a device is actually shipped).
Which is mostly the nature of my complaint, that it takes extra development time and extra layers to enable something like WMI above and beyond assuring the functionality of the device and, for lack of a better word, 'native' instrumentation. It adds complexity and particularly a CIM broker that I have seen never be very resilient no matter who did it, which makes me suspect a broker has a harder job than I would guess it should.
I will say I didn't mess with DSC, but a lot of the.NET calls no longer rely upon WMI working. WMI like sfcbd and Pegasus will completely cock up if a provider so much as looks at it funny. Previously, only utilities like ipconfig and stuff would keep working and any thing making WMI calls was just SOL. I noticed in one of the various scenarios where WMI had gone belly up that the calls I had moved to in.NET didn't mind at all for a lot of the stuff. Someone at MS suggested that WMI/CIM was being stepped around by design more and more over time, but it could be one portion of MS versus another.
It can actually sustain 40 gb of throughput. All the tools report link accurately as well. I confess to have no idea why RHEL would call out 40 gb as 'new' since it has been around already...
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.
RHEL is about as change averse as a *Linux* company gets. They have the unfortunate balance to play between fulfilling the mission of a solid predictable experience and not appearing to lag so much compared to the base people are well aware of. At times, I will say RHEL is in denial about ABI-breaking changes (e.g. swearing up and down that a kernel driver should compile and work against their rather dramatically backported base just as if it was really the kernel version advertised in uname output).
If you want 'stuff that never changes while still giving new hardware support', you are pretty much stuck with AIX or mainframe at this point.
Slashdot Mirror
If I can pay my bills or buy something with Bitcoin, it's the exception and not the rule
That's a low bar to set. If you can get a price or invoice in BTC that gives you a month to pay it off, then I'll start considering it a viable 'currency'. Accepting bitcoin with just-in-time pricing is very low risk and it's cheap for a company to do that for publicity with no downside. A company need not believe in bitcoin in all to do it. A company believes in bitcoin if it will commit to a long term price for anything it supplies or purchases.
by your argument, dell selling computers in france and generating euros would be a sham because they then call their bank to convert to USD (their reporting currency) at some point.
If 'at some point' is 'when tax laws and reporting make it most effective' it is a bit different than 'at some point' being seconds after the sale, with quotes longer than 15 minutes being considered invalid.
Notably dell will announce products with MSRP in dollars, euros, pounds, etc. They will not do the same in BTC, they will instead do a just-in-time quote that is invalid about as quickly as they can get away with. There is no even vague assumption about BTC value from one hour to the next, unlike the other currencies.
"Actual" currency is just the middleman to trading goods and services.
But people 'save' currency and plan retirements around quantities of it and such. Value fluctuations are real and troublesome of course, but in general this works. I give a company 30,000 dollars and they will keep it in an account for some non-trivial time and report their quarterly success in terms of those figures. They will at least talk about the value of currency in a manner that assumes pretty much absolute stability over 3 months and even project their expectations for how much money they will get and spend over the next several years.
All the companies worth their salt that elect to engage in bitcoin in a way to get publicity, but none want to plan for the value of the 'currency' for more than 15 minutes. You won't see dell doing a promotional price in terms of the bitcoin value, but rather you get the price converted to bitcoin as you pay for it with a quote that is invalid 20 minutes later.
Long story short, MS has proved they can buy a large market, but cannot figure out how to make a profit after achieving that end.
xbox 360 enjoyed a very brief couple of years of profitability that waned too quick to pay for the losses suffered in the years prior. xbox one tried to cash in on some of the carefully cultivated brand value only to see a fickle market jump sides and show their really wasn't much persistent brand loyalty (a lesson that also bit Sony in the ass in PS3). It's the only way I can figure MS would offer a lower spec system at significantly higher cost, a hail mary for margins to see if they could hit the ground profitable since so many people seemed to 'love' their xbox 360.
Also, xbox did nothing to build up the 'microsoft' brand, it basically built a new brand 'xbox'. Attempts to leverage that outside of gaming have fallen flat, so they don't get any residual benefit from the business unit whatsoever.
I'm guessing xbox one will be the last venture for MS-owned gaming. I suspect they will sell the brand since it has undeniable value, but MS cannot figure out how to profit from that and so it is time for them to give up.
It's also time to give up on surface RT (I frankly thought it was a misguided attempt in the first place) and on being a hardware company in general. All surface, surface pro, and nokia did was alienate current and potential partners. Looking at the market trends it is clear that 'trying to do it the apple way' is the wrong way. Apple is the only one to even remotely make it work, and they are losing ground to Android at large. This is actually very similar to how MS surpassed Apple, through a large ecosystem of vendors competing against each other by leveraging a common arms dealer. Problem for MS is that Google monetizes the platform in a different way so the classic 'pay for your software license' model that MS is used to doesn't fly.
Or it could be a deviation that had little to no practical downside in selection since the world rarely went that weird in the past. It would explain why motion sickness is so prevelant, yet not close to universal. There may just have been very little selective pressure either way.
I think on the poison theory, if your senses are impacted, the ship has sailed on ejecting the poison.
If it was a selected-for trait, my completely unsubstantiated guess would be something about falling out of or maneuvering within trees. After all, people who get motion sick can get sick in excessively peculiar real-world motion without messing with reference points (e.g. some people do it on roller coasters without looking at the car that much, or on boats without looking at the floor).
I have high hopes that the movement won't bother me, I've never had a hint of the issues many report, though I haven't tried VR, per se.
I will say even if there is a problem for people who can stand it when it's a conventional screen but lose it at the threshold of VR, there is yet hope for FPS genre without cockpits. Imagine playing your game and the monitor having the appearance of a movie theater screen. An experience that is totally impractical in reality, but not really much of a big deal in VR. There is a lot of interest in things like VR Cinema and virtual desktop (https://developer.oculusvr.com/forums/viewtopic.php?f=29&t=8182). In both cases, the medium is still fundamentally not motion sensing or surrounding in any way, but the concept of playing with screen size, curvature, and distance freely all while not imposing any particular posture is quite appealing.
The part that I'm wondering about is with these new, ultra efficient companies that merge up like crazy how much work is there going to be for the rest of us to do? Between that an automation it just looks like we're running out of work to do..
I think that's a bit of overestimation of these 'new, ultra efficient' companies. The volume of IT work has increased a lot over the past couple of decades, despite a seemingly more homogenous IT world with fewer 'newer, ultra efficient' companies (compared to the state of things in the early 90s).
In practice, the industry has just been shuffling I think. Some key specific cases see some gains or else loudly think they got gains, but there are losers too.
Some areas that were more automation friendly actually get less automated (some expensive automation features are falling out of favor in some datacenters in favor of low lost local labor). Many of these have sensibilities of 'buy a whole new server' rather than trying to fix something, meaning more volumes for their server vendors.
In the rise of 'cloud' we see a phenomenon where a lot of companies end up paying twice. They outsource their needs, but find out their IT staff actually is still needed (since the cloud providers actually don't help on as much as the stack as would be needed, and even when they do, they don't find a lot of takers). So they end up funding more headcount for their provider without getting to significantly reduce their own (which frequently means increased actual IT cost).
This is a bit on the pessimistic side of things, but these phenomenon add up to the chase for the 'magic bullet' continually driving change but not necessarily workforce reduction.
The closest thing to concrete data about that whole situation could accurately describe:
-Agency plugs in lenovo laptop with preload intact
-Agency notes that a TCP SYN packet was sent to China, but not allowed to actually get there.
-Agency says 'screw it' and bans it without further analysis
This could be nefarious or it could be checking for firmware or driver updates. There's no way to guess what really happened without details of any investigation coming to light.
Keep in mind that it was likely an activity driven by some agenda. Notably, these agencies start from a perspective of 'distrust china' and consider it their job to prevent that vendor selling into agencies. So they seek the flimsiest reason to hold up to impose a ban, which no one really objects too hard to since it's politically better to not source from China anyway. The agencies may not have detected a real threat, but they likely presume a real threat is a significant possibility that they have no way of practically detecting, so they run with this.
If there was an unambiguous backdoor seen, you bet your ass the agencies would be shouting from the rooftops. Instead, they are doing enough to keep it away from sensitive areas, but not so much to invite much scrutiny.
Finally, if China *really* wants backdoors, they don't need to actually have even slight ownership of the company. All the big companies gleefully hand over pretty much full control of their manufacturing and much of their hardware design, software, and firmware development to China anyway. The nationality of the CEO means approximately nothing in the scheme of state sponsored espionage.
Those early days are over and 3.x is intentionally designed to be more rational and consistent.
The issue being that is *always* the case. In the early python 2 days, they thought the 'early' days were over. I haven't dealt with python 3 with sufficient depth to be keenly aware of any real gotchas, but the fact they decided to add back in the explicit unicode syntax is a sign that they have at least continued to indulge in flux to fix bad design decisions. In that specific case, I don't see a downside for the increased ability to have python2/3 agnostic code so I won't declare any example of breaking 3.x series code with that. It seems clear to me that the python language can't quite exercise enough restraint in their enthusiasm for their vision of improved syntax and features to walk away confident that code won't break in a couple of 3.x generations.
It's almost like a curse, the more popular and energetic a language implementation is, the more likely it is to experience some incompatible evolution.
As the hip kids would say 'un-pythonic'. It's sort of like how perl can be perfectly readable until people go and start using all the language features in 'clever' ways. Making a dict on the fly and indexing it in the same statement is the sort of thing I could see rendering python code hard to read and follow...
Python is a language that has a fascinating tendency to break python on version upgrades. Yes, there is very clearly the python 2 to python 3, but even python 2.3 to python 2.6 can create worlds of headaches.
But then again no language is perfect. Old C code is frequently hard to build on modern compilers, perl had a very long history of not needing anything to be touched but some of the disilliusionment in prel 6 has caused even perl5 to get a bit fidgety as of late.
Why not hold people not claiming to be scientists to a higher standard? It's not like their science-but-don't-call-it-science experiments are any less potentially damaging than the same behavior done by a 'true scientist'.
I fail to see how it's that different than the manipulation that mass media does, who also do not get informed consent. There is the facet of it being more targeted, but the internet is already about targeted material (hopefully done with the best interest of the audience in mind, practically speaking with the best interests of the advertiser). They just stop short of calling it an 'experiment' (in practice, they are continually experimenting on their audience) and somehow by not trying to apply scientific rigor they get off the hook.
I'm not saying that Facebook is undeserving of outrage, I'm saying that a great deal of the media behavior is similarly deserving and somehow we are complacent with that situation.
My question is why is there particular outrage when they do it as part of a science experiment whereas it is widely acceptable to do the exact same thing in mass media to get revenue.
National and local news programs basically live and breath this sort of thing constantly. They schedule their reporting and editorialize in ways to boost viewership: stirring up anger, soothing with feelgood stories, teasing with ominous advertisements, all according to presumptions about the right way to maximize viewer attention and dedication. 'What everyday item in your house could be killing you right now, find out at 11'.
I don't have a Facebook account precisely because I don't like this sort of thing, but I think it's only fair to acknowledge this dubious manipulative behavior is ubiquitous in our media, not just as science experiments in Facebook.
If you deploy new software where it does not improve the user experience, then it's valid for the userbase to punish that move to a reasonable extent.
Not to the end result in this article of course, but sharing the pain inflicted by 'change for change's sake' with those who inflict it makes a lot of sense. Sometimes there are requirements to be fulfilled that do matter that make life harder for the users which justify inflicting pain upon the userbase, but in my experience the vast majority of change is a false sense that something must evolve or else it is dead. That sentiment should be punished.
So, in one die, it's a little interesting, though GPU stream processors and Intel's Phi would seem to suggest this is not that novel. The latter even let's you ssh in and see the core count for yourself in a very familiar way (though it's not exactly the easiest of devices to manage, it's still a very much real world example of how this isn't new to the world).
The 'not all cores are connected' is even older. In the commodity space, hypertransport and QPI can be used to construct topologies that are not full mesh. So not only is it not all cores on a bus, it is also not all cores mesh connected, the two attributes claimed as novel here.
Basically, as of AMD64 people had relatively affordable access to an implementation of the concept, and as of Nehalm both major x86 vendors had this concept in place. Each die included all the logic needed to implement a fabric, with the board providing essentially passive traces.
I assumed that was the sentiment of the engineers themselves.
I don't have a lot of contact with people in *this* field, but in other similarly niche fields with very concrete, yet limited demand (e.g. not aligned with the buzzwords deep in the muck where things *must* happen but 99.99% of the ecosystem take it for granted and doesn't want to actually touch it). In those fields, it was once upon a time not a 'given' and thus young blood was actively pushed in. Now it's a 'given' (despite requiring continuous evolution to keep things up), so the only people in the field are mostly retirement eligible people who have not retired. Overwhelmingly, the impression I get is that they are so *passionate* about the work that they can't bear to see it go untended.
Of course, some of those would declare that, but then even after a fluke young person interested in the work does come along, they still can't bring themselves to retire since the work is really simply enjoyable to them.
Personally, the moment I realistically could retire, I'm out. I love my work and all, but I love not working even more.
Perhaps, but from a 'we now support 40gb' statement, I don't see why that is accurate to distinguish 7.0 and 6.5 given that both included 40 gb drivers and all the reporting tools I knew already described 40 gb without issue...
For my personal workstation, I favor the Ubuntu cycle, though I know the cycle is too short for a lot of other scenarios. So RHEL more closely hits those sensibilities in schedule. Unfortunately I've become less and less enamored of the content of the ubuntu cycle as they seem to try to steer things toward things like Unity and Mir.
However, as you say, RHEL will go crazy back porting features to old codebases without an appropriate level of risk relayed. An update from 6.4 to 6.5 is a lot more drastic than a service pack for most competitors, and then RH will refuse to support 6.4 claiming that '6.5 is a safe update', even if some third party stack cannot work correctly with 6.5. I do believe RH has enough expertise to backport features better than anyone else, but it is a bad idea for *anyone* to do it. I wish Fedora and RH weren't so disparate and Fedora would behave more like a typical Ubuntu release in terms of how conservative it is and how change averse it should be post release.
This is precisely the point I keep in mind but always forget to explicitly say...
Where open source has great strength is where people have had to scratch their own itches. Now as more and more people's livelihoods become 'developer supporting *other* people's needs that I don't actually live with day to day', a lot of stuff is evolving in an unfortunate direction. Additionally, when someone *lives* inside a problem too much they lose touch with the relative importance and the degree to which others deal with it and understand a complex way to avoid a nuisance.
I don't know if they ever required WMI. I think wmi is still supposed to be right, but some calls just go direct. I rarely dabble in windows world, but it was things like enumerating network devices and disks. Once upon a time, if the wmi provider was messed up, my stuff did not work. Now the wmi calls can hang and stuff does work. I might have also changed calls, I'm a bit vague in my recollection. I tended to review the MS documentation and change things around when it looked like the documentation was preferring an alternative strategy. Mind you, when the wmi calls do work, they were as accurate, just in my scenario WMI could hang completely. I am in a position to see wmi hang more often than I think most others are (i.e. before a device is actually shipped).
Which is mostly the nature of my complaint, that it takes extra development time and extra layers to enable something like WMI above and beyond assuring the functionality of the device and, for lack of a better word, 'native' instrumentation. It adds complexity and particularly a CIM broker that I have seen never be very resilient no matter who did it, which makes me suspect a broker has a harder job than I would guess it should.
I will say I didn't mess with DSC, but a lot of the .NET calls no longer rely upon WMI working. WMI like sfcbd and Pegasus will completely cock up if a provider so much as looks at it funny. Previously, only utilities like ipconfig and stuff would keep working and any thing making WMI calls was just SOL. I noticed in one of the various scenarios where WMI had gone belly up that the calls I had moved to in .NET didn't mind at all for a lot of the stuff. Someone at MS suggested that WMI/CIM was being stepped around by design more and more over time, but it could be one portion of MS versus another.
It can actually sustain 40 gb of throughput. All the tools report link accurately as well. I confess to have no idea why RHEL would call out 40 gb as 'new' since it has been around already...
instead of developing an alternative to systemd
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.
RHEL is about as change averse as a *Linux* company gets. They have the unfortunate balance to play between fulfilling the mission of a solid predictable experience and not appearing to lag so much compared to the base people are well aware of. At times, I will say RHEL is in denial about ABI-breaking changes (e.g. swearing up and down that a kernel driver should compile and work against their rather dramatically backported base just as if it was really the kernel version advertised in uname output).
If you want 'stuff that never changes while still giving new hardware support', you are pretty much stuck with AIX or mainframe at this point.