1) That particular software is not so good. That's like saying PS4 technology is crap because someone made this: https://www.youtube.com/watch?... 2) Trying to judge a VR experience through a youtube video will be ineffective.
My concern is that it becomes chicken and egg. The technology could crtainly be a tad better, but it's pretty damn effective. The problem right now is that there is a crucial lack of *quality* games. There have been a fair number of games, and some of them have been pretty techonologically and artisitically impressive, but generally they are no more than 'arcarde' deep, with emphasis on short playtimes and/or wonder of an environment but lack of story or gameplay to actually drive things beyond looking nice.
If game studios 'wait and see' so will the market, and it becomes a stale mate.
Sure, resolution doesn't go as far as it does on a monitor, so in some respects resolution steps back a decade or so.
Also, currently at least the rift lenses are pretty bad for rays of light that really detract.
However, the amazing sensation of being utterly surrounded by the environment, rather than looking at a relatively tiny window into the environment, it's incredible. It doesn't in any way feel somehow more eerie than the stuff on a monitor, the way a almost-real-but-not-quite 3d render is.
I also would say the full motion that VR fanatics *demand* is doing more harm than good to the health of the genre. Sure, a game like robo recall is a fantastic experience, but saying that you have to have 1:1 motion mapping from real world to virtual or else don't bother at all.
The big challenge for VR is that games on average or pretty 'meh', VR or not. VR has started to accumulate expereinces which is nice, but like the general industry, a good game is a rarity. Elite Dangerous is a fantastic VR space sim, but not so much a good *game* as of yet. Lucky's Tale is cute, but it's a generic platformer when all is said and done. Even one of the 'deeper' experiences like Edge of Nowhere is decently executed, but exceedingly short in terms of how that genre *usually* goes,
His smartcad+pin probably would have been faster if he had the card on him, here it replaced the second factor with his phone, which presumably wouldn't happen the smartcard+pin way.
Or that's the least bad sounding explanation he could pull from his ass in the heat of the moment. It doesn't make much sense.
The two more likely explanations: -They have a bug in the javascript under edge they hadn't ironed out -There was a bug in their javascript with respect to some dom storage or cookie that the edge browser had picked up along the way that could have also broken chrome, but chrome had a clean slate and had not accumulated crap. Particularly if their framework reacts to cookies, being under 'microsoft.com' probably meant all kinds of completely irrelevant cookies not pertaining to app had accumulated in the browser and were being flung at their server.
I'm not the parent poster, but at a company that has dealt with Apple.
At least in a business relationship, they are quite abusive to their vendors. Of course, every company is as abusive to their vendors as they can afford to be, and Apple's position is such they can be really abusive.
Beyond that, they would also put out crazy requirements that would cause expensive work to meet, and then select a vendor that didn't meet any of those requirements because ultimately the only metric that matters is cost. This wouldn't be so bad if they did not insist up front that these things were a hard requirement and not doing them would mean disqualification. The only time my business 'won', it meant bidding under cost, foolishly thinking that would kickstart the relationship, but no. We are also in the list of companies that go for the greener pastures in the market and happily ignore apple, as there is plenty of money to be made elsewhere.
The thing is I wonder how their long term quality will be, if this is their attitude. As they ignore their requirements for cost savings, and more and more companies learn that bidding under cost isn't going to work, what happens to Apple?
I guess I've been blessed in that I've never worked in a team that wasn't naturally continuously building and testing their changes. I couldn't imagine being more than a few minutes of being able to see the result of my work. So for me, CI comes into novel play only when merge requests happen that start exposing subtle conflicts between privately worked branches of work.
I suppose I could imagine someone spending a long time without even building and testing, but on the other hand I can't imagine that willingness translating to a good developer even if that particular bad habit is automated away.
The curse of all of this is that good teams have always naturally done things that lead to good product, and then some folks comes along to try to 'distill' out the magic of those successes into useless aphorisms and make a consultancy industry out of it. Complicated by ditching the unprofitable pieces (for example the agile manifesto among other things stressed communication rather than processes and tools, but an Agile consultant will ditch that and focus on tools and processes because they can make money off of tools and processes are what sells to the management).
So 'continuous blah' and 'devops' and 'agile' are all afflicted by the curse of being the consultancy of the month and as such are applied to bad teams and leave bad tastes in the mouths of folks. Also, the business is held up by taking the no true scotsman both ways. A project that did the Agile or DevOps or CI/CD thing and failed, well they didn't do it right, so it wasn't "truly" whatever it was. By the same token, a project succeeds, it is deemed to have done it right, even as it makes no sense in the context of the purported philosophy..
I think it's the efffects of the bubble. The late 90s did have whiffs of this too, though that bubble burst earlier in the cycle and communication wasn't as rapid as it is today, so it's a bit more severe. Developers in general had a wake up call after the bubble burst last time and things settled back down for a while there into more manageable offerings.
The real root cause is not the fads and rhetoric, those are a combination of band aids and denial about the reality that the market is flooded with students that became programmers because of big dollarsigns in their eyes and not so much passion for the industry, and companies have a very hard time recognizing the value of the more intrinsically dedicated and focus more on X developers should be able to do this, and if not there must be a magic process to fix that'
I think the complaint is developer written tests of their own code is frequently considered a replacement for an actual QA team, whether unit or integration test.
One of the *massive* gaps is if the developer is batshit crazy and designs horribly because they are not the target audience and do not understand the target audience, the tests are going to sail on through and be horrible because no 'mere mortal' could check that developers bizarre vision. Also a developer can be plain dumb and think the wrong thing and make tests that only will pass when a broken implementation is thrown at them.
The biggest problem is the buzz of CI/CD brands developers in general as infallible. CI at least is a good idea in and of itself to augment a process, but the collateral damage of how those words are interpreted by management is severe.
In general, the reality is that the biggest losers are the ones *obsessed* with appearing to conform to .
Recently the great corporate overlords came to make my team "go Agile" to improve our productivity. Of course we already were 'Agile', but the company brought in 'certified Agile' consultants to retrain project managers, and frankly for somewhat plausible cause since there are some really crappy teams that no one wants to admit just aren't qualified and would rather a process magically fix those teams.Prior to the mess my team had continuous integration with unit tests prior to our QA team, our QA team had access to builds as changes were made, the average time from a bug opened to a test build available for QA team (after CI and all) was about 2.5 hours. Our release cycle dictated shippable increments and punting functions not ready.
What did the 'Agile' project management team and consultants do? Throttled us to weekly builds (wtf??), demanded 100% commitment on functionality 1 year in advance, and started saying functions *must* go in and we need to slip dates if we didn't get a feature completed in the timeframe we thought (despite no external stakeholder expecting the features), and imposed that no customer request could be satisfied sooner than about 9 months from asking, even if minor. They started 'helping' by preventing developers from talking to customers and talking to them instead. The end result is a bizarre situation where the QA team has asked dev team for a secret build server to provide fixes like we used to without telling management, and customers no longer going through official channels because they no longer reach developers, but sending personal emails to the dev email addresses they remember, begging for help and betas. That latter thing of course produced an introducing graph, a spike in customer support traffic and then a decline as informal channels triumphed over official, so their take away is 'greater customer sat' (despite declining sales because 'market pressures')
But hey, now we are more 'Agile' because we use trendy words like 'user stories', 'scrum', and 'sprints'. Long story short, crappy teams and crappy project management will be crappy, but they dream of easy fix through dumping money on consultants without fixing the fundamental problems.
Of course with CI, you can still have this phenomon. This is about midnset and developer strategy, You can still have developers sitting on their private branches and at the last minute end of conflicting with each other. Of course a sane process says they get to sit that week out, but in all likelihodd, one of those has some change that simply "can't wait" even a week, so the whole train gets held up despite the sane thing of punting that developer work for a week,,
CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks.
Also, while CI isn't in and of itself a bad thing, it does encourage a lot of organizations to skimp on vluable QA, made overconfident by misleading phrases like '100% test coverage' and deciding that means they automated the need for QA.
Also, by the same mistaken thought, they don't need maintenance branches anymore because the first release was necessarily bug free because those unit tests passed, so no need to think about whether a change makes sense to work into an older functional branch.
Of course the change now is that the standard was to have PTF type updates that would fix problems without changing functionality.
Now developers aren't forced to do that because they are too cool for that, and roll out fixes alongside functional changes that also aren't baked yet and bring new problems, so you don't get to stop and say "hey, you *almost* got it right here, I'll just take fixes from this version, thanks"
In this era of using software remotely, you can't even choose to ignore updates and stick with an abandoned version, it's just gone.
Of course there are enterprise vendors still doing this, but developers will bitch about being asked to support that 'ancient' platform that first released 3 years ago and screw it up by ignoring all the content and replacing with the random untested assortment of latest crap from gems/pypi/npm/whatever wtogether with a random build of the language runtime that partially screws up the system paths.
It's just not 'cool' to have maintenance branches, so.. here we are.
Well, it *can* be ok, for 'most users' is the hypothetical case among the general computing population.
Of course, the Linux desktop is more enthusiast centered, and I think we have to recognize that reality and accept it, instead of continuing to sacrifice enthusiast friendly flexibility and power for the sake of the mythical casual linux desktop user that is using a traditional linux distro rather than android or chromeos...
KDE has been a bit disappointing, because I like their design sensibilities, but they tend to have more random glitches in various components. Specifically KWin is a fantastic window manager/compositor and I have little reason to complain there.
Meanwhile Gnome has tendend to be less glitchy, but I hate their design, and they lack flexibility. They settle for being marginally better than Microsoft Windows.
Meanwhile most other desktops fail to take advantage of compositing for producting fetures. Sure a lot of the compositing effects is shiny fluff, but it does provide useful views of data (which is one thing I like about KWin).
So Ubuntu Phone was an unmitigated commercial flop (as was Ubuntu on the TV). Ubuntu as a supported desktop OS is just not a prospect anyone is about to pay for.
So they can trumpet their share of cloud instances. That's a nice looking metric for them sure enough, but the whole reason is because they are the no-fuss no-cost option. It has not translated to people paying Canonical for much as of yet. They have been trying to drive this up from the instances to the infrastructure where there *could* be some consulting money to be had, but that has not been a huge commercial success as of yet.
Similarly, they can court IoT, but again we are talking about companies that shave every last fraction of a cent possible from their cost, volumes are extremely high and any cost is not tolerated. Popularity comes by being the no cost option. You may say 'quality', but that random ass yocto build you cobbled together seems good enough, fits in your memory footprint, and without paying anyone to do it for you. Sure your home grown is crap and will probably bite you in the ass down the road, but every penny counts and your device is probably going to just be rebadged as needed by other companies, so you don't even have much of a reputation to protect, statistically speaking of IoT device makers.
Despite some respectable technical effort and good judgement about what is and is not appropriate in a release cycle, as a business endeavor I think they are deeply challenged to find an 'in'.
I imagine that if I sat at a starbucks and made an AP called 'StarbucksWifi' or whatever, people would join and be totally oblivious to the network not being the same.
If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.
Of course, I bothered to look at at least one version of the PCI DSS spec:
This means all CDE data must be encrypted as suggested in PCI DSS Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer. Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end cryptographic protection of card-holder data.
So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...
Slashdot Mirror
1) That particular software is not so good. That's like saying PS4 technology is crap because someone made this: https://www.youtube.com/watch?...
2) Trying to judge a VR experience through a youtube video will be ineffective.
My concern is that it becomes chicken and egg. The technology could crtainly be a tad better, but it's pretty damn effective. The problem right now is that there is a crucial lack of *quality* games. There have been a fair number of games, and some of them have been pretty techonologically and artisitically impressive, but generally they are no more than 'arcarde' deep, with emphasis on short playtimes and/or wonder of an environment but lack of story or gameplay to actually drive things beyond looking nice.
If game studios 'wait and see' so will the market, and it becomes a stale mate.
Ehh.. Not for me..
Sure, resolution doesn't go as far as it does on a monitor, so in some respects resolution steps back a decade or so.
Also, currently at least the rift lenses are pretty bad for rays of light that really detract.
However, the amazing sensation of being utterly surrounded by the environment, rather than looking at a relatively tiny window into the environment, it's incredible. It doesn't in any way feel somehow more eerie than the stuff on a monitor, the way a almost-real-but-not-quite 3d render is.
I also would say the full motion that VR fanatics *demand* is doing more harm than good to the health of the genre. Sure, a game like robo recall is a fantastic experience, but saying that you have to have 1:1 motion mapping from real world to virtual or else don't bother at all.
The big challenge for VR is that games on average or pretty 'meh', VR or not. VR has started to accumulate expereinces which is nice, but like the general industry, a good game is a rarity. Elite Dangerous is a fantastic VR space sim, but not so much a good *game* as of yet. Lucky's Tale is cute, but it's a generic platformer when all is said and done. Even one of the 'deeper' experiences like Edge of Nowhere is decently executed, but exceedingly short in terms of how that genre *usually* goes,
His smartcad+pin probably would have been faster if he had the card on him, here it replaced the second factor with his phone, which presumably wouldn't happen the smartcard+pin way.
Additionally, in the infamous BSOD demo, they didn't whip out a Mac to finish the demo.
Or that's the least bad sounding explanation he could pull from his ass in the heat of the moment. It doesn't make much sense.
The two more likely explanations:
-They have a bug in the javascript under edge they hadn't ironed out
-There was a bug in their javascript with respect to some dom storage or cookie that the edge browser had picked up along the way that could have also broken chrome, but chrome had a clean slate and had not accumulated crap. Particularly if their framework reacts to cookies, being under 'microsoft.com' probably meant all kinds of completely irrelevant cookies not pertaining to app had accumulated in the browser and were being flung at their server.
It was a made up hand waving that is less embarrassing then the more likely explanation of them having a bug in javascript under edge.
I couldn't possibly relate to paying for uber expensive fighter jets that I couldn't budget repairs for..
Thanks for the far more relatable scenario of buying exotic cars I can't budget repairs for...
I'm not the parent poster, but at a company that has dealt with Apple.
At least in a business relationship, they are quite abusive to their vendors. Of course, every company is as abusive to their vendors as they can afford to be, and Apple's position is such they can be really abusive.
Beyond that, they would also put out crazy requirements that would cause expensive work to meet, and then select a vendor that didn't meet any of those requirements because ultimately the only metric that matters is cost. This wouldn't be so bad if they did not insist up front that these things were a hard requirement and not doing them would mean disqualification. The only time my business 'won', it meant bidding under cost, foolishly thinking that would kickstart the relationship, but no. We are also in the list of companies that go for the greener pastures in the market and happily ignore apple, as there is plenty of money to be made elsewhere.
The thing is I wonder how their long term quality will be, if this is their attitude. As they ignore their requirements for cost savings, and more and more companies learn that bidding under cost isn't going to work, what happens to Apple?
I guess I've been blessed in that I've never worked in a team that wasn't naturally continuously building and testing their changes. I couldn't imagine being more than a few minutes of being able to see the result of my work. So for me, CI comes into novel play only when merge requests happen that start exposing subtle conflicts between privately worked branches of work.
I suppose I could imagine someone spending a long time without even building and testing, but on the other hand I can't imagine that willingness translating to a good developer even if that particular bad habit is automated away.
The curse of all of this is that good teams have always naturally done things that lead to good product, and then some folks comes along to try to 'distill' out the magic of those successes into useless aphorisms and make a consultancy industry out of it. Complicated by ditching the unprofitable pieces (for example the agile manifesto among other things stressed communication rather than processes and tools, but an Agile consultant will ditch that and focus on tools and processes because they can make money off of tools and processes are what sells to the management).
So 'continuous blah' and 'devops' and 'agile' are all afflicted by the curse of being the consultancy of the month and as such are applied to bad teams and leave bad tastes in the mouths of folks. Also, the business is held up by taking the no true scotsman both ways. A project that did the Agile or DevOps or CI/CD thing and failed, well they didn't do it right, so it wasn't "truly" whatever it was. By the same token, a project succeeds, it is deemed to have done it right, even as it makes no sense in the context of the purported philosophy..
I think it's the efffects of the bubble. The late 90s did have whiffs of this too, though that bubble burst earlier in the cycle and communication wasn't as rapid as it is today, so it's a bit more severe. Developers in general had a wake up call after the bubble burst last time and things settled back down for a while there into more manageable offerings.
The real root cause is not the fads and rhetoric, those are a combination of band aids and denial about the reality that the market is flooded with students that became programmers because of big dollarsigns in their eyes and not so much passion for the industry, and companies have a very hard time recognizing the value of the more intrinsically dedicated and focus more on X developers should be able to do this, and if not there must be a magic process to fix that'
I want and use my VR. I'm very sad if it fails to take off more than it has.
Voice recognition on the other hand.. Meh
I think the complaint is developer written tests of their own code is frequently considered a replacement for an actual QA team, whether unit or integration test.
One of the *massive* gaps is if the developer is batshit crazy and designs horribly because they are not the target audience and do not understand the target audience, the tests are going to sail on through and be horrible because no 'mere mortal' could check that developers bizarre vision. Also a developer can be plain dumb and think the wrong thing and make tests that only will pass when a broken implementation is thrown at them.
The biggest problem is the buzz of CI/CD brands developers in general as infallible. CI at least is a good idea in and of itself to augment a process, but the collateral damage of how those words are interpreted by management is severe.
In general, the reality is that the biggest losers are the ones *obsessed* with appearing to conform to .
Recently the great corporate overlords came to make my team "go Agile" to improve our productivity. Of course we already were 'Agile', but the company brought in 'certified Agile' consultants to retrain project managers, and frankly for somewhat plausible cause since there are some really crappy teams that no one wants to admit just aren't qualified and would rather a process magically fix those teams.Prior to the mess my team had continuous integration with unit tests prior to our QA team, our QA team had access to builds as changes were made, the average time from a bug opened to a test build available for QA team (after CI and all) was about 2.5 hours. Our release cycle dictated shippable increments and punting functions not ready.
What did the 'Agile' project management team and consultants do? Throttled us to weekly builds (wtf??), demanded 100% commitment on functionality 1 year in advance, and started saying functions *must* go in and we need to slip dates if we didn't get a feature completed in the timeframe we thought (despite no external stakeholder expecting the features), and imposed that no customer request could be satisfied sooner than about 9 months from asking, even if minor. They started 'helping' by preventing developers from talking to customers and talking to them instead. The end result is a bizarre situation where the QA team has asked dev team for a secret build server to provide fixes like we used to without telling management, and customers no longer going through official channels because they no longer reach developers, but sending personal emails to the dev email addresses they remember, begging for help and betas. That latter thing of course produced an introducing graph, a spike in customer support traffic and then a decline as informal channels triumphed over official, so their take away is 'greater customer sat' (despite declining sales because 'market pressures')
But hey, now we are more 'Agile' because we use trendy words like 'user stories', 'scrum', and 'sprints'. Long story short, crappy teams and crappy project management will be crappy, but they dream of easy fix through dumping money on consultants without fixing the fundamental problems.
Of course with CI, you can still have this phenomon. This is about midnset and developer strategy, You can still have developers sitting on their private branches and at the last minute end of conflicting with each other. Of course a sane process says they get to sit that week out, but in all likelihodd, one of those has some change that simply "can't wait" even a week, so the whole train gets held up despite the sane thing of punting that developer work for a week,,
CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks.
Also, while CI isn't in and of itself a bad thing, it does encourage a lot of organizations to skimp on vluable QA, made overconfident by misleading phrases like '100% test coverage' and deciding that means they automated the need for QA.
Also, by the same mistaken thought, they don't need maintenance branches anymore because the first release was necessarily bug free because those unit tests passed, so no need to think about whether a change makes sense to work into an older functional branch.
Of course the change now is that the standard was to have PTF type updates that would fix problems without changing functionality.
Now developers aren't forced to do that because they are too cool for that, and roll out fixes alongside functional changes that also aren't baked yet and bring new problems, so you don't get to stop and say "hey, you *almost* got it right here, I'll just take fixes from this version, thanks"
In this era of using software remotely, you can't even choose to ignore updates and stick with an abandoned version, it's just gone.
Of course there are enterprise vendors still doing this, but developers will bitch about being asked to support that 'ancient' platform that first released 3 years ago and screw it up by ignoring all the content and replacing with the random untested assortment of latest crap from gems/pypi/npm/whatever wtogether with a random build of the language runtime that partially screws up the system paths.
It's just not 'cool' to have maintenance branches, so.. here we are.
Well, it *can* be ok, for 'most users' is the hypothetical case among the general computing population.
Of course, the Linux desktop is more enthusiast centered, and I think we have to recognize that reality and accept it, instead of continuing to sacrifice enthusiast friendly flexibility and power for the sake of the mythical casual linux desktop user that is using a traditional linux distro rather than android or chromeos...
KDE has been a bit disappointing, because I like their design sensibilities, but they tend to have more random glitches in various components. Specifically KWin is a fantastic window manager/compositor and I have little reason to complain there.
Meanwhile Gnome has tendend to be less glitchy, but I hate their design, and they lack flexibility. They settle for being marginally better than Microsoft Windows.
Meanwhile most other desktops fail to take advantage of compositing for producting fetures. Sure a lot of the compositing effects is shiny fluff, but it does provide useful views of data (which is one thing I like about KWin).
So Ubuntu Phone was an unmitigated commercial flop (as was Ubuntu on the TV). Ubuntu as a supported desktop OS is just not a prospect anyone is about to pay for.
So they can trumpet their share of cloud instances. That's a nice looking metric for them sure enough, but the whole reason is because they are the no-fuss no-cost option. It has not translated to people paying Canonical for much as of yet. They have been trying to drive this up from the instances to the infrastructure where there *could* be some consulting money to be had, but that has not been a huge commercial success as of yet.
Similarly, they can court IoT, but again we are talking about companies that shave every last fraction of a cent possible from their cost, volumes are extremely high and any cost is not tolerated. Popularity comes by being the no cost option. You may say 'quality', but that random ass yocto build you cobbled together seems good enough, fits in your memory footprint, and without paying anyone to do it for you. Sure your home grown is crap and will probably bite you in the ass down the road, but every penny counts and your device is probably going to just be rebadged as needed by other companies, so you don't even have much of a reputation to protect, statistically speaking of IoT device makers.
Despite some respectable technical effort and good judgement about what is and is not appropriate in a release cycle, as a business endeavor I think they are deeply challenged to find an 'in'.
I only ever bother to remember the version number, since that's nice and easy .(04 or 10 for april and october respectively).
They can enjoy their cutesy codename, but much easier for me to remember the numbers since they are date based.
I imagine that if I sat at a starbucks and made an AP called 'StarbucksWifi' or whatever, people would join and be totally oblivious to the network not being the same.
If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.
Of course, I bothered to look at at least one version of the PCI DSS spec:
This means all CDE data must be encrypted as suggested in PCI DSS
Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as
AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer.
Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end
cryptographic protection of card-holder data.
So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...