Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Microsoft Windows Hardware

Microsoft Works On Windows For ARM-Based Servers 113

SmartAboutThings writes According to some reports from the industry, Microsoft is working on a version of its software for servers that run on chips based on ARM Holdings's technology. Windows Server now runs on Intel hardware, but it seems that Redmond wants to diversify its strategy. An ARM-based version of Windows Server could help challenge Intel's dominance and make a place for ARM in the server market, not only in mobile chips. According to the article, though, Microsoft "hasn’t yet decided whether to make the software commercially available."
This discussion has been archived. No new comments can be posted.

Microsoft Works On Windows For ARM-Based Servers

Comments Filter:
  • by Anonymous Coward on Tuesday October 28, 2014 @10:15AM (#48250525)

    Why would you want Microsoft Works on you server ARM or no?

    • by Jhon ( 241832 )

      So you can print to your kodak diconix battery operated ink-jet printer, of course!

    • by tepples ( 727027 )
      So that you can upload a Works document and get an ODF document back to use in modern software, of course.
    • Exactly I would go for the full version of Office.
      For the server, I would really would like Microsoft provide a better library for interacting with office files then interop

      • Though judging by how Microsoft handled it's last shot at arm, it may shoot itself in the foot instead...again.

        I think Windows on Arm could have worked well, but Microsoft made the incredibly stupid decision to only allow it to run under the RT platform, and worse is that it was forced under a walled garden.

        • Re:Microsoft Works? (Score:5, Interesting)

          by cbhacking ( 979169 ) <been_out_cruising-slashdot@@@yahoo...com> on Tuesday October 28, 2014 @02:29PM (#48253441) Homepage Journal

          The only really stupid aspect of the Windows-on-Arm (AKA Windows RT) product line was the intentionally crippling it to only be able to run stuff signed by MS. Take out that restriction, and it's actually pretty decent: full web browser (to which Firefox and Chrome and all could have been ported, although - speaking as somebody who tried porting Chrome - that doesn't mean it would be easy), full file management, built-in "root" (just a standard UAC prompt), multi-user support, scripting capability (all the standard Windows languages), built-in Office and Remote Desktop software, ability to use Windows networking (SMB), updates from MS rather than from some OEM that may or may not bother to push important patches or so on, and a bunch of other nice stuff. Combine that with the inability to join domains (a purely artificial restriction, as they didn't even take out the domain-client code; hack the registry a bit and it will happily join domains) and you had something that nobody really wanted

          As soon as it was jailbroken, a bunch of useful stuff - ranging from 7-Zip to DOSBox to Python - was ported over. Additionally, anything that was pure .NET, or .NET with P/Invoke of functions from built-in OS libraries, ran without so much as a recompile. The problem was the need to jailbreak (and then the absurd level of effort that MS went to with 8.1 to break the jailbreak). That meant that commercial developers never ported their stuff to RT (all the community-ported apps are open source), and there was no software ecosystem outside of the joke of the Windows Store. One guy, in his spare time, wrote a surprisingly decent x86 emulation layer that could run a reasonable amount of old Wintel software as-is; pay him to do it as his full-time job and it could have run anything that wasn't simply too performance-intensive for the dynamic recompilation on low-powered CPUs.

          So, with that said, an "RT Server" could be pretty useful... if MS didn't go all brain-dead on third party software again. Not a lot of point running a web server that can't run PHP or Java or even ASP.NET to host web applications, these days. File serving is fine as long as you stick to SMB, assuming it can also join a domain and do all the standard Win Server stuff with volume management, I guess.

          • (to which Firefox and Chrome and all could have been ported, although - speaking as somebody who tried porting Chrome - that doesn't mean it would be easy)

            Unless it uses assembly, it should pretty much just be a recompile. How dependent is Chrome on x86/x64?

          • to which Firefox and Chrome and all could have been ported

            With the annoying stipulation that they aren't allowed to be set as the default browser. In Windows RT, IE is hard coded as the default, just like Safari in iOS.

            In fact if you look at the whole RT setup from a distance, it's pretty blatant that Microsoft wanted to just flat out copy Apple's mobile model. Problem is they apparently missed the memo that Google had already outdid Apple in that arena, and did so without using a walled garden, making it appeal to both power users and casual users, becoming a vas

            • by tepples ( 727027 )

              it's pretty blatant that Microsoft wanted to just flat out copy Apple's mobile model. Problem is they apparently missed the memo that Google had already outdid Apple in that arena, and did so without using a walled garden

              And Android gets the reputation among news outlets for being the most malware-filled mobile operating system precisely because it doesn't use a walled garden.

  • Link = Download? (Score:4, Insightful)

    by Dan Askme ( 2895283 ) on Tuesday October 28, 2014 @10:16AM (#48250531) Homepage

    Nice checking on the editing there /.

  • this is because Windows RT did so well! Hey, mr CEO, you clearly need to lay off more people.
    • The main reason RT Failed is because MS Would not let you develop Desktop apps for it. All you could do was port metro apps and businesses stayed away from it cause you couldn't add it to a domain. It also was more expensive than Android tablets so it was already priced out of the market.

      They could have also saved it by making it a Chromebook competitor. FWIW if someone made a laptop with RT running on a good ARM Processor, and sold it for under $200 it would fly off shelves. It's basically got everything m

      • by Bert64 ( 520050 )

        It would sell because its marketed as windows, and then customers would be disappointed because it didnt do the same things their desktop windows does. After a short while, it would earn itself a terrible reputation and people would avoid it, and the existing unwanted devices would show up on ebay very cheaply.

        On it's own merit, windows rt offers nothing over android or ios, and at $200 the hardware would at best be the same spec as $200 android hardware if windows were given away for free. On the other han

        • It would sell because its marketed as windows, and then customers would be disappointed because it didnt do the same things their desktop windows does. After a short while, it would earn itself a terrible reputation and people would avoid it, and the existing unwanted devices would show up on ebay very cheaply.

          On it's own merit, windows rt offers nothing over android or ios, and at $200 the hardware would at best be the same spec as $200 android hardware if windows were given away for free. On the other hand, its unlikely to be free, so the hardware would be inferior to cover the cost and then you also have a much smaller pool of apps than android/ios devices have.

          TFA is about Servers, not Desktops. Windows Servers tend to run specialized software already - Exchange, MS SqlServer, Oracle Database, etc. Yeah, there'd likely be some complaints regarding stupid admins; but the Server world is looking at using ARM-based systems especially in datacenters b/c they are cheaper to run and easier to scale out due to lower heat generation (which Intel has always been bad about).

          This is just MS saying "we don't want to be left out" since Linux is currently able to take on al

        • RT actually offers a lot over iOS and Android, especially over the versions available at the time it was released.

          Full web browser, with dev tools and fine-grained settings and all. Oh and Flash (love it or hate it, Flash is a factor on the web even today, never mind back then).
          Built-in "root" (just a UAC prompt) and full file browser with support for Windows file sharing.
          Word, Excel, Powerpoint, OneNote, and Outlook (on 8.1) all built in, plus built-in Remote Desktop client.
          Real, normal-OS-style multitaski

    • Actually it is because RT did so well. I can envision management types trying to find ways to get some ROI on their investment in ARM after the Windows RT flop. In traditional fashion of chasing bad investments with more bad investments, out comes Server "RT".
    • this is because Windows RT did so well! Hey, mr CEO, you clearly need to lay off more people.

      Not just that, Windows NT before it - on the MIPS and the Alpha - was such a rip-roaring success. Seriously, if someone buys an ARM server, why would they buy Windows on it? It won't run any of the Wintel software that's out there - be it old or new. Actually, in the 90s, Microsoft could have gotten ahead by developing a 64-bit Windows - today's Windows 7/8.x on one of these, and promoted it in the workstation & server markets. They'd have been 64-bit even before AMD or Intel was.

      • I have to say though, they stand a much better chance today at doing this thanks to the .Net framework. Software written on top of that framework should work regardless of the CPU type. Same for anything written for the JVM.

        Moreover, unlike desktops, servers don't have to support an open ended list of apps. So, if by going to ARM they save on energy cost and cost of hardware, it's a win. So, maybe it's a smart move after all. Mr CEO, keep those ARM developers :)

        So the loser in this is of course intel an

  • by SmartAboutThings ( 1951032 ) on Tuesday October 28, 2014 @10:35AM (#48250713) Homepage
    it seems that moderator timothy likes to modify my submission links all the time. sigh...
    • Which wouldn't be nearly as much of a problem if the change was actually to a functional link.

      Maybe it's not the link. Maybe timothy's just broken.

  • by Anonymous Coward

    That will not fly.

  • Irrelevant (Score:4, Informative)

    by ArhcAngel ( 247594 ) on Tuesday October 28, 2014 @10:39AM (#48250755)
    The majority of shops these days run a hypervisor [wikipedia.org] on the bare metal and load Windows as a virtual machine. Now if Microsoft is working on an ARM version of Hyper-V that's a different story. But even the hard core Microsoft shops I work with use VMWare as their hypervisor of choice.
    • Re:Irrelevant (Score:4, Insightful)

      by ledow ( 319597 ) on Tuesday October 28, 2014 @10:50AM (#48250863) Homepage

      The problem would be that the virtualisation of ARM on Intel or vice versa would suffer quite large performance problems. You're basically into emulation, rather than virtualisation.

      So even if they could do that, you wouldn't see much point in doing it over just running your Intel stuff on Intel hypervisors and your ARM stuff on ARM hypervisors. What you'd gain would be, well, almost nothing.

      At least it's a showing, though, that the Microsoft code is in a big better shape that they can port things across. That is, of course, assuming it ever comes to fruition. Microsoft has had a lot of non-Intel architectures over the years and they've always played second-fiddle and then been obsoleted.

      Quite what they expect to get from aiming at ARM, I can't see. You won't get Intel compatibility, so you're effectively running another OS that - actually - only specialist places that are running huge compute farms etc. are using, or smaller gadgets where you'll struggle to sell a non-compatible Windows (like Windows CE was).

      • I think the benifit of using ARM would be energy effeciency not computing power.
        • by Junta ( 36770 ) on Tuesday October 28, 2014 @11:42AM (#48251315)

          ARM won over in the mobile device space because of solid engineering around a low power envelope, without trying to compete with x86 performance in any way. Basically Intel made a mistake by not having *any* appropriate chips for that space at all. Performance per watt was never demonstrated to be better if you followed the curve up to desktop/server class energy consumption. Intel has actually competently answered in their Atom space, and has secured some mindshare among Android vendors (which I never would have guessed could be possible). Intel is second comer to the party and thus the ecosystem is clearly stacked against them, but they still managed to get their components in the market.

          Some vendors are starting to tout ARM based competitors to Xeon. The problem being their energy consumption numbers at this point are actually higher and achieve lower performance numbers in compute and have worse I/O capability.

          • It looks like there are enough big names wanting to escape the grasp of Intel's grip to tip the scales but only time will tell. I found a painfully in depth article [enterprisetech.com] discussing the reasoning and driving forces.
          • by steveha ( 103154 )

            My understanding is that ARM-based microservers are attractive for low-compute workloads. For example, a half-rack with 1600 microservers in it would do a great job of coping with the Slashdot effect (it could spin up a whole bunch of web servers).

            You are right that if you are scaling out major number crunching jobs, fast Xeon boxes will work out to be more efficient. But those Xeon boxes would be wasted just serving up web pages.

            HP has released figures claiming that 1,600 of its Project Moonshot Calxeda

          • Intel is second comer to the party and thus the ecosystem is clearly stacked against them, but they still managed to get their components in the market.

            It is amazing what you can acheive if you are prepared to lose (sorry, I mean "Contra Revenue") $1B/quarter by massively subsidsing development and silicon costs.

      • by ADRA ( 37398 )

        Windows has been mostly architecturally portable since NT was released. The fact that they're debating supporting ARM's for their server cores is more interesting because it means their main consumer Windows OS could also run on ARM tablets / netbooks now, which I think has more viability for them. Having their managed code stack and applications that can be binary portable between underlying OS architectures would be the BIG win Microsoft should've done originally when they released their tablet-lite versi

        • by Hadlock ( 143607 )

          Win8 and WS2012 run on the same kernel, the only difference is Win8/8.1 has the "desktop" role enabled rather than the server roles. It's not uncommon to see people hack in server roles to their desktop machine as an exercise

        • The stupid thing is, Windows RT *already* demonstrates that "their main consumer Windows OS could also run on ARM tablets / netbooks"... but they had to go and cripple it into near-uselessness. Recompiling most software for ARM instead of x86 is pretty trivial; it's a drop-down in Visual Studio and then you hit Build again. Stuff like web browsers (which have JavaScript JITs and are therefore inherently platform-dependent) have already been ported to ARM on non-Win32 platforms. Stuff that only compiles on V

      • Intel already emulates the x86 ISA. How much worse could emulating the ARM ISA be?

    • by Bert64 ( 520050 )

      There are hypervisors for ARM, but most current ARM based servers seem to be geared up towards having lots of small machines rather than a single big machine split into lots of virtual images...
      It's really PCs vs Mainframes all over again.

  • Is the ARM version of Windows Server going to be arbitrarily limited to Microsoft Store apps with the exception of a handful of Microsoft applications and services, too?

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Tuesday October 28, 2014 @10:47AM (#48250835)
    Comment removed based on user account deletion
    • The history NT is really a fear of what happened to the crappy DOS based operating systems such as Windows.

      NT from day 1 was purposedly not made x86 as the main cpu as people used assembler more in those days and MS management knew it would loose its portability and later security by having x86 hacks and direct memory calls in the kernel etc.

      So NT 3.1 was made for the MIPS first on SGI then backported to x86. This continued to PowerPC in 1990s with NT 3.51 and NT 4 and later Alpha with Windows 2000. Itanium

      • Actually, NT 3.1 was developed on MIPS based DECstations 3000, and on i860s. After the x86, it was ported to the Alpha. PowerPC came much later. In terms of dropping support, MIPS died first, then PPC and then Alpha.

        Given that failure, MS should avoid doing it for ARM. If they need a non-Intel CPU, they should port RT to the MIPS CPU, since that's still an active CPU, even if SGI is dead as far as RISC boxes go.

  • Here [zdnet.com].

    Well, at least a non-malformed link.

  • by __aaclcg7560 ( 824291 ) on Tuesday October 28, 2014 @10:51AM (#48250873)
    Might as well bring out Windows Server for the DEC Alpha [wikipedia.org].
    • My first webserver gig was the EMWAC [windowsitpro.com] Server on a DEC Alpha/NT 3.x rig (I forgot if it was 3.1 or 3.51 by the time we had the webserver). I can say I had a paying "webmaster" (is that still even a word?) gig in 1993, 1994 or so.

      On another note, the link above was not too much later than the time we installed it (1993). I guess things some things just don't change. I like the recommendations to go all the way to a 486 and 16MB of memory, and how to set up PPP (for a web server?) Well, some things do.

    • Better example - the MIPS. The DEC Alpha is dead - no longer being manufactured, but the MIPS is.
  • Microsoft "hasn't yet decided whether to make the software commercially available."

    Microsoft, get back to me when you decide to make it commercially available and I'll decide whether I want it.

    Chances are I won't.
  • by pak9rabid ( 1011935 ) on Tuesday October 28, 2014 @11:03AM (#48250965)
    MS couldn't produce a mobile device that anybody wanted (where ARM makes much more sense). What makes them think they're going to have any success on the server front?
    • A Windows server is likely to run the services that come with the OS. It's not so much like desktop-style use, where people want to run a game from 2008, genealogy software from 1997, and the software that came with the printer and camera on disc. Windows on ARM was toast for that market as well as failing to replicate the tablet/phone crap market of iOS and Android, which were available years earlier.

      On the other hand small LAN infrastructure servers are useful. Now imagine some Mac Mini sized shit running

    • MS from day 1 with NT was never use x86 as the main CPU.

      This was to prevent another crappy DOS or Windows 95 quirky OS optimized and insecure with buffer overflows and optimizations for just x86 instead of portable C libraries.

      NT was made for the mips in 1993, not x86 (later backported). This tradition continued and ARM makes sense for the server room.

      Most apps are database driven or network specific and are I/O bottlenecked. Not CPU. A java servlet does a query and waits 10 million cpu cycles (exaggeration

  • by bobbied ( 2522392 ) on Tuesday October 28, 2014 @11:03AM (#48250969)

    Are bound to repeat it. (And those who do know history are doomed to watch helplessly while others repeat it).

    Didn't Microsoft try this with NT? I recall that it had a DEC workstation Variant (Not that it worked all that well.)

    My guess is that all the people who understood why this effort failed so completely are now gone and few are left who remember the lesson learned for Microsoft in that boondoggle. So the young bucks are now in the process of repeating the history they don't know. They will get *some* market share, but for the price sensitive user, Linux will be a better option for ARM because going to ARM only makes sense for large sized installs. Large installs have huge license costs and start to look cheaper on Linux, even with the management costs being more.

    My guess is that this won't go well for Microsoft, but if they want to shoot themselves in the foot again, so be it. Personally, I'd not want to poke the Intel bear too much if I was Microsoft.

    • by Anonymous Coward

      Actually, NT was going to be written for Intel i860 (codenamed N-Ten, hence NT), but MIPS was used when the i860 workstations didn't materialize. Then it was ported to i386 in 1990 and Alpha for the NT 3.1 release. The NT 3.51 release was specifically created for the PPC port. It was eventually ported to Itanium, x86-64, and then ARM for the purposes of WinRT.

      So Windows has been ported to seven different architectures, with ARM merely being the latest. Since they already have an ARM port for WinRT, why not

    • by Bugler412 ( 2610815 ) on Tuesday October 28, 2014 @12:23PM (#48251685)
      The only reason NT on Alpha failed was market share driven by DEC's hardware prices (the only source of Alpha based servers at the time) was about three times the equivalent i386 server from Dell or Compaq. I ran a shop fully populated with Alpha's running NT 3.1, 3.51 and NT4 at first, we switched to Dell i386 servers because of this. The DEC Alpha's did have very good availability and uptime, but for three times the cost, and very limited to non-existent third party software (backup software, security software, etc.). It was very hard to justify the expense. Not to mention being locked in to DEC for auxiliary hardware like NICs and RAID controllers which limited the selection severely, and again at triple the cost per unit. DEC Alpha's running NT were great runners, but their hardware pricing, selection and availability is what did it in, not weakness of the OS on that platform. Methinks you should get your facts and root causes for the failures in the market of the Alpha/NT product straight before you spout off.
      • Or Carly Fiona wanted Itanium instead.

        The market was hot for ALPHA. My community college used them and Slashdot was using them as well in the turn of the century. They ran Windows and IE 6 for internet terminals and classroom labs. $3000 got you a powerful workstation that ran Linux and Windows with Office and Visual Studio and Office. True games were lacking outside Quake 3.

        But Compaq bought DEC which HP bought and Carly Fiona pillaged. Rest in peace alpha.

        They also purposedly crippled the chip to make it

        • The decision on Itanium was made well before Carly. In fact, when Intel & HP started on the Itanium project, iirc, Lewis Pratt was running things
        • Also, iirc, the decision to kill Alpha was made by Compaq, which had converted to the Itanic
      • The only reason NT on Alpha failed was market share driven by DEC's hardware prices (the only source of Alpha based servers at the time) was about three times the equivalent i386 server from Dell or Compaq. I ran a shop fully populated with Alpha's running NT 3.1, 3.51 and NT4 at first, we switched to Dell i386 servers because of this. The DEC Alpha's did have very good availability and uptime, but for three times the cost, and very limited to non-existent third party software (backup software, security software, etc.). It was very hard to justify the expense. Not to mention being locked in to DEC for auxiliary hardware like NICs and RAID controllers which limited the selection severely, and again at triple the cost per unit. DEC Alpha's running NT were great runners, but their hardware pricing, selection and availability is what did it in, not weakness of the OS on that platform. Methinks you should get your facts and root causes for the failures in the market of the Alpha/NT product straight before you spout off.

        The biggest reason the DEC Alphas failed was the lack of native software. While the systems from DEC itself were expensive (to fund the development of further Alphas as well as OVMS), there were other vendors who made & sold Alphas - companies like DeskStation, Carrera Computers, Aspen Systems, Microway and a few others. Not all of them were expensive - if one wanted, one could have had one's hands on a low end Alpha box

        However, problem was that Microsoft never supported their RISC platforms prope

        • You are correct in all that you say here. The question still comes down to market share and whether MS was willing to devote the support and development resources to a product (Alpha based systems) that at the time was less than 1% of the total market. Could they ever have turned a profit in that scenario? Not likely. Like so many other instances, quality does not always win over quantity I suppose. Alpha was a better platform, I have no doubt, but that wasn't enough to make it a winner. Power and MIPS wer
        • 100,000 Model T's will beat a 100 Cadillacs in the car business every time.
    • by Bert64 ( 520050 )

      NT for Alpha actually worked very well, it was considerably faster and more stable than the x86 version.

      The problem was a lack of applications... Most windows apps are closed source, and only compiled for x86 which meant you either couldn't run them at all, or you had to run them through emulation which incurred a significant performance hit.

      That's why Linux is in much better shape on non x86 architectures than windows, the fact that drivers/apps/etc can easily be recompiled by anyone and in most cases alre

      • NT for Alpha actually worked very well, it was considerably faster and more stable than the x86 version.

        My experience didn't match that, but I think mine was a bit unique. We where a DEC shop and where going to switch to NT. DEC and Microsoft engineers descended on us after somebody in management agreed to go that route, but they took weeks trying to get the software installed and working. I still remember the two engineers in the next cube claiming the other's company was at fault. They had a heck of a time getting all the hardware (video and network) to match the drivers and actually function and neither

      • "That's why Linux is in much better shape" Are you really comparing Linux in 2014 to NT/Alpha/x86 20 years ago?
        • Alpha doesn't exist anymore. RIP.

          In 1999 it was hot and had all sorts of apps that were essential. CS majors loved them. For $3000 they could have their own but couldn't run games. It could do excel, word, visual studio, java, and Unix stuff with FreeBSD or Linux (I was in BSD camp back then). It could trounce a highly priced x86 in it's price range.

          But yes it was niche for artists, hackers, and engineers. Carly Fiona killed it. Part of it came back to live with the AMD AthlonXPs and Athlons MPs which cream

      • NT for Alpha actually worked very well, it was considerably faster and more stable than the x86 version.

        The problem was a lack of applications... Most windows apps are closed source, and only compiled for x86 which meant you either couldn't run them at all, or you had to run them through emulation which incurred a significant performance hit.

        That's why Linux is in much better shape on non x86 architectures than windows, the fact that drivers/apps/etc can easily be recompiled by anyone and in most cases already have been.

        Pretty much everything most people would want to do on an x86 linux box, i can also do on an alpha, ppc or arm based linux box... The same is not true with windows.

        Windows apps may be closed source, but had Microsoft alone ported each one of their apps to the Alpha, the platform would have been off to a great start. Aside from that, the Alpha could have been specifically targeted at the EDA engineering community, which at the time used a mix of Unixstations and PCs: Alphas would have had the power to run a 64-bit NT well, while win64 apps would have covered both high end engineering and low end PC apps

  • wasn't NT 3.5 available for ARM, DEC Alpha, Power PC *and* x86? wasn t the core of the NT kernel based on the Mach kernel, and written almost exclusively in c? so what the hell went wrong??

    • Did it ever change?
      Windows XP, Vista and 7 were supported on three architectures, x86, amd64 and itanium (for the latter only under the names of XP 64bit edition, Server 2003, Server 2008 and 2008R2). Windows 8 droppped Itanium but gained ARMv7 - the crippled ARM version runs some win32 software by default such as explorer.exe and Office, if jailbreaked it can run recompiled/ported win32 software.

      Windows 2000 perhaps only did x86 but at least had an unrealeased port to Alpha (even 64bit Windows 2000).
      So eve

      • Technically XP didn't run on AMD64, you needed a separate OS called XP Professional x64 Edition. It shared the codebase with Server 2003 SP1, not with XP.
    • Not based on Mach, so far as I know. The head guy on the NT kernel team, Dave Cutler, came to Microsoft from DEC, where he'd been working on VMS. With that said, NT wasn't really based on anything else (although some of the TCP/IP stack in pre-6.0 versions apparently came from BSD). It was supposed to be a microkernel, but round about the 4.0 timeframe a bunch of stuff got shoved back into the kernel for performance reasons, because switching ring levels was expensive enough to matter back then.

      It is, howev

      • NT was never a microkernel then, and in fact, in 4.0 and beyond, more things migrated to the kernel. However, in both Windows 7 & 8, with 64-bit and multi-cores, the trend has moved back to a microkernel like approach, with device drivers for instance, moving into user space. At the time, microkernels would slow OSs down, but now with all those underutilized cores, that's apparently no longer an issue
  • ...but I mentioned it for the past two years: Microsoft biggest problem is that their foray into the ARM world with RT did not come with a server version. Yes, I know that RT was designed to be craptastic. Absolutely needlessly given that a much lower powered Pi can do more. ARM servers and their low power consumption allow for having many of them tightly packed into rack space and get turned on and used only when needed. Many enterprises have cyclical demands for processing power, especially for financials

E = MC ** 2 +- 3db

Working...