• fred (edited 8 years ago)
    +3

    They say this, but its unproven, and the models they have built and their customers have adhered to will likely determine that course of action.

    Microsoft hardly tests and QA's their monthly updates. Service packs and the whatnot helped reduce this overhead for companies supporting the windows OS.

    Its likely fine for consumer use but in a business setting things change a bit. I hope they manage it great, but im not going to be on the bleeding edge given the shaky release history.

    Even with them ditching patch Tuesday as a method, companies will still run releases on a schedule with WSUS/SCCM/LanDesk etc for version and QC.

    Service packs in the past were tested and vetted much more than simple updates and in a lot of cases included essential updates that were already released. they may call them something different, but they have a lot of companies that use their OS, and they need to be able to continue to meet their needs.

    • spaceghoti
      +3

      You're definitely preaching to the choir, here. I don't trust anything Microsoft does out of the box. I'm not comfortable until they release a service pack with all of the updates necessary to create a stable system. My point is simply that Microsoft has said they're not doing service pack updates for 10, nor are they planning to release any new versions of Windows. They're simply going to push out periodic updates to patch and upgrade things they feel need fixing as they come along.

      How this works out for them remains to be seen. I don't have much faith in Microsoft architecture.

      • fred
        +3

        I think they are definitely in a bad spot overall. In their search for stability they have found trouble dealing with the bloat of their code.

        Products like Exchange are good examples of this. They have started releasing them every few years, but many companies rely on email so heavily, and Exchange patching being so finicky and break prone that many companies just got to 2010, skipping 2007 altogether (the last two I worked for included).

        And these, even on their "new" email system are already outdated by almost two versiosn. and due to their inability to support the code and bloat that comes from version to version a 2003 ->2013 upgrade isn't possible. So how do they fix that? How do they instill confidence in companies that you don't need an Exchange Certified Master to help with an version upgrade?

        The same can be said for server and workstation releases but on a issue of scale and version control. To this day we have 1 or 2 2012R2 servers but still rely on 2008R2 and 7 at our core. I still have some 2003 boxes im decomming and it has be a pretty big pain to get through some of these upgrades with vendors. I don't want the headache of support 7, 8, 8.1, 10, 2008, 2008 R2, 2012, 2012R2, and whatever 10's server version is.... That's like 8 different code bases and software compatibilities I have to support. So what do we do? We trim the fat, 7 and 2008R2 only. We have a few 8.1 (surface testing)/2012R2 (Few enhancements like DHCP replication) and may consider a move to 10 when the EOL 7/2008R2.