Why port? Most useful apps already run under ARM. Debian is available on ARM completely. What more do you need?
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 …
-
-
Friday 7th February 2014 07:11 GMT Matt Bryant
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.
-
Friday 7th February 2014 09:17 GMT 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.
-
Friday 7th February 2014 10:45 GMT Phil Endecott
>, 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.
-
Friday 7th February 2014 11:25 GMT 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_.
-
-
-
Friday 7th February 2014 16:43 GMT 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.
-
-
-
-
-
-
-
Tuesday 11th February 2014 10:36 GMT big_D
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.
-
-
Friday 7th February 2014 05:14 GMT 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.
-
Friday 7th February 2014 05:27 GMT 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.
-
Friday 7th February 2014 13:25 GMT Matt Bryant
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.
-
Saturday 8th February 2014 00:47 GMT 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.
-
Saturday 8th February 2014 09:53 GMT 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.
-
-
-
-
Friday 7th February 2014 06:18 GMT Flocke Kroes
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.
-
-
-
Tuesday 11th February 2014 12:24 GMT Flocke Kroes
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.)
-
-
-
-
Friday 7th February 2014 09:55 GMT 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.
-
Tuesday 11th February 2014 10:29 GMT 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 ??
http://packages.debian.org/search?keywords=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.
-
-
Tuesday 11th February 2014 13:17 GMT 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.
-
-
-
-
-
Friday 7th February 2014 08:06 GMT 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...
-
Friday 7th February 2014 08:21 GMT Hans 1
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.
-
Friday 7th February 2014 18:06 GMT CheesyTheClown
Re: An ARM world would be nice, but...
LLVM?
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.
-
Friday 7th February 2014 20:49 GMT 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?
-
-
-
-
Friday 7th February 2014 10:14 GMT 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?
-
Friday 7th February 2014 10:52 GMT 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
-
Friday 7th February 2014 12:16 GMT Gordan
Re: High performance ARM
@Fenton:
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.
-
Friday 7th February 2014 13:44 GMT Fenton
Re: High performance ARM
@Gordan
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.
-
Friday 7th February 2014 15:22 GMT 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.
-
Friday 7th February 2014 15:42 GMT 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.
-
Friday 7th February 2014 20:54 GMT Gordan
Re: High performance ARM
@AC
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.
-
-
-
-
-
-
-
Friday 7th February 2014 13:17 GMT Matt Bryant
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.
-
Friday 7th February 2014 15:45 GMT 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)
-
-
Friday 7th February 2014 17:51 GMT 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..
-
Tuesday 11th February 2014 12:40 GMT 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: http://lists.debian.org/debian-devel/2013/02/msg00413.html
We're just waiting for the hardware now ...
-
-
-
-
-
-
Friday 7th February 2014 21:23 GMT 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.
-
Saturday 8th February 2014 01:15 GMT 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.
-
Saturday 8th February 2014 10:57 GMT Mage
Virtualisation
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.
-
Thursday 13th February 2014 21:43 GMT 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...