monstermonster
If there isn't one, I'll take two! Cheaper than Azure!
It's one of the reasons I do a lot of my work on a proper machine with ECC and SAS disks.
Due to some duff RAM a few years ago I lost a week of work. It silently corrupted filesystem buffers.
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!
I used that intentionally to prevent the association of HN with the other form of the word. It is polite IMHO.
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.
Java EE Web profile, hibernate (via JPA), JAX-RS. That's a pretty good stack.
No JSF, servlets, JSP or EJB and it's all good.
As for Java 8 and containers, what are your issues? Just interested.
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.
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)
However if you want one fast core, you're screwed :)
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.
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.
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.
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.
A UDP packet walks into a bar.
I've owned a Sony android device (Xperia SP) Never again. Total bag of crap. Sold it and got a Moto G which was crap too. Neither devices could handle more than three tabs open without losing one and refreshing. The 630 can with half the RAM. I think NT scales down better than Android on handsets.
I'd have got the 830 if I wanted a camera phone but I lug a Nikon D3100 around.
I'm selling the kids' iPhones and getting them winphones so I don't have to deal with itunes.
Super happy.
1. Snipping tool. Allows you to screenshot and annotate then email, save, copy the screenshot. This lives in my taskbar.
2. Problem steps recorder. Screen recorder that produces an Html document with embedded images and annotated key presses and clicks.
Both very helpful!
The camera is shit but I tend to lug around a DSLR anyway if there's anything worth taking a photo of, so the phone is used for taking photos of where I parked so I can appeal tickets. Less pixels (480x854) means less power usage and I can't say I notice the difference that much compared to the wife's Moto G.
But everyone goes "fuck windows phone" and walks away from such things...