back to article Hands up if you have one good reason to port enterprise apps to ARM

ARM servers look tantalising. Various CPU vendors offer multi-core silicon at a price that makes Intel go weak at the knees. Those CPUs also slurp so little power that by the time a senior manager reads about them in an in-flight magazine you'll be asked why you're not using them yet. Throw in the fact that Dell and AMD have …


This topic is closed for new posts.
  1. Martijn Otto

    Why port? Most useful apps already run under ARM. Debian is available on ARM completely. What more do you need?

    1. Matt Bryant Silver badge

      Re: Martijn Otto

      "Why port? Most useful apps already run under ARM....." You mean geek apps, actual business apps that run on ARM are like hens' teeth.

      ".....Debian is available on ARM completely....." Linux is also available on x64-compatible Atom CPUs, which means if I do have a requirement for low power I can already get it without needing to recompile anything. I may pay a fraction more on power but it will probably be a lot less over the lifetime of the unit than the cost of porting all my apps.

    2. Gordan

      Both Debian/Ubuntu and Fedora/EL based distributions now have their fully featured ARM variants, so for a typical Linux shop running a LAMP or similar stack there really is nothing to port - it has all already been done. I have worked with several clients whose LAMP(ish) stack projects migrated without any problems at all on the ARM variant of the same stack.

      The biggest obstacle to addoption, IMO, has been the lack of good, standards compliant ARM motherboards - and by this I mainly mean *TX form factor. Random-slab-of-PCB form factor for the vast majority of ARM machines is a huge pain in the backside, as is a frequent lack of SATA ports for any more serious use. AMD's recent noise about the A1100 Opterons is welcome but the announcement was vastly premature - I spoke to them earlier this week and was told that the earliest these might be availble to developers is 2nd half of this year, which is not what you would expect after the announcement fanfare; call me old fashioned but when they talk about something the way they do I expect to be able to get my hands on one within a week or two at most.

      Having said all that, there does seem to be one ARM offering that is head and shoulders above the rest in terms of standards compliance (*TX form factor, SATA), specification (4-core Freescale A9, 4GB of RAM) and cost (~£220 for the motherboard which includes the CPU, RAM and PSU, cheaper than comparable x86 Atom based offerings). To put the price into perspective, this is only about 2x the cost of a SheevaPlug, but has about 7x the CPU performance and 8x the RAM, plus the huge added *TX convenience. Best of all - you can buy one _today_. Google cornfed servers and you should be able to find it.

      1. Phil Endecott Silver badge

        >, there does seem to be one ARM offering that is head and

        > shoulders above the rest in terms of standards compliance

        >. Best of all - you can buy one _today_. Google cornfed

        > servers and you should be able to find it.

        Looks a bit vapourware to me. Have you actually seen one? The website just shows a mini-ITX case and has a "contact us" web form.

        FWIW, at this point I think it is probably worth waiting for ARMv8 (64 bit) devices. The future AMD offering may be the best bet.

        1. Gordan

          I spoke to them this week and my motherboard is in the post. Definitely not vaporware, unlike the AMD offering. Don't get me wrong - what AMD announced looks _great_. I would love a powerful 8-core ARM (as in, more powerful than Arndale) with 128GB of RAM (mock build everything on tmpfs!) to replace my build farm of Sheev/Guru/Dream Plugs. Unfortunately, I cannot wait for another 6 months for that to become available - I need to get my EL7 ARM build going at a decent pace _now_.

          1. Phil Endecott Silver badge

            > my motherboard is in the post.

            Well I hope it works out OK. How much did it cost?

            If they ask for feedback, tell them that putting actual photos of the board and actual prices on their website would make it look much more believable.

            (Not my downvote BTW)

            1. Gordan

              I'll let Lew answer the exact cost part (I had no idea he was reading the reg forums :)). I had already mentioned that seeing a product without a price tag was offputting.

              Thankfully, for once the lack of a pricetag does not equal to a lack of a product.

              1. Salts

                Actually, the lack of a price on the website put me off, but I do have a project in mind for this type of solution, as Lew as taken the time to post here, I will take the time to fill in the enquiry form.

                In general however if there is no price on a website I don't bother, too many follow up emails asking how can they help, blah, blah, blah.

        2. LewB


          cornfed servers has been shipping our 4 core arm server since dec 2013 and demo'd apps at IT-EXPO in jan. its fully functioning and we have MB and case mounted servers available for developers. If we can help, get in touch at cornfed servers.

    3. Anonymous Coward
      Anonymous Coward

      And more importantly so is Windows - Windows Phone and Windows RT already run on ARM.

    4. big_D Silver badge

      And all of those custom LOB applications? Do you even have all of the source code? Do you have ARM compatible compilers that will take the code?

      The OS and some standard packets are all well and good and simple applications, like file, print and web serving can probably be moved across relatively easily. But those bought in LOB solutions? What about the custom written LOB solutions? How much are they going to cost to get somebody in to recompile them and work out any issues and bugs that come along? Are all the third party libraries available in ARM versions?

      I'm not saying it isn't possible, or that for standard needs it can't be done relatively easily, but you need to do a lot of investigative work and testing to get custom code transferred. The question is whether it is cost effective to do so? Or maybe wait until the next generation of the LOB tools needs to be written / bought in and go ARM then.

  2. Charles Manning

    Is this a shill piece for VMWare and Intel?

    Pretty much anything Linux runs fine on ARM. The whole of Ubuntu runs on ARM.

    If you need anything else, it is pretty easy to achieve.

    I've been writing Linux ARM stuff since about 2000 and being on ARM has never really held anything back. Heck, at one stage I even usesd a complete self-hosted developmnest set up with the compilers, editors etc running on ARM. Normally though cross compiling from a PC is faster and easier.

    So tell the boss fine... porting to ARM is not a huge issue in itself.

    1. Matt Bryant Silver badge

      Re: Charles Manning Re: Is this a shill piece for VMWare and Intel?

      You really need to get that chip on your shoulder looked at.

  3. Number6

    I have a couple of little ARM machines handling DNS and DHCP, as a master/slave pair so that there's a bit of resilience. They'll stay up longer than anything else due to the light load on their battery backup, and come up before anything else. They also do local NTP services, polling a different set of servers out on the internet. Far more robust than using a large server, and more configurable than a typical consumer router.

    1. Matt Bryant Silver badge

      Re: Number6

      "I have a couple of little ARM machines handling DNS and DHCP, as a master/slave pair so that there's a bit of resilience...." TBH, so what? How long did it take you to hand-craft your solution compared to the ease of buying OTS MS components and an x64 serer (or, easier still, buying the processing power in the cloud)? I'm pretty sure it was ten years ago there was a complete website (full LAMPs stack) running on iPaqs that got a lot of geek attention, but it didn't make any business anywhere drop Xeon and MS Windows Server.

      If anything is going to break the Wintel server monopoly it is going to be cloud offerings, where you don't give a fudge what is actually running the applications just as long as they do so reliably. And until they build clouds with real business apps on ARM it is still most likely to be an x64 cloud.

      1. Number6

        Re: Number6

        I see no need to use cloud services for what I do, half the fun is playing with it and learning how the stuff works. I've got another little ARM platformm running a 6to4 tunnel so my home network can do IPv6. I get to pay the electricity bill too, so a couple of little 5W boxes easily beats 100W+ of server ticking over, although I'll admit the room is a lot colder in winter now than it used to be when I had several big x86 machines running. As for handcrafting, that's all part of the learning process, and having done it once, the second one didn't take much time at all.

        I would not use the little ARM platforms as-is for serious professional deployment - the lifetime of the SD cards used to boot is not good enough and they suffer bit rot. I've had to rebuild a few times, although once the base image is built, it's easy enough to create a new bootable SD card.

        When it comes to using Windows servers, I'd have to pay for those, with Linux I can just throw together a new system to play with fairly qickly, no licence or activation hassles and no multiple reboots as it's patched from install state to latest release. It was hard at first, but now I'm up the learning curve and it's relatively straightforward. Perhaps if I was paid to do it I'd think differently.

        1. Gordan

          Re: Number6

          I'd just like to point out there are several ARM boards available with SATA ports, including the recent SheevaPlug, GuruPlug and DreamPlug, TonidoPlug2, CompuLab SBC-A510, Cornfed i.MXQ board, Higher end SolidRun CuBox-is, TrimSlice (note: it's SATA port is actually running via a built in USB->SATA adapter because CompuLab couldn't get PCIe SATA working properly for some reason on Tegra2) just off the top of my head.

          On the point of how long it takes - I'm pretty sure it would take me substantially less time to set up a DreamPlug with Linux from scratch to act as a DHCP, DNS and NTP server that it would take to install Windows Server and configure the services on an even remotely similarly specced Atom machine. The process for the DreamPlug would be:

          1) Extract rootfs to disk (one-liner)

          2) Copy modules/firmware to rootfs and the kernel/initrd to bootfs (2 lines)

          3) Configure uboot to tell it where to get the kernel from and tell the kernel where the rootfs is (2 lines)

          4) Reboot into new OS

          5) yum install dhcpd bind bind-utils ntp ntpdate

          6) dhcpd would need 3-4 lines in the config to tell it IP ranges DNS and gateway to serve plus any specifics for more fancy things, e.g. assigning specific IPs to specific MACs. NTP should need no extra configuration, and Bind comes configured by default to act as a caching name server.

          All of that would take little more time than it did to type this message.

  4. Buzzword

    Managed code

    Chances are your server code is written in an interpreted language anyway. Java, .NET, PHP, Ruby - as long as there's an engine your apps should just work.

  5. Flocke Kroes Silver badge

    Hand is up

    A decade ago, ARM was big endian, which caused a small hiccup (See man 3 htobe64 for the solution). ARM is big endian now, so the problem has evaporated. There was some hassle when x86 became AMD_64, (see man stdint.h). Sometimes this showed up again when porting AMD_64 back to ARM (See man inttypes.h).

    Porting to ARM has been trivial before, and will be even easier for 64-bit ARMs. Been there. Done that. Didn't bother to get a T-shirt.

    1. Gideon 1

      Re: Hand is up

      ARM can do both endians, but it is usually run in little endian mode just like x86.

    2. alain williams Silver badge

      Re: Hand is up

      If your application only works on machines of a particular endian - it is broken, full stop, no excuses.

      It is not hard to make applications work on machines of different: endian or word lengths.

      1. big_D Silver badge

        Re: Hand is up

        It depends on how much assembler you are using...

      2. Flocke Kroes Silver badge

        Re: Hand is up

        Early this century, pppd gave me some hassle because back then it had some little endian only code. Endianness shows up whenever multi-byte values go over a network, get stored on disk or are sent to some hardware. As I have been doing embedded systems for decades, I step around the pitfalls without thinking. I heard Microsoft had real problems with endianess because their file formats depended on where the C compiler placed values in a structure. If that is true, it would have hit them again for 64-bit machines, and if they ever meet an 8-bit CPU that does not benefit from padding out to word boundaries it will byte them again.)

        (Endian typo - The last few ARMs I met were little endian only. Selectable endianness is fading into history.)

  6. A Non e-mouse Silver badge


    For those who mention that Linux already runs on ARM, I suspect VMware really mean "porting Windows apps"

    1. anoncow

      Re: Windows

      Why would anybody bother porting a Windows app to ARM? Is VMWare really that out of touch?

      1. LaeMing Silver badge

        Re: Windows

        Windows? Isn't that a client-side OS?

        1. Anonymous Coward
          Anonymous Coward

          Re: Windows

          "Windows? Isn't that a client-side OS?"

          Presumably he meant "Windows Server".

      2. Anonymous Coward
        Anonymous Coward

        Re: Windows

        You may have missed it, but every company I've worked in uses Exchange, MS Office (which, even with Ribbon, is better than Libreoffice), and a whole host of other pretty platform-specific programs. Can you imagine the reaction if you went to a supplier and demanded they now create a Linux version of a diagnostic program for something they stopped building 10 years ago? They wouldnt do it, nor would you get hold of the source code for it.

        Not to mention the obligatory poorly-understood internal systems for managing data that came about when a manager heard people yammering on about Databases and thought they were a good idea. Every business has them, and IT depts really dont do enough to give people the tools and knowlege to do this properly (and under the watchful eye of IT).

        The first person to create a Linux-on-ARM compatible drop-in Exchange replacement will become a very rich person indeed. But to the best of my knowledge it hasnt happened yet.

        1. Mike Pellatt

          Re: Windows

          "The first person to create a Linux-on-ARM compatible drop-in Exchange replacement will become a very rich person indeed. But to the best of my knowledge it hasnt happened yet."

          OpenChange ??

          I see arm in the available architecture list....

          Not, of course, that a few people will become rich on the back of this. But plenty will make a decent living, which is acceptable to me.

          1. big_D Silver badge

            Re: Windows

            I've used openxchange a few times over the years, but it is a pain to configure and still needs a lot of work. I haven't tried openchange.

            1. Mike Pellatt

              Re: Windows

              I've used Microsoft Exchange a few times over the years, but it is a pain to configure and still needs a lot of work.

              The latest complaint from my users is that as soon as they change a new appointment to "all-day", it automagically changes the status from "busy" to "free". Which leads to appointments being put into peoples' holidays, unless they notice this and change it back again. Needless to say, googling reveals lots of moans about this and the inevitable "fix" that "fixes" an entirely different issue, nevertheless being flagged as the "answer" by some Microsoft forum moderator.

    2. Tom 7 Silver badge

      Re: Windows

      You mean porting windows apps that dont use VB.

  7. Return To Sender

    An ARM world would be nice, but...

    Remember that porting on any scale would only happen if there's a strong economic reason to do so. We can have all the debates we like about the difficulty or otherwise of porting, but these days money wins.

    Now, demonstrate a toolset that makes it equally easy (as in just a compiler option) to build on ARM as x86 and you might get the software houses on board. Persuade them to make their licensing platform agnostic, and you've got a non-argument for corporates when choosing their hardware. Demonstrate that the cost of acquisition is the same or lower as x86, that's another barrier down. Show that you can knock percentage points off of your operating costs, that's the money men on board.

    And of course you'll do all of this on the sort of timescale that prevents Intel finally working out how to make the x86 run at really low power (not sure personally that's possible), thus removing your competitive advantage.

    Don't have to like it, but you can't stick your fingers in your ears and go 'la-la-la' either...

    1. Hans 1 Silver badge

      Re: An ARM world would be nice, but...

      >Now, demonstrate a toolset that makes it equally easy (as in just a compiler option) to build on ARM as x86 and you might get the software houses on board.

      Ever heard of cross-compiling ? I compile Windows apps on Linux, man ;-).

      The thing that is great for ARM is that you already have a complete ecosystem, complete software stacks, OS' etc available on ARM thanks to the freetards. Linux and BSD's run on ARM, what more do you want ? This means the whole Internet infrastructure can be moved to ARM.

      Maybe ARM will mean Windows will die off quicker than expected, Intel saved MS' lunch by increasing performance at regular intervals, but I doubt they will get Windows Server to run on ARM ... even ONE gui-less windows server install takes up 32Gb, I can have 10 Linux/Freebsd servers instead ... I know disk space is cheap, but still 10 times more ... Plus, when I calculate CALS, Server licenses, Exchange/SQL Server/whatever license etc I can even get support for the 10 servers for the same price as the one windows server.

      Even Avaya claims Linux has a lower TCO than Windows, they are not exactly Linux-friendly as they do not provide client software for Linux.

      1. CheesyTheClown

        Re: An ARM world would be nice, but...


        Would be nice if someone implemented a "fat-elf" (dwarf is already taken) shared library/executable format that could store x86, x64, ARM 32 and ARM 64 all in a single file. Would actually be child's play. Then just package an LD which can link fat binaries generated by four cross compilers.

        1. Gordan

          Re: LLVM

          This was discussed to some extent back when soft-float/hard-float issue on arm was being considered. In the end, the conclusion was that rather than coming up with a dynamic linker bodge that could handle both and rolling fat binaries that contained the payload for both, this taking up double the memory (or requiring awkward strapping that would purge the non-executable payload from memory after mmap()-ing it) it was more sensible to have a clean break. And you know what? This isn't such a big deal because the vast majority of software people run on ARM is FOSS.

          The question is really why would you want a single hugely bloated executable that runs on multiple platforms? What problem does it solve that isn't much better solved by just having different binaries? You have to compile it once for each platform before gluing them all together anyway, so what does it actually gain you that shipping 4 different binaries (or a zip file, or shell archive containing all 4) wouldn't do just as well?

  8. Fenton

    Database file compatibility

    Now what would be interesting is a database with two sets of executables, one on ARM the other on x86 but can read the same datafiles.

    During the day I might want to shunt my DBs off to a lower power farm running ARM.

    So shutdown x86 VMs, start ARM VMs and attached to the same set of datafiles.

    I don't believe that is supported by either Oracle or IBM.

    In fact the only DB I know of that is certified to run on different CPU architectures using the same datafiles is SQLserver, on x86 or Itainium but who runs windows on Itanium these days?

    1. billse10

      Re: Database file compatibility

      try MySQL

      "who runs windows on Itanium these days?" Well, certainly no-one who wants to run Windows Server 2012 ;-)

    2. Gordan

      Re: Database file compatibility


      You can already do this with both MySQL and PostgreSQL. The on-disk formats and wire protocols are exactly the same, completely compatible, and endiannes independent. I do this sort of thing all the time.

  9. Fenton

    High performance ARM

    Is it not time we had a high performance ARM chip. In my scenario above of migrating from x86 for peak high performance load to off peak low perf requirements, if we had a 2 different ARM architectures, a nice lower power one and a 3.x GHz monster we could use Vmotion to move loads around.

    Or just stick to x86 with xeons and Atoms.

    Alas my apps only run on DB/oracle/SQLserver/Sybase

    1. Gordan

      Re: High performance ARM


      Have you heard of ARM's big.LITTLE achitecture? It gives you 4 Cortex A15 CPU cores and 4 Cortex A7 CPU cores. The A7 cores are a little less powerful, but a LOT less power hungry, so depending on the load the system is on, it will use one or the other set of cores (or all 8 cores on the recent Exynos CPU systems such as the Arndale board). So ARM already provides this kind of functionality on a single slab of silicon.

      As for your apps - if they are based on closed, proprietary technologies you are indeed screwed, but that was always going to be the case, starting with the cheque you write to the vendor for the licences every year.

      1. Fenton

        Re: High performance ARM


        The apps arn't the problem, (ok they have not released an arm port yet), as they are OS/DB independent

        just we are constrained on the DBs as the Vendor only supports "Enterprise class" DBs.

        Oracle is such a pain in that you have to migrate to a new OS, even on the same CPU architecture. I'd rather just replace the exe's and just read the database files.

        1. Gordan

          Re: High performance ARM

          It's funny you should say that Vendor only supports "enterprise class" DBs, and then you mention Oracle - when Oracle now owns MySQL. Oracle DBs don't even feature in the top 10% of biggest databases by size or throughput I have seen in the field, every one of those has been MySQL. Oracle is down there in the noise with PostgreSQL. I'm not saying that PostgreSQL isn't as good a database - far from it; I'm merely saying it doesn't seem to be as popular.

          1. Anonymous Coward
            Anonymous Coward

            Re: High performance ARM

            "biggest databases by size or throughput I have seen in the field, every one of those has been MySQL."

            Probably because they couldn't afford the licensing fees for the real thing. Big databases usually run on Oracle (top by revenue) or SQL Server (Top by volume) these days. MySQL is mostly a cheap toy for running web sites. Sure it has some niche uses, but nothing even remotely approaching Oracle and Microsoft SQL.

            1. Gordan

              Re: High performance ARM


              How are you meaningfully comparing revenue in a meaningful way between Oracle and a FOSS package?

              Also how are you comparing the "volume" between MS SQL and a freely downloadable FOSS database? If we are comparing the number of downloads of MySQL (and don't forget to include the distro ISOs rather than just the deb/rpm/tgz as well as summing the totals for MySQL, Percona and MariaDB) with the number of copies of MS SQL shipped/downloaded from MS I suspect that the "volume" of MySQL deployments is some orders of magnitude bigger than MS SQL.

              If you are going to compare statistics then make sure those statistics are meaningful in the context of all the items in the comparison.

  10. Volker Hett

    We ported from whatever-it-was-hp-had-in-the-micro-xe to Risc and then to x86, why not to ARM?

    With VMWares arguments we'd still be running that old HP-3000!

    1. Matt Bryant Silver badge

      Re: Volker Hett

      "We ported from whatever-it-was-hp-had-in-the-micro-xe to Risc and then to x86, why not to ARM?....." In each of the migration cases you mention there was a compelling business case for moving which is, as yet, missing from ARM. Simply saying it uses less power is not going to sway a lot of developers to stump up the costs of porting their products off a platform (x86) that is still selling more than well enough (more than half of ALL the servers in the World in use in business are Wintel), and without the applicatiosn there will be no companies willing to bet on replacing x86 servers with ARM ones. Laugh all you like, but Balmer was very right when he said "developers, developer, developers", and for years MS and Intel have been making it very easy and profitable for application vendors to run their code on x86. Whilst the anti-MS fanbois will shriek and grind their teeth in denial, the fact is Linux has been available on x86 for donkey's years and has hardly made a dent in MS's share of the server market, so expecting it to magically usurp the Wintel beast with ARM is just being tragically naive and wishful.

      What ARM really needs is a whole bunch of mainstream COTS applications to be announced as available on ARM-based servers. Until that happens it will remain in the webserving/VDI/HDI niche.

      1. Anonymous Coward
        Anonymous Coward

        Re: Volker Hett

        "What ARM really needs is a whole bunch of mainstream COTS applications to be announced as available on ARM-based servers. "

        Bearing in mind that 75% of servers run Windows Server, and that Microsoft already ported the current Windows Kernel and OS to ARM, yes the apps and an ARM server flavour edition of Windows are all that is needed to drive adoption. No one in enterprise cares about all these weird and wonderful Linux flavours that no one uses It needs to run Windows to be mass market. (Or SUSE / Redhat for Linux stuff)

        1. Anonymous Coward
          Anonymous Coward

          Re: "SUSE / Redhat for Linux stuff"

          Fedora and OpenSUSE have both had ARM capability for select ARM64 hardware since late last year, and informal ARM capability for much longer than that, so you may not have to wait too long.


          1. Gordan

            Re: "SUSE / Redhat for Linux stuff"

            Aarch64 has not been in any official Fedora build thus far. Last time I checked there were only preview developer builds because there were still a few important packages that were broken on aarch64 due to package and toolchain bugs.

            GCC took quite a while (a year or two) after ARMv7 hardware was easily available before the hard-float support was working sufficiently well to be suitable for full distro building. It would not be surprised if ARMv8 support at toolchain level takes a similar length of time to become sufficiently stable after the easy general availability of hardware..

            1. Anonymous Coward
              Anonymous Coward

              Re: ARMv8 toolchain support

              They've made a real effort to get the tools ready in advance of hardware this time. GCC has been generating A64 code very reliably for years. Debian has been bootable for almost a year. Here's the announcement from Feb 2013:

              We're just waiting for the hardware now ...

  11. Glen Turner 666

    Enterprise computing is like competing to be the new mainframe

    Why the fuss about enterprise server applications? They might matter to VMware, but they are a diminishing proportion of computing. ARM AArch64 might be able to run enterprise applications, but why would a ARM chip manufacturer go up against Intel with a high power, high throughput chip when it could make more certain money with a low power design.

    What AArch64 will do is to totally win the "appliance" space, as those little 1RU boxes which do useful things will have less power draw (and thus heat issues, and thus be cheaper to design and own and be more reliable). Those appliances pretty much all run Linux, or will.

    AArch64 also has a decent run at a peculiar sort of desktop -- the space which used to be filled by the "IBM mainframe terminal". Low power -- with its reliability and a small size on the desk -- makes ARM more attractive than x86.

    I doubt ARM has much hope in the cloud, as it's performance per watt still trails x86 at maximum throughput. Remember that cloud servers are provisioned to be either at maximum throughput or to be off. If ARM is used it will be because cloud providers specify their own CPU, and obviously AArch64 is available for that, whereas x86 is not.

    There's plenty of opportunity to make money with ARM servers without going for the hardest market first. The only attraction of enterprise is the large profits available due to their poor management of computing. But that very same poor management makes them adverse to change.

  12. itzman

    since anythning I writre server side is ...

    ...either C or PHP..

    I'd have zero trouble spending half a day recompiling.

    And I would, like as not.

    If you have code written for Linux on an x86, it will port to Linux on ARM.

    Only MSexcresence code wont.

    So what? legacy apps can run on X86 as long as Intel is still in business.

  13. Mage Silver badge


    Windows needs Virtual machines more than Linux. Which is more efficient? 10 copies of the OS with SQL & Web Server & Mail server on each copy or 10 users using one copy of OS, SQL & Web Server & Mail server?

    Windows Server doesn't support multiuser in the sense UNIX, Solaris, Linux always had. VMware have a vested interest in x86 as MS are unlikely to port a full Windows Server, Exchange, IIS and MS-SQL to ARM any time soon.

    With ARM it makes more sense even if you do need 10 copies of the OS to run them on 10 ARMs. Not virtualised on one x86.

    1. Gordan

      Re: Virtualisation

      If you are running Linux on Linux you might as well just use VServer (or LXC or OpenVZ). No need for full virtualization sucking away the performance.

    2. Anonymous Coward
      Anonymous Coward

      Re: Virtualisation

      "Windows Server doesn't support multiuser in the sense UNIX, Solaris, Linux always had. "

      Quite true- Windows has more powerful isolation - it's hybrid microkernel architecture means that different users instances and driver instances can be fully isolated from the kernel.

      And of course Remote Desktop Services is also a far more powerful multiuser platform than anything than those legacy UNIX type OSs have...

  14. ATeal

    What are you guys babbling about?

    I've been reading the comments and you lot are whining about nothing. Porting stuff to ARM is effortless. Why is enterprise stuff different? It is really really easy, you just have to set (your compiler of choice, GCC in my case) to compile to arm, this may mean checking out the repo and waiting for GCC to compile, and configuring it to actually be able to compile to arm, but once you've done that you are quite literally done.

    When you compile things with this compiler you wont get x86_64 stuff, no, you'll get whatever flavour of ARM you compiled for. I think developing on ARM would be a bit tedious because... well ARM chips are slower, but this isn't a downside, just do stuff on a computer, but yeah make binaries on whatever architecture you like. You could even compile your x86 stuff on ARM! GCC doesn't care, most optimisation are done before RTL is lowered into hardware registers anyway, after that it's just register pressure.


    If this breaks your code, you were doing it wrong, this is the very definition of "portable" code. By all means have some lovely platform specific hack, but use the lovely preprocessor to choose a version based on the target and write a fall-back not-hacky one.

    I really hate Windows, it is slow and crap and just... I could never use it, instead I love wxWidgets and compile windows binaries using MinGW's flavour of gcc) and test them using WINE.

    I don't see the issue here

    1. Roland6 Silver badge

      Re: What are you guys babbling about?

      >Porting stuff to ARM is effortless.

      Yes and no!

      As has been pointed out the typical 'enterprise' application will have been designed and written for an x86 or equivalent platform. Where the typical approach has been to include 'features' and assume that if things run slow then just throw a more powerful CPU at it. However, sensibly porting to ARM is a bit like doing the opposite, namely: taking something that runs great on the typical enterprise server CPU - a mid to high end x86 (or equivalent) and dropping it onto a low end CPU. Done poorly, and you end up with something like Windows 7 starter on Atom - yes it 'works' but it's hardly usable...

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019