So you are saying everyone is entitled to cheap entertainment, cheap being whatever you dictate.
That's hubris getting in the way of sound business calls. "If they are only willing to pay 1 buck, they aren't *worthy* of getting it" is a philosophy that leads to poor business decisions.
Where do we stop playing this silly game of assuming twice as many people are always willing to pay half as much.
Given this is virtually unlimited supply, you can game the demand/pricing curve. You are right in that it isn't constant, but I think it's pretty clear that HBO stopped short of the point where twice would pay half. Once you get to that point in the curve, it is pointless to go further, but you should get there.
Of course, I've never seen game of thrones (precisely because I at least agree that infringement *shouldn't* be done even if you disagree wwith the terms), but from HBO's perspective, the fact that I abstain isn't any better than if I pirated instead, and from a practical perspective, trying to brute force away the piracy problem isn't going to be a profitable business move.
Though to be fair, generally the vendor will tie it to the dedicate port, and all other choices require explicit action. So if an admin is local, has no desire for remote management, ignoring the whole thing and leaving the dedicated ports unplugged *generally* suffices.
On shared chassis servers (blades, etc...) you may have common I2C sensor busses, and IPMB.
Absolutely, remember to ask your vendor *specifically* about this. Various solutions have varying degrees of resilience. Some even treat that topology as *trusted* and made certain design choices based on that.
Surprisingly, IBM BladeCenter is a tad frightening. While the management bus is pretty much isolated from the running OS requiring some hypothetical service processor exploit to get at, the 'CIN' is extended to server processors via VLAN tagging on shared nics. To its credit, they have taken some significant measures to prevent the NICs from behaving in certain ways that seemingly prevent it, but it all seems more complicated than I would like.
Despite BladeCenter frightening me, IBM Flex actually is perhaps the most strongly isolated chassis design. Servers in an enclosure have no i2c or similar connection between them, it's a point to point between the management module and each service processor. The ethernet topology is hard-isolated from the OS. Even if you found a service processor exploit in theory, that service processor has a distinct authentication scheme from everyone else, meaning they can't take the exploit further into other parts of the chassis.
It's a very robust and reliable technology. Just because supermicro pushes half-baked tools doesn't mean the technology is flawed. People go with supermicro because they are cheaper than the IBM, Dell, and HP implementations, but you get what you pay for.
IPMI is good when used correctly. A quality vendor (e.g. IBM) will select the appropriate security measures for default (*except* still allowing a default password, which really must be changed), but get a random white box, make sure that *this* won't work: ipmitool -I lanplus -U correctusername -P someincorrectpassword -H youripmidevicehere power off 90% of the time it will. Cipher suite zero is the most idiotic thing in the IPMI spec, it by design allows you to access a system without knowing a password at all. To Mitigate, ipmitool lan print 1. You'll see what cipher suites are supported and how they are restricted. Usually the supported ones will start out like '0,1,2,3'. In that case, you ipmitool lan set 1 cipher_privs Xaaa' Note the '1' may be different and the '0' in the protocol sequence isn't guaranteed, so adjust accordingly. Also use matching letters if the other cipher suites are not 'a'. xCAT on service processor setup disables cipher suite 0 automatically.
IPMI is actually capable of some very good behaviors if configured correctly. -In the standard cipher suites, passwords are *never* sent over the wire (encrypted or in the clear) as of 2.0 (in 1.5 this was *usually* the case in sane implementations, but there was a mode for password on the wire). The password is actually a shared secret between client and service processor. In a good client, the service processor cannot be impersonated, as it *must* know the password to respond to the client correctly. ipmitool can be deceived but xCAT cannot. -Additionally, payload can be AES encrypted as of 2.0 (and usually is, 'cipher suite 3' is the most common incarnation since it has been available since 2.0 of the spec). -It is pretty much the *only* very specific spec for systems management. If the payload is the sequence of bytes '0,2,0' that means 'turn the server off' no matter who the vendor is. Other specifications tend to fall short of this, in the name of giving the vendors the 'freedom' to do as they wish.
That out of the way, article gets a few things wrong:
eliminate IPMI access over insecure protocols like HTTP. Use HTTPS with proper certificates, or SSH
IPMI cannot be done with HTTP(s) or SSH. IPMI *specifically* has its own UDP protocol in its remote incarnation. Most remote management solutions implementing *also* have a web and cli, but that's not covered in IPMI.
review the BIOS configuration option for IPMI. If you can't have a physical management network, at least try to use a VLAN if supported.
While this is possible in many current shared nic solutions, it generally suffers from two problems: -In some shared NIC implementations, the OS driver for nic is more likely to mess up the remote access unless it behaves *just* right. This reduces the point of IPMI, to service a system when things have gone horribly wrong. Some older shared nic implementations made it risky even without the complication of tagging, but that's largely no longer an issue. -It likely doesn't provide significant additional protection over an aliased private IP subnet. The theoretical additional benefit with VLAN being you are protecting service processor access if one server is compromised in-band. The problem is, you can generally coax the shared nic to let the OS onto any tagged vlan (just ask the local BMC what the compromised server's current vlan tag for IPMI traffic is, vconfig add eth0 , and usually you get right on that 'secure' vlan).
try to integrate IPMI authentication with existing authentication systems. Options typically include RADIUS and AD.
Actually, since the *standard* security mechanisms are all shared secret base, this isn't possible. There are some proprietary IPMI cipher suites that have the client transferring a password, but since normally that doesn't happen, you have no user password to check against the authentication server.
The video they showed was a web interface, *not* IPMI. I know companies like SuperMicro have really made this confusion, but I already mentioned that.
Salt means rainbow tables become impractical. Salt also means a collision attack is also mitigated. Salt is not expected to be any more secret than hash, it just changes tho way it works.
b) differs from a) in common practice in that you must find data+determined salt=hash. If your collision doesn't end in the salt, it's useless in that application.
Regardless of initial intent (I seem to vaguely remember the same message being relayed by people *swearing* azure was going to render other platforms irrelevant), they probably see EC2 continuing on without popularity abating. MS realized they aren't fundamentally changing the game so they want to try to beat EC2 at their own game. Probably a whole lot of practical realization that while in theory a platform that magically has 'no OS' is actually going to be harder to debug/service than they expected....
Whole system needn't be installed, you can fit a special-purpose KVM hypervisor in less than 16 megabytes or so. One kernel and a few megabytes of cpio.gz and you have what you want...
Ok, let's take it further. You bundle a 'pirated' grub and kernel. You furnish an initrd that sets up a full screen KVM hypervisor to boot the windows environment.
Of course, I wonder if this simply inconveniences legitimate use without additional security.
For example, if RedHat has a multi-boot capable grub signed, could malware just bundle RedHat's signed grub to load rootikit before chaining windows execution. 'SecureBoot' is still set, but rootkit comfortably in place.
self-register their own trusted keys on their own systems at no cost.
How? Most reasonable mechanisms that could be envisioned would likely be considered an 'attack vector' in certain scenarios. I'm genuinely curious as to the mechanisms allowed for end-user key management in this sort of system.
The 'interviewer' being overwhelmed that the scenes aren't pre-rendered seems pretty forced. Considering that pretty much every new title looks about that good/bad, disbelief around a scene being realtime seems silly. I do think it is part of a good trend of moving away from the pre-rendered scenes. So long as all graphics are done realtime, you can easily forget just how lacking the graphics are. In a modern title with cutscenes, they just serve to remind you that the lighting isn't quite right, reflections are bad, and textures just look not-quite-right. Stranger still are the obviously 'pre-rendered' cutscenes, but seemingly done in the game engine (e.g. the lighting and other stuff is still obviously off, but with the added mismatch of resolution and in some cases even encoding artifacts).
In terms of gameplay, who knows how it will be. I will say one of my first thoughts is the last scene looked like you were handed control, and within 5 seconds a cinematic sequence happens taking the control away for the scripted scene to play out. I hope that's the exception not the rule. Just because a cinematic, scripted scene isn't a 'prerendered' cutscene, doesn't mean it is any less intrusive on the gaming. At least with the cutscene scenario, you knew you weren't controlling it, nowadays it isn't uncommon that you will still be trying to control your character a few seconds before you realize control has been disabled.
You lost me... I would hope/presume that Yammer doesn't carry over the imposed message length limitations (which has fascinating effects, but productivity wise it's pretty bad by itself and the stuff *worth* archiving would have to be hosted by... something else. I think a message board system would be more appropriate here. Of course, there is the challenge of managing the very complex access rights inherent in a lot of business communications if you want to adopt a 'twitter' or message board like system. Following that is how to gracefully integrate any internal system with partner companies.... Essentially, business confidentiality concerns severely restrict the scalability of better-than-email systems. Not talking about *hard* security concerns (email is usually not that, though public key integration is often a feature inherent), but avoiding content getting out idly to peers that may induce confusion or incite people one way or another unnecessarily.
In our team, we've tried sticking to the rule that forbids the use of email for anything that will still be relevant one week from the day of sending
Problem being there that sometimes you don't know whether that will be the case until a week from the day of sending.
The idea is that any such messages belong to the corporate memory,
I agree, but *often* the message devoid of the context provided by a human can lose a lot of its value. It's infeasible to assure that everything in the employee's head lands in the corporate memory independent of the employee (including everything to ad-hoc hallway conversations to background thougths formulated in the bathroom, human nature just is more complex in practice).
Thanks for that. I do wish the window previews were a bit more usably large (as it stands, the thumbnail is just too small to make out wtf it is).
The alt-tab behavior you describe is vanilla, but when you have dozens of terminals and you *know* a substring in a title, a search is more effective than traversing. If referring to it being a substitute for 'show all windows for an app', the problem being the UI in compize/kde uses maybe 90% of screen real estate to facilitate decipherable previews, where alt-above-tab uses maybe 15% of the screen real estate and the rest is pretty much unused.
I think Microsoft will actually GAIN market share with the new Window Server 2012
Why? I can see it keeping some 2k8r2 shops from jumping ship because 2012 does a few things like ReFS mitigating the advantages of ZFS and (future) btrfs, but I don't see anything to induce non-Windows shops to jump aboard all of a sudden. 2k8r2 already has virtualization, so maybe 2012 gets some capability to be more competitive, but those vmware shops that are willing to jump ship have largely already done so (to KVM either in Free or RedHat backed configurations mostly). The overwhelmingly large base that sticks with VMWare that is still out there isn't looking to jump platforms unless VMWare royally screws up.
In terms of form factor, most any 'real work' is unsuitable for a tablet or phone device. Among the people who do indeed use it for 'real' work, probably more than half do it out of blind zealous devotion to the device rather than of practical considerations. If you have to do any significant amount of text/data entry, you are doing yourself a disservice by using touchscreen-only devices. Also, fitting your work into sub-10-inch display territory when it is perfectly reasonable to let it be more than twice that.
'The cloud' as MS imagines and Windows 8 facilitates is, however, MS' wet dream.... if they can win. Suddenly, not only does MS have a monopoly on your application platform, they get a monopoly on the data you manage with it. Suddenly they not only have more stuff to mine for revenue, but in addition to worrying about if you can find a calendar app in a competing OS that can manage your schedule, now your schedule itself is stuck in MS servers.
I doubt it will flame out though. I think it should fail in many respects and particularly in digital media context royally screws up the concept of 'ownership', but it's still clearly happening....
Anyway, Windows 8 will do just fine, especially because Microsoft is falling all over itself trying to be tablet-friendly and all of the other bollocks that'll generally make it a pain in the ass.
After trying the Win8 customer preview, I think it *won't* do 'just fine', precisely because they are *trying* to be tablet-friendly with a horridly awkward UI concept for desktop. Hell, I don't see how pure touch even works particularly well with Metro.
I guess the question being, what scenario is more productive? If you have small window count of about one window per app, then you probably wouldn't have even *noticed* the difference. If you have a large window count, then how does alt-tab, alt-above-tabe impede productivity? Other arguments I can buy (e.g. encouraging many across-the-screen moves, hiding dock making it more difficult to be 'discoverable', and many other criticisms of gnome 3), but other than 'it's different', I see no technical advantage to alt-tab versus what they provided.
I currently have a modest number of windows open (11). To get to a particular window as a test, it took me 4 keypresses. For me to have gotten to it without hierarchical task switching, it would have taken me 8 keypresses given the current layout. Also, by masking the windows of other apps, more screen real estate is available to preview the windows I want.
Mind you, this is still all significantly worse than a hypothetical scenario with window title search or 'show only windows of a certain app' in 'activities view', where you can both be more precise in query and have more real estate to show the results.
But once you get used to it, it is a much more scalable mechanism to deal with many windows. Plenty of stuff in Gnome3 frustrates me, but this one I think they got right.
Re:another example of having lost the plot
on
Fedora 17 Released
·
· Score: 4, Insightful
You do realize that the Fedora leadership expressly does *not* want to be part of corporate applications right? From a business perspective, the goal is to have a research and development strategy that takes advantage of enthusiasts willingness to have a less stable environment to test and develop features and concepts that ultimately land in 'Red Hat Enterprise Linux', the most popular 'enterprisy' instance of Linux there is?
Slashdot Mirror
So you are saying everyone is entitled to cheap entertainment, cheap being whatever you dictate.
That's hubris getting in the way of sound business calls. "If they are only willing to pay 1 buck, they aren't *worthy* of getting it" is a philosophy that leads to poor business decisions.
Where do we stop playing this silly game of assuming twice as many people are always willing to pay half as much.
Given this is virtually unlimited supply, you can game the demand/pricing curve. You are right in that it isn't constant, but I think it's pretty clear that HBO stopped short of the point where twice would pay half. Once you get to that point in the curve, it is pointless to go further, but you should get there.
Of course, I've never seen game of thrones (precisely because I at least agree that infringement *shouldn't* be done even if you disagree wwith the terms), but from HBO's perspective, the fact that I abstain isn't any better than if I pirated instead, and from a practical perspective, trying to brute force away the piracy problem isn't going to be a profitable business move.
Though to be fair, generally the vendor will tie it to the dedicate port, and all other choices require explicit action. So if an admin is local, has no desire for remote management, ignoring the whole thing and leaving the dedicated ports unplugged *generally* suffices.
You must also disable cipher suite 0. Since it by design makes the password moot and all...
On shared chassis servers (blades, etc...) you may have common I2C sensor busses, and IPMB.
Absolutely, remember to ask your vendor *specifically* about this. Various solutions have varying degrees of resilience. Some even treat that topology as *trusted* and made certain design choices based on that.
Surprisingly, IBM BladeCenter is a tad frightening. While the management bus is pretty much isolated from the running OS requiring some hypothetical service processor exploit to get at, the 'CIN' is extended to server processors via VLAN tagging on shared nics. To its credit, they have taken some significant measures to prevent the NICs from behaving in certain ways that seemingly prevent it, but it all seems more complicated than I would like.
Despite BladeCenter frightening me, IBM Flex actually is perhaps the most strongly isolated chassis design. Servers in an enclosure have no i2c or similar connection between them, it's a point to point between the management module and each service processor. The ethernet topology is hard-isolated from the OS. Even if you found a service processor exploit in theory, that service processor has a distinct authentication scheme from everyone else, meaning they can't take the exploit further into other parts of the chassis.
However, IME it's a half-baked technology
It's a very robust and reliable technology. Just because supermicro pushes half-baked tools doesn't mean the technology is flawed. People go with supermicro because they are cheaper than the IBM, Dell, and HP implementations, but you get what you pay for.
IPMI is good when used correctly. A quality vendor (e.g. IBM) will select the appropriate security measures for default (*except* still allowing a default password, which really must be changed), but get a random white box, make sure that *this* won't work:
ipmitool -I lanplus -U correctusername -P someincorrectpassword -H youripmidevicehere power off
90% of the time it will. Cipher suite zero is the most idiotic thing in the IPMI spec, it by design allows you to access a system without knowing a password at all.
To Mitigate, ipmitool lan print 1. You'll see what cipher suites are supported and how they are restricted. Usually the supported ones will start out like '0,1,2,3'. In that case, you ipmitool lan set 1 cipher_privs Xaaa' Note the '1' may be different and the '0' in the protocol sequence isn't guaranteed, so adjust accordingly. Also use matching letters if the other cipher suites are not 'a'. xCAT on service processor setup disables cipher suite 0 automatically.
IPMI is actually capable of some very good behaviors if configured correctly.
-In the standard cipher suites, passwords are *never* sent over the wire (encrypted or in the clear) as of 2.0 (in 1.5 this was *usually* the case in sane implementations, but there was a mode for password on the wire). The password is actually a shared secret between client and service processor. In a good client, the service processor cannot be impersonated, as it *must* know the password to respond to the client correctly. ipmitool can be deceived but xCAT cannot.
-Additionally, payload can be AES encrypted as of 2.0 (and usually is, 'cipher suite 3' is the most common incarnation since it has been available since 2.0 of the spec).
-It is pretty much the *only* very specific spec for systems management. If the payload is the sequence of bytes '0,2,0' that means 'turn the server off' no matter who the vendor is. Other specifications tend to fall short of this, in the name of giving the vendors the 'freedom' to do as they wish.
That out of the way, article gets a few things wrong:
eliminate IPMI access over insecure protocols like HTTP. Use HTTPS with proper certificates, or SSH
IPMI cannot be done with HTTP(s) or SSH. IPMI *specifically* has its own UDP protocol in its remote incarnation. Most remote management solutions implementing *also* have a web and cli, but that's not covered in IPMI.
review the BIOS configuration option for IPMI. If you can't have a physical management network, at least try to use a VLAN if supported.
While this is possible in many current shared nic solutions, it generally suffers from two problems:
-In some shared NIC implementations, the OS driver for nic is more likely to mess up the remote access unless it behaves *just* right. This reduces the point of IPMI, to service a system when things have gone horribly wrong. Some older shared nic implementations made it risky even without the complication of tagging, but that's largely no longer an issue.
-It likely doesn't provide significant additional protection over an aliased private IP subnet. The theoretical additional benefit with VLAN being you are protecting service processor access if one server is compromised in-band. The problem is, you can generally coax the shared nic to let the OS onto any tagged vlan (just ask the local BMC what the compromised server's current vlan tag for IPMI traffic is, vconfig add eth0 , and usually you get right on that 'secure' vlan).
try to integrate IPMI authentication with existing authentication systems. Options typically include RADIUS and AD.
Actually, since the *standard* security mechanisms are all shared secret base, this isn't possible. There are some proprietary IPMI cipher suites that have the client transferring a password, but since normally that doesn't happen, you have no user password to check against the authentication server.
The video they showed was a web interface, *not* IPMI. I know companies like SuperMicro have really made this confusion, but I already mentioned that.
Salt means rainbow tables become impractical. Salt also means a collision attack is also mitigated. Salt is not expected to be any more secret than hash, it just changes tho way it works.
b) differs from a) in common practice in that you must find data+determined salt=hash. If your collision doesn't end in the salt, it's useless in that application.
Regardless of initial intent (I seem to vaguely remember the same message being relayed by people *swearing* azure was going to render other platforms irrelevant), they probably see EC2 continuing on without popularity abating. MS realized they aren't fundamentally changing the game so they want to try to beat EC2 at their own game. Probably a whole lot of practical realization that while in theory a platform that magically has 'no OS' is actually going to be harder to debug/service than they expected....
Whole system needn't be installed, you can fit a special-purpose KVM hypervisor in less than 16 megabytes or so. One kernel and a few megabytes of cpio.gz and you have what you want...
Ok, let's take it further. You bundle a 'pirated' grub and kernel. You furnish an initrd that sets up a full screen KVM hypervisor to boot the windows environment.
Now what?
Of course, I wonder if this simply inconveniences legitimate use without additional security.
For example, if RedHat has a multi-boot capable grub signed, could malware just bundle RedHat's signed grub to load rootikit before chaining windows execution. 'SecureBoot' is still set, but rootkit comfortably in place.
self-register their own trusted keys on their own systems at no cost.
How? Most reasonable mechanisms that could be envisioned would likely be considered an 'attack vector' in certain scenarios. I'm genuinely curious as to the mechanisms allowed for end-user key management in this sort of system.
The 'interviewer' being overwhelmed that the scenes aren't pre-rendered seems pretty forced. Considering that pretty much every new title looks about that good/bad, disbelief around a scene being realtime seems silly. I do think it is part of a good trend of moving away from the pre-rendered scenes. So long as all graphics are done realtime, you can easily forget just how lacking the graphics are. In a modern title with cutscenes, they just serve to remind you that the lighting isn't quite right, reflections are bad, and textures just look not-quite-right. Stranger still are the obviously 'pre-rendered' cutscenes, but seemingly done in the game engine (e.g. the lighting and other stuff is still obviously off, but with the added mismatch of resolution and in some cases even encoding artifacts).
In terms of gameplay, who knows how it will be. I will say one of my first thoughts is the last scene looked like you were handed control, and within 5 seconds a cinematic sequence happens taking the control away for the scripted scene to play out. I hope that's the exception not the rule. Just because a cinematic, scripted scene isn't a 'prerendered' cutscene, doesn't mean it is any less intrusive on the gaming. At least with the cutscene scenario, you knew you weren't controlling it, nowadays it isn't uncommon that you will still be trying to control your character a few seconds before you realize control has been disabled.
- Email sucks as an archive.
I'm with you
A Twitter-like chat system for corporations
You lost me... I would hope/presume that Yammer doesn't carry over the imposed message length limitations (which has fascinating effects, but productivity wise it's pretty bad by itself and the stuff *worth* archiving would have to be hosted by... something else. I think a message board system would be more appropriate here. Of course, there is the challenge of managing the very complex access rights inherent in a lot of business communications if you want to adopt a 'twitter' or message board like system. Following that is how to gracefully integrate any internal system with partner companies.... Essentially, business confidentiality concerns severely restrict the scalability of better-than-email systems. Not talking about *hard* security concerns (email is usually not that, though public key integration is often a feature inherent), but avoiding content getting out idly to peers that may induce confusion or incite people one way or another unnecessarily.
In our team, we've tried sticking to the rule that forbids the use of email for anything that will still be relevant one week from the day of sending
Problem being there that sometimes you don't know whether that will be the case until a week from the day of sending.
The idea is that any such messages belong to the corporate memory,
I agree, but *often* the message devoid of the context provided by a human can lose a lot of its value. It's infeasible to assure that everything in the employee's head lands in the corporate memory independent of the employee (including everything to ad-hoc hallway conversations to background thougths formulated in the bathroom, human nature just is more complex in practice).
Thanks for that. I do wish the window previews were a bit more usably large (as it stands, the thumbnail is just too small to make out wtf it is).
The alt-tab behavior you describe is vanilla, but when you have dozens of terminals and you *know* a substring in a title, a search is more effective than traversing. If referring to it being a substitute for 'show all windows for an app', the problem being the UI in compize/kde uses maybe 90% of screen real estate to facilitate decipherable previews, where alt-above-tab uses maybe 15% of the screen real estate and the rest is pretty much unused.
I think Microsoft will actually GAIN market share with the new Window Server 2012
Why? I can see it keeping some 2k8r2 shops from jumping ship because 2012 does a few things like ReFS mitigating the advantages of ZFS and (future) btrfs, but I don't see anything to induce non-Windows shops to jump aboard all of a sudden. 2k8r2 already has virtualization, so maybe 2012 gets some capability to be more competitive, but those vmware shops that are willing to jump ship have largely already done so (to KVM either in Free or RedHat backed configurations mostly). The overwhelmingly large base that sticks with VMWare that is still out there isn't looking to jump platforms unless VMWare royally screws up.
In terms of form factor, most any 'real work' is unsuitable for a tablet or phone device. Among the people who do indeed use it for 'real' work, probably more than half do it out of blind zealous devotion to the device rather than of practical considerations. If you have to do any significant amount of text/data entry, you are doing yourself a disservice by using touchscreen-only devices. Also, fitting your work into sub-10-inch display territory when it is perfectly reasonable to let it be more than twice that.
'The cloud' as MS imagines and Windows 8 facilitates is, however, MS' wet dream.... if they can win. Suddenly, not only does MS have a monopoly on your application platform, they get a monopoly on the data you manage with it. Suddenly they not only have more stuff to mine for revenue, but in addition to worrying about if you can find a calendar app in a competing OS that can manage your schedule, now your schedule itself is stuck in MS servers.
I doubt it will flame out though. I think it should fail in many respects and particularly in digital media context royally screws up the concept of 'ownership', but it's still clearly happening....
Anyway, Windows 8 will do just fine, especially because Microsoft is falling all over itself trying to be tablet-friendly and all of the other bollocks that'll generally make it a pain in the ass.
After trying the Win8 customer preview, I think it *won't* do 'just fine', precisely because they are *trying* to be tablet-friendly with a horridly awkward UI concept for desktop. Hell, I don't see how pure touch even works particularly well with Metro.
I guess the question being, what scenario is more productive? If you have small window count of about one window per app, then you probably wouldn't have even *noticed* the difference. If you have a large window count, then how does alt-tab, alt-above-tabe impede productivity? Other arguments I can buy (e.g. encouraging many across-the-screen moves, hiding dock making it more difficult to be 'discoverable', and many other criticisms of gnome 3), but other than 'it's different', I see no technical advantage to alt-tab versus what they provided.
I currently have a modest number of windows open (11). To get to a particular window as a test, it took me 4 keypresses. For me to have gotten to it without hierarchical task switching, it would have taken me 8 keypresses given the current layout. Also, by masking the windows of other apps, more screen real estate is available to preview the windows I want.
Mind you, this is still all significantly worse than a hypothetical scenario with window title search or 'show only windows of a certain app' in 'activities view', where you can both be more precise in query and have more real estate to show the results.
That wouldn't be 'fixed', that would be regressing for the sake of people who hate change just because it is change.
If you are terribly bothered by it:
https://extensions.gnome.org/extension/15/alternatetab/
But once you get used to it, it is a much more scalable mechanism to deal with many windows. Plenty of stuff in Gnome3 frustrates me, but this one I think they got right.
You do realize that the Fedora leadership expressly does *not* want to be part of corporate applications right? From a business perspective, the goal is to have a research and development strategy that takes advantage of enthusiasts willingness to have a less stable environment to test and develop features and concepts that ultimately land in 'Red Hat Enterprise Linux', the most popular 'enterprisy' instance of Linux there is?
I actually grew to like the alt-tab part pretty quickly.
I still miss 'window title search' and 'show all windows for an app' that I had in compiz.....
Also, only allowing configuration through themes and extensions is frustrating...
You may wish to try Cinnamon from Mint, last time I tried it was a tad incomplete though.
Can't stand unity either...... Gnome 3 is the less of the two evils.
There is also always KDE and xfce...
I find it amusing that as a result of this name, I think this kicked off:
https://fedoraproject.org/wiki/Future_Release_Naming
After several tries at getting 'Beefy Miracle' in, and the leadership seemingly forced to accept it. Hence a new naming process.