Limited upgrade possibilities, tiny storage, poor airflow, not ECC RAM, no redundancy in network interfaces or power supplies, no remote console and you have to bastardise the things to get two disks in.
You can do a lot better for $50/month without the initial up front cost of the machine!
Yes. This happened to a company I worked for in the UK in the last 1990s. We had a half rack full of NT4 machines and someone got into our kit and used it to run a pr0n FTP. They took us to court to pay up and the magistrate said we had no bill to pay and that it was a waste of court time as it wasn't intentional.
You're right about reporting a crime though even if the police don't take it seriously. A crime ref number goes a long way on its own.
Edit: we had to move our kit sharpish though as the company exercised their right to throw it on the street within 24 hours.
No they're not. I've worked with them. They are pretty good at turning around typical enterprise tech platforms that are in trouble. I'm not talking about CRUD stuff but heavy integration and workflow stuff with hundreds to thousands of tables that scales to thousands of concurrent users. They know the tech very well and know how to get from A to B cheaply which is incredibly difficult. They know how to organise large teams as well and have a good tech relationship with a lot of vendors which is really important.
Not joking but what we threw at them had a codebase that would scare a lot of people and they sucked it up and spat it out in good shape and they did the same with the team too.
As for Fowler, the analysis and formal descriptions he wrote up for PoEEA are rather good. Read the book at least once. You'll understand why things like hibernate were written and what problems they solve.
Well actually a bad example of their business model because they can piss off they think I'm buying another one. She's getting the innards chucked in a T420 with a 1440x900 screen and windows 8.1
My wife has a 2011 MBP blessed with a 1280x800 screen and the Helvetica face looks pretty bad from a type point of view. It's not unreadable but the type has lost its definition completely.
Unfortunately "after yesterday", things are expensive I.e. to get our definition back, we have to shift the entire unit with an i7, 16Gb of RAM and Samsung 840 Pro and buy a new unit with similar spec, which isn't cheap because you have to buy up front rather than upgrade now.
Hmm.
(I have an X201 with same res as my daily driver and its pretty good with ClearType on windows)
Not tried to push it but it has 20 Windows Server 2012 R2 instances running on it at the moment all with 8Gb of memory (this is overcommitted dynamic memory). Disk is on a SAN larger than my kitchen. I span up a Linux VM quickly to do a bogomips on :)
I can probably push 40 of those onto it without it bending too terribly. If I knock the RAM down to 2Gb an instance I could probably quite happily get 64-100 on it in theory. I think memory bandwidth might kill it before CPU does.
We have two almost full (18 each) 42U racks of those machines (bar switches) so across the 720 E5 cores with 4.6TiB of RAM there is about 4.3 million bogomips.
Fun :)
(most of this is corporate fileservers, exchange, AD, various crappy apps, network appliances, web servers, SQL servers and idles at around 20% in use). If it all went off you'd need earplugs and fireman's equipment.
Not a scientific measure by ANY measure, but a similar core I googled appears to kick out about 200 bogomips whereas a virtual Xeon E5-2690 v2 core on one of my machines knocks out 5984 bogomips.
I have 20 of those Xeon cores and 128Gb of RAM in a 2U.
Comparing the ratio of bogomips you'd have to get 598 of those ARM machines in a 2U to get the same bogomips.
Like I said this isn't even slightly scientific but is at least interesting trivia.
I don't know of any executable configuration files on any Unix derivatives. There are init scripts, but they are not configuration; they are instructions.
There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.
Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time.
Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine.
To put it into perspective, everything becomes as much of a PITA as RPM packages without yum.
That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install.
That's where we don't want to go.
We are now running FreeBSD and nginx on a HyperV cluster.
1. NT is very small. A 66MHz / 24Mb system can still throw up a desktop.
2. The UI is entirely hardware accelerated WPF.
3. You're right about the AOT which is done off the device. It still does GC on the device for most apps which are CLR based but core WinRT stuff is manual management. NT doesn't do overcommit or mmap stuff either. Also the CLR GC runs concurrently.
4. The ecosystem isn't fragmented making centralised compilation and optimisation a reality. There are very few hardware combinations to support.
5. Better native type support in CLR. There are better unsigned and binary types in the CLR making micro-optimizations possible.
Comparing to android, Dalvik is damn slow. It seems to defer all GC until an inconvenient time and suck up lots of RAM in the process. If they get that ART compiler in there then it might be getting somewhere but I suspect from my experiments with my Moto G that the compiler has a different set of performance penalties.
That's ok until there's a provider that they don't have in their database. This may be a big problem for the smaller virtual operators or calling card outfits.