More than once I’ve added a monitor or changed a monitor configuration and lost my applications to the nebulous missing screen area that once was. Almost everybody knows the secret of right clicking your taskbar icon, clicking move, then tapping an arrow key to fasten your missing window to your cursor… it’s the bomb-diggity way.
What happens when you right-click though and the familiar Alt Menu with Minimize, Maximize and Move just doesn’t appear? Some Windows windows are apparently generated without the option to bring up that menu from the taskbar. There is still a way – do your normal left click on the taskbar item for the window you’re missing, then tap Alt+Space. Tada, the familiar Alt Menu just showed up somewhere in your viewable screen area, hopefully.
Now if you have Windows that are programmed without taskbar entries – good luck. I haven’t encountered it yet, when I do I’ll update.
I fought this far too long. Generally I’m a guy who doesn’t like fiddling with root, aftermarket bootloaders and non-stock Android ROMs. At the same time I carry around 2 phones, an iPhone 5 and a Motorola Droid RAZR Maxx (Spyder or XT912 if you prefer). Because I’m spoiled by the iPhone for part of my life, waiting for simple things like search results or even the keyboard to slide up for even milliseconds can be infuriating. Android phones are like Windows computers, they seem polished and usable on day one, but as time goes on they somehow manage to get crufted up and slower than molasses. So once again I find myself dicking with my phone to make it useful in the way I want it.
The process is easier than ever on this phone, and SafeStrap allows you to do it all without ever compromising your stock Android. It’s nice to have that safety net. I got LiquidSmooth 3.0 (KitKat) going without a hitch. The phone was faster, smoother, better than ever in every way. Unfortunately I got the message in the title whenever trying to send or receive MMS It is a dealbreaker. After fiddling with apns-conf.xml, build.prop, loading 3rd party messaging apps, and spending countless hours flashing, reflashing etc. I found the only solution ended up backing out to JellyBean, I used Eclipse which was fine.
Determined yesterday I returned to my KitKat endeavors. There are some features in it I just don’t want to be without. I spent the same countless hours doing the same things. There are hundreds of people on the Internet with apparently the same problem, but no silver-bullet sort of solution pops up. For me that silver bullet was as simple as changing my “Preferred network type” setting from Global to CDMA+LTE/EVDO. That was it!!! I even tried it on a couple of different ROMs just to make sure.
Hopefully someone else finds this and saves themselves the same amount of time troubleshooting that I did. It would make sense for me to revisit the countless threads on different forums scattered across the net and put my findings there, unfortunately it’s just not going to happen. Hopefully this post finds it way to the top of the Google heap.
The top Google result when searching for how to uninstall an Active Directory LDS (Formerly known as ADAM) instance doesn’t seem to apply to 2012 anymore. It was more straightforward in 2008 R2 and before as each instance just showed up as a Windows Feature.
Googling the problem didn’t yield the simple solution, but it truly is simple. Before you waste a bunch of time right-clicking random crap in Server Manager and going through the add/remove features seven ways from Sunday, hopefully you found my howto here. It’s as simple as this:
c:\windows\adam\adamuninstall.exe /i:instanceName
Click through a few dialogue and warning boxes and you’re done.
Disclaimer first: I’m well aware that this is a very short-sighted disk performance analysis.
I had some stress testing I wanted to do to some new disks prior to putting them into production. Because I’m too poor/cheap to buy SAN adding disks will result in an outage of my services, which means taking them back offline in the event that something was wrong would at least double my outage window, probably more.
In addition to my meager endurance testing I also wanted to do my own analysis of how bad RAIDZ sucks. Don’t get me wrong, I love ZFS, but more than once its performance (or lack thereof) has come back to bite me. That’s why I’m adding disks to my storage system in the first place. With that in mind I created a few different types of zPools and ran Bonnie++ on them. I am starting with 15 146GB 15k RPM SAS disks, directly attached to FreeBSD 10.0. I had 3 different zPools I wanted to test:
RAIDZ – 5 of 3+1
RAIDZ – 1 of 14+1 (unrealistic to ever use I know)
RAID10 – 7 of 1+1
I created a single zPool in each case representing the disk layouts I wanted to compare, I then created a single ZFS inside the disk pool with no tuning, except in the case of those with compression. For those with compression, the zfs option was set to lzjb.The command used to run each test was
So I was disappointed in that the RAID10 didn’t do terrifically better than the RAIDZ 5 of 2+1. As a matter of fact I may end up choosing the latter model as it gives me over 400GB of additional usable space at minimal cost of redundancy and performance. On the other hand, with the RAID10 configuration I do have a hot spare. It may come down to the toss of a coin. One thing is (and always has been) certain though, and that is that I’ll definitely be compressing the data. It was for that reason, midway through I wanted to enable compression and how the compression vs. non-compression analysis came about. As I said at the beginning of this post the tests are barbaric and take into count no sense of the actual workload that this box will see, and also it will be delivered via NFS to the clients, however at first glance a compressed ZFS volume will outperform an uncompressed volume with this particular setup.
The reason for the additional speed using these barbarian tests is that I go from 80GB of block data to only 2.3GB when compressed. The compression ratio is indeed insane and is no doubt the reason for the increase in speed. At the expense of some leftover CPU cycles (which I have plenty of on my production system) I spend a lot less time going to spinning disk since such a great ratio of my useful data lives in ARC. On my production system, this 80GB test would have never went to disk as all of the compressed data would have been in ARC.
Once I get the disks attached to the production system we’ll run some real world tests where I create a workload somewhat representative of my clients and run IOmeter on a guest VM. The results of that – yet to come.
It is a dealbreaker. After fiddling with apns-conf.xml, build.prop, loading 3rd party messaging apps, and spending countless hours flashing, reflashing etc. I found the only solution ended up backing out to JellyBean, I used Eclipse which was fine.