xanjar reamonn gauntah
Tabita Knezevic
Over the past two years, work has changed dramatically. Most employees want flexible and remote options to stay. Cyberthreats are at an all-time high. And with the move to hybrid work, IT managers are challenged to empower their workforces with new tech experiences.
Our teams derive so much inspiration for Windows by hearing from our customers on how they use Windows to stay connected and productive. As people are working in more places, across devices, requiring even greater flexibility, we want to build experiences into Windows that are as inclusive, connected and intelligent as possible.
We will soon deliver new integrations that bring the power of Windows 11 and Windows 365 together. Integrations include Windows 365 Switch for seamless movement between your Cloud PC and Local PC with a single click, Windows 365 Boot to be able to boot straight to your Windows 365 Cloud PC in just one step, and we envision the ability to work offline and then automatically resync without losing any data with Windows 365 Offline. These scenarios are powerful for businesses, and they are just the beginning of our Windows and Microsoft cloud integration.
Windows 11 and Windows 365 are ready to take us all into the next era of hybrid work. Now is the time to move your business to Windows 11 and Windows 365. We are building Windows for the future, to support the future of your business, offering organizations the most secure, manageable and productive Windows experience on the planet.
I hope Google only changes minor things, so that we can still run the browser, with a little tweaks here and there. If I think back to 2016, there were no ports for higher Chrome versions for Windows Vista, since we needed a kernel extension before we could run the necessary functions.
I feel we have 2 main options. Either have a large protest directed at Google and Mozilla, or focus on improving the extended kernels so there is "day one" support for new versions when official support drops.
Chrome updates often enough for it to be an issue. Do you think Google will be ethical and disable updates on Win7 systems when this last version arrives or do you expect they will do what every other lazy developer does these days and push an unsupported update to a system thus making the software unusable? I'm not willing to bet that updates will be automatically disabled on the last version, or that they will show a prompt saying so, or block a future update to an OS-locked version.
As I previously said in another post, I think that Mozilla will be more graceful when it comes to ending them. They ended support for XP/Vista 10 months after Google did and then pushed out security updates for another year. If v115 will be the next ESR in July, we will continue to receive Security Updates for at least another year. ESR is usually also supported for more than just 12 months (v78 had 16 months). Applying the same stats to Windows 7 would mean that Firefox should at least be supported till July - October 2024, which is still 2 years ahead.
Hmm.. no surprise but moving Windows 7/8.1 to 102 ESR now is not a good idea in my opinion. They already run a newer version now and that would kinda be a downgrade now. Mozilla should definitly extend support till 114 ESR, so that Firefox remains supported till August-October 2024. It's highly unusual that they drop support on a regular release. It's either gonna be 102 ESR (which I highly doubt) or 114 ESR.
So sad that they don't let any door open for Windows 7 and 8.1 users. Mozilla already has a low market share and they will loose about 15% more, if they discontinue support for 7/8.1. They should re-consider and wait till there are less than 5% left. They always want to keep up with Google, but this time I don't think they should.
The problem with this code is that it use concurrent.futures to spawn many child process and, while on the mac it works fine (just tested on the other computer), the same code on windows gives me the following error.
fork creates the child process as a perfect copy of the parent process. All the code and data in both processes are the same. The only difference being the return value of the fork call. (That is to let the new process know it is a copy.)So the child process has access to (a copy of) all the data in the parent process.
On ms-windows, multiprocessing tries to "fake" fork by launching a new python interpreter and have it import your main module.This means (among other things) that your main module has to be importable without side effects such as starting another process. Hence the reason for if __name__ == '__main__'. It also means that your worker processes might or might not have access to data created in the parent process, depending on where it is created. It will have access to anything created before __main__. But it would not have access to anything created inside the main block.
What is the future of On-Prem Active Directory/ Active Directory Directory Services? Azure AD does not have the capabilities to do what AD/ADDS does and Azure AD does not work in environments where you cannot expose the systems to the internet. With Microsoft's push for hybrid everything. A large amount of important items are getting left behind.
My takeaway from this article is that on-premise AD isn't going anywhere (yet) even if they do have a shift in focus towards Azure AD as the supposed control plane (which I'm not on board with yet from technical parity and data governance perspectives).
I would imagine that there's numerous large organisations - both government and private - that have the same requirements as you (whatever they may be, as part of your "large amount of important items" statement).
I've done a quick bit of searching and can't find any articles that ring any bells, however, I vaguely recall that it spoke to the ongoing need for Active Directory for large enterprise customers who are expected to remain hybrid for the foreseeable future.
I'll keep looking for that "authoritative" post I claim to have found, but in the meanwhile, here's some (highly-opinionated, but experiential all the same) additional concerns I've got where the marketing rhetoric doesn't match the on-the-ground deliverables.
Point 2 reflects limitations of Azure AD itself when compared to on-prem Active Directory, however, Graph has more issues. The multi-valued attributes is a good example where, technically, Azure AD does indeed handle them properly but it let down by Graph, which doesn't surface them in the JSON response, leaving things like often-asked for features like using multi-valued attributes in dynamic licencing groups still out of reach.
This - for me - raises questions around the overarching Azure strategy which is further evident in the availability of no less than three Azure AD PowerShell modules. I feel like what we're getting as enterprise customers is a "make it up as you go" Agile-based approach to product development that's delivering a lot of new - and potentially nice - features, but poorly thought through and executed with a great many holes in the implementation.
Bringing the discussion back to Active Directory for a moment, I've listened to some people saying there's no further development planned and that's evidence of it's limited future. This to me only serves to demonstrate their lack of understanding of a directory service's obligation, which is firstly to act in accordance with the relevant standards, and from a practical perspective, deliver on its purpose which is to provide authorisation services. Additional roles and features were always a vendor add-on designed to benefit the customer, but you have to ask yourself, what more do I need from a directory service?
In that context, I don't really feel that further development of the service has really been all that important for at least the last decade. I think this is somewhat reflected in the schema changes from Server 2012 onwards where by and large, the only changes have largely been to facilitate cloud integration. To me, this is an acknowledgement that not much more could be added to the directory service itself.
Shifting contexts for a minute, on-premise Active Directory (or any other directory service, really) has tremendous value - when paired with a formal identity management strategy - in the context of handling on-boarding and offloading (think merger and divestment-like activities) where it's quite possible the external entity is not positioned well for integrating natively with Azure AD.
Lastly, but importantly, from a data governance perspective - particularly sovereignty as a subtopic; you're implicitly operating at a higher level of risk in storing your entire identity data set in Azure AD (or any cloud-based alternative) rather than just the operational metadata that if compromised might be embarrassing, but not in breach of legal frameworks such as your country's legislation (which we're seeing an increasing amount of here in Australia in the past five years).
This all reads like a lot of naysaying and that isn't deliberate for my part. I think Azure (and the other cloud platforms) is a wonderful tool that could use a good deal of love in playing catch-up to important feature parity with on-premise Active Directory as well as other on-premise products.
Where I diverge from the marketing fluff is that it is just that: a valuable tool in your arsenal that when adopted strategically can improve service delivery (including the over-touted, poorly understood "digital transformation"), not a panacea where wholesale adoption makes sense when considering your legal and commercial requirements. That I've seen a couple of clients back out from the cloud seems to lend some credibility to that observation (though I only have superficial awareness of the "whys" in those cases - I think OpEX cost was actually a prominent component).
I'd love to do more with Azure - particularly via Graph which enjoys good support from all the key identity management system vendors, but it's simply not mature enough to be all-encompassing when compared to the benefits from a hybrid approach.
c01484d022