A lot of people have experienced the dreaded "Bluetooth Not Available" problem on their Apple machines, and I just recently had it happen to me.
I've seen it before, and just rebooted to resolve it but this time I researched more.
Some people report that resetting the SMC will fix it. Some report it's a temperature thing. Odds are it can be many things, so this fix may not work for you.
One forum post reported that they hadn't noticed it, but they were using VMWare, and one of their VMs had taken control of the bluetooth device - simply unhooking it from the VM allowed it to be used in OS X again.
Imagine my chagrin when I noticed that was what had happened to me...so if you get this message and use VMWare, check your VMs to see if one of them grabbed the device. Disconnecting it will get you going again.
Thursday, September 25, 2008
MacBook Pro rev3+ works with 6GB ram (1x4GB SODIMM, 1x2GB SODIMM)
1x4GB SODIMM RAM sticks just came out, and they're actually not that expensive ($179 @ NewEgg)
Read on a zdnet review site that a Rev3 or higher MacBook Pro would boot with 2x4GB sticks, but not work well
An enterprising forum member on some Australian tech site defied someone else's unsubstantiated data to show that in a 1x4GB+1x2GB SODIMM configuration it would work, so I ponied up to try it for myself along with a colleague.
Works just fine for me, second day running. Going to kit out the rest of the office with them.
VMs running with 2 CPUs and 3GB of RAM while your host machine is still humming along? Definitely worth $170...
Read on a zdnet review site that a Rev3 or higher MacBook Pro would boot with 2x4GB sticks, but not work well
An enterprising forum member on some Australian tech site defied someone else's unsubstantiated data to show that in a 1x4GB+1x2GB SODIMM configuration it would work, so I ponied up to try it for myself along with a colleague.
Works just fine for me, second day running. Going to kit out the rest of the office with them.
VMs running with 2 CPUs and 3GB of RAM while your host machine is still humming along? Definitely worth $170...
Saturday, August 30, 2008
Build systems, and work flow thoughts
Long time, no post. No worries though, there are new tasks and new thoughts associated with them. Here's a couple.
First is a general problem associated with build systems. For some reason, it appears that dependency resolution and build/package/deploy scripting always get mixed up in build systems. I'm creating one now for a large Java system and the fact is that all the available tools and styles leave me unsatisfied.
A system that is basic might include dependencies persisted into the source tree (libraries etc committed) with ant scripting. This is functional but for systems with multiple modules, like the one I'm working with, it results in either a lack of fine-grained library control, or library clashes, or library redundancies - all of which are maintenance inefficiences. At the ant level you would either end up with a large complicated ant file that is hard to maintain or you would have many sub-build files which may have redundancy
A system that is more "modern" would use maven for dependency resolution and build, but the problem as I see it is that while you eliminate the operational inefficiency associated with library placement you add a large maintenance inefficiency in that you were already using a source control system and now you have a fair bit of work to do to maintain your maven repository as well, in order to back up your dependency declarations. Further, scripting the actual compilation and packaging of your artifacts can be done in maven but is not elegant, to my eyes.
I have heard that ivy+ant can help, but as ivy is built on maven repositories to meet declared dependencies there is still the maintenance cost of maintaining a repository, and scripting the build in ant reduces the problem at minimum to the cost incurred in the basic build system.
Which all leaves me honestly feeling as though from a pure dependency resolution and artifact production perspective that the basic system with libraries in the source tree and ant scripting for artifact production is still the global optimum for build systems. That just can't be the case, can it? I'd love to hear otherwise.
The only saving grace I'm aware of with maven is that there are enough value-adding plugins (e.g. IDE configuration generators, static analysis tools) that maven proponents assert the value of a maven system is large enough globally to overcome the local added costs of maintaining the repository. While I will grant that there are a large number of value-adding plugins, I'm not convinced that the same value couldn't be captured with what I would wager is a simpler system substituting like ant tasks for those maven plugins.
The internal debate goes on, though I am committed to using maven for the system. At the least I will come out of this with a thorough understanding of exactly how maven will work on a large project because we are certainly destined to find out.
One other thing I have an ongoing interest in is the general problem of how to efficiently complete tasks where more than one person could do parts of the task, and in general more than one type of specialized skill must be used to complete the task.
I've been watching articles on lean engineering, agile, scrum and XP flow by for a while, and I think something between a pull-based lean system and agile/scrum models how a highly skilled team works, while introspection on the real things that drive such a system would perhaps formalize (and make more efficient) how this realistic team works. That makes a little formal thought around the ideas useful, and I just recently read a great article that does so here:
http://leansoftwareengineering.com/ksse/feature-brigade/
The idea I see there is a generalization of a "bucket brigade" work team style to any production need, and then a refocus of that style to a specific application of software feature development, mapping in the lean and agile processes where necessary to communicate the idea. It appears it might work.
One thing I'm curious about though is that it appears the work style counts on the links in a chain being fixed - e.g. this one type of skill (or skill overlap) is always needed for this stream of tasks. In reality a stream of tasks is typically much less uniform and contains individual tasks that need a variety of skills (or skill overlaps) - never quite the same set twice in a row. I'm not sure how you would handle that, or even if it is handleable in a general work flow design like that.
Perhaps for each unique set of skills you'd have a different feature brigade, and just hope that in reality there was a finite number of linkages required and that exercising them didn't result in over-utilization of a resource shared between multiple brigades? Unfortunately, this seems to match reality frequently as well. It shouldn't be too hard to reduce the multiple chains to a single slightly branching chain though and still get the inventory/capacity alarms that a kanban board will give you while maintaining flexibility around the skills required for a given task.
Either way, if there is potential to have smooth high-velocity feature development it should be examined, and this is article definitely has some ideas I'd like to incorporate.
Cheers-
-Mike
First is a general problem associated with build systems. For some reason, it appears that dependency resolution and build/package/deploy scripting always get mixed up in build systems. I'm creating one now for a large Java system and the fact is that all the available tools and styles leave me unsatisfied.
A system that is basic might include dependencies persisted into the source tree (libraries etc committed) with ant scripting. This is functional but for systems with multiple modules, like the one I'm working with, it results in either a lack of fine-grained library control, or library clashes, or library redundancies - all of which are maintenance inefficiences. At the ant level you would either end up with a large complicated ant file that is hard to maintain or you would have many sub-build files which may have redundancy
A system that is more "modern" would use maven for dependency resolution and build, but the problem as I see it is that while you eliminate the operational inefficiency associated with library placement you add a large maintenance inefficiency in that you were already using a source control system and now you have a fair bit of work to do to maintain your maven repository as well, in order to back up your dependency declarations. Further, scripting the actual compilation and packaging of your artifacts can be done in maven but is not elegant, to my eyes.
I have heard that ivy+ant can help, but as ivy is built on maven repositories to meet declared dependencies there is still the maintenance cost of maintaining a repository, and scripting the build in ant reduces the problem at minimum to the cost incurred in the basic build system.
Which all leaves me honestly feeling as though from a pure dependency resolution and artifact production perspective that the basic system with libraries in the source tree and ant scripting for artifact production is still the global optimum for build systems. That just can't be the case, can it? I'd love to hear otherwise.
The only saving grace I'm aware of with maven is that there are enough value-adding plugins (e.g. IDE configuration generators, static analysis tools) that maven proponents assert the value of a maven system is large enough globally to overcome the local added costs of maintaining the repository. While I will grant that there are a large number of value-adding plugins, I'm not convinced that the same value couldn't be captured with what I would wager is a simpler system substituting like ant tasks for those maven plugins.
The internal debate goes on, though I am committed to using maven for the system. At the least I will come out of this with a thorough understanding of exactly how maven will work on a large project because we are certainly destined to find out.
One other thing I have an ongoing interest in is the general problem of how to efficiently complete tasks where more than one person could do parts of the task, and in general more than one type of specialized skill must be used to complete the task.
I've been watching articles on lean engineering, agile, scrum and XP flow by for a while, and I think something between a pull-based lean system and agile/scrum models how a highly skilled team works, while introspection on the real things that drive such a system would perhaps formalize (and make more efficient) how this realistic team works. That makes a little formal thought around the ideas useful, and I just recently read a great article that does so here:
http://leansoftwareengineering.com/ksse/feature-brigade/
The idea I see there is a generalization of a "bucket brigade" work team style to any production need, and then a refocus of that style to a specific application of software feature development, mapping in the lean and agile processes where necessary to communicate the idea. It appears it might work.
One thing I'm curious about though is that it appears the work style counts on the links in a chain being fixed - e.g. this one type of skill (or skill overlap) is always needed for this stream of tasks. In reality a stream of tasks is typically much less uniform and contains individual tasks that need a variety of skills (or skill overlaps) - never quite the same set twice in a row. I'm not sure how you would handle that, or even if it is handleable in a general work flow design like that.
Perhaps for each unique set of skills you'd have a different feature brigade, and just hope that in reality there was a finite number of linkages required and that exercising them didn't result in over-utilization of a resource shared between multiple brigades? Unfortunately, this seems to match reality frequently as well. It shouldn't be too hard to reduce the multiple chains to a single slightly branching chain though and still get the inventory/capacity alarms that a kanban board will give you while maintaining flexibility around the skills required for a given task.
Either way, if there is potential to have smooth high-velocity feature development it should be examined, and this is article definitely has some ideas I'd like to incorporate.
Cheers-
-Mike
Wednesday, May 21, 2008
If you upgrade JDKs, don't forget the security portions
Ran into this today at work - the goal was to upgrade the JDK / JVM on our servers to a newer version with bugfixes for some issues the servers have.
We merrily got the new JDK and slowly promoted it out from dev to qa to staging and then to two servers in prod.
Naturally, there was a problem that wasn't discovered until we got to prod, but on testing other environments was present everywhere. What was the problem? there was a security exception preventing the server from accessing an https URL now over SSL.
Huh? Well, Java is very very strict about SSL / HTTPS connections, so if you try to use a Java program to connect to a server over SSL using an HTTPS URL, and that server doesn't have an SSL certificate that is signed by a CA in your JDK cacerts file, you'll have problems. The normal solution for this is to use keytool to add the CA to the JDK's cacerts file, or to make a keystore using keytool with the certificate in it.
Additionally, it is possible that the java.policy file itself has been changed to grant (or revoke) certain permissions from the JDK.
Both of these files live inside the JDK, so if you upgrade the JDK but forget to copy those files over (like we did) you're going to have some problems.
Finally, for very very old JDKs (1.3.1 and older, pity me) note that you will have other issues if you don't download the JCE and JSSE since without those, the old JDK can't do strong crypto and you'll have trouble too.
In order to discover whether you need to care about this or not, you should like at JAVA_HOME/jre/lib/ext (the JSSE and JCE files go in there) and JAVA_HOME/jre/lib/security/ to see if any files have been updated. Or you can use something like a "find . -mtime" to see what's not stock.
Good luck...
We merrily got the new JDK and slowly promoted it out from dev to qa to staging and then to two servers in prod.
Naturally, there was a problem that wasn't discovered until we got to prod, but on testing other environments was present everywhere. What was the problem? there was a security exception preventing the server from accessing an https URL now over SSL.
Huh? Well, Java is very very strict about SSL / HTTPS connections, so if you try to use a Java program to connect to a server over SSL using an HTTPS URL, and that server doesn't have an SSL certificate that is signed by a CA in your JDK cacerts file, you'll have problems. The normal solution for this is to use keytool to add the CA to the JDK's cacerts file, or to make a keystore using keytool with the certificate in it.
Additionally, it is possible that the java.policy file itself has been changed to grant (or revoke) certain permissions from the JDK.
Both of these files live inside the JDK, so if you upgrade the JDK but forget to copy those files over (like we did) you're going to have some problems.
Finally, for very very old JDKs (1.3.1 and older, pity me) note that you will have other issues if you don't download the JCE and JSSE since without those, the old JDK can't do strong crypto and you'll have trouble too.
In order to discover whether you need to care about this or not, you should like at JAVA_HOME/jre/lib/ext (the JSSE and JCE files go in there) and JAVA_HOME/jre/lib/security/ to see if any files have been updated. Or you can use something like a "find . -mtime
Good luck...
Thursday, May 15, 2008
JDK GC tuning for app servers
A quickie post here.
Lets say you get called in to review a server that's getting OutOfMemoryErrors
This is a bad thing, obviously! How do you fix it?
Well, it depends on the root cause, first of all you have to figure out what the problem is.
On old JVMs you turn on -verbose:gc and that's it, on newer ones you can turn on more details, some timestamps etc - all things that help you, but that's not the point of the post.
The point of this post is to send you over to get GCViewer from tagtraum at http://www.tagtraum.com/gcviewer-download.html
It's really the best option for visualizing what's going on.
It's not perfect though, and a trick I have to use nearly every time I'm visualizing the GC behavior in an app server via GCViewer, I have to filter the log file so it has nothing but GC lines:
cat $log | grep '\[' | grep GC > clean-gc.log
Then you fire GCViewer up and see what you've got
usually you get a line going "up and to the right" which is great for finance, but bad for GC signatures. That means you have a memory leak, or you have misconfigured your server to hold on to too many objects in caches, or to accept too many sessions that themselves have too many objects.
Sometimes you realize that you never run out of heap, but if you still get OOM errors, you are either running out of PermGen space or in rare cases are running out of operating system file handles by spawning too many threads (that error gets mapped to OOM, believe it or not)
Without GCViewer, it's difficult to clearly articulate the problem though, and also hard to see trends. Combined with how fast it is to use, I end up reaching for this particular utility every time.
Cheers
Lets say you get called in to review a server that's getting OutOfMemoryErrors
This is a bad thing, obviously! How do you fix it?
Well, it depends on the root cause, first of all you have to figure out what the problem is.
On old JVMs you turn on -verbose:gc and that's it, on newer ones you can turn on more details, some timestamps etc - all things that help you, but that's not the point of the post.
The point of this post is to send you over to get GCViewer from tagtraum at http://www.tagtraum.com/gcviewer-download.html
It's really the best option for visualizing what's going on.
It's not perfect though, and a trick I have to use nearly every time I'm visualizing the GC behavior in an app server via GCViewer, I have to filter the log file so it has nothing but GC lines:
cat $log | grep '\[' | grep GC > clean-gc.log
Then you fire GCViewer up and see what you've got
usually you get a line going "up and to the right" which is great for finance, but bad for GC signatures. That means you have a memory leak, or you have misconfigured your server to hold on to too many objects in caches, or to accept too many sessions that themselves have too many objects.
Sometimes you realize that you never run out of heap, but if you still get OOM errors, you are either running out of PermGen space or in rare cases are running out of operating system file handles by spawning too many threads (that error gets mapped to OOM, believe it or not)
Without GCViewer, it's difficult to clearly articulate the problem though, and also hard to see trends. Combined with how fast it is to use, I end up reaching for this particular utility every time.
Cheers
Monday, April 28, 2008
Installing windows on a laptop that had linux
At my office, most of the people use macs, and of the people that don't, most use windows but some use linux.
I don't really care what people use, but when someone wants a windows laptop and the only available hardware in our inventory used to have linux on it, I need to pop in the old windows installation cd and get windows installed, right?
Problem is, the windows installer CD will not install by default onto a hard disk that has linux on it.
Why not? I have no idea. I'm fine with it obliterating all the data - I want it to actually. But it will say "Setup is investigating your something or other..." then get stuck on a black screen. The installer doesn't really start.
The solution? Boot the machine with some linux install cd (or something similar that you have handy) and zero out the first part of the hard disk. The first 800MB did it for me (it did that before I could even hit ctrl-c, probably just a few MB is enough). It is not enough to just re-partition the drive without zeroing out some data. (specifically I popped a fedora core install CD into the drive, typed "linux rescue" at the boot prompt, told it to skip networking and skip finding linux installs, then at the root prompt said 'dd if=/dev/zero of=/dev/hda bs=1M', let it run for a second, then hit ctrl-c, then when the prompt came back, said 'exit' and rebooted)
After that, you can use the windows installation cd with no issues.
I don't really care what people use, but when someone wants a windows laptop and the only available hardware in our inventory used to have linux on it, I need to pop in the old windows installation cd and get windows installed, right?
Problem is, the windows installer CD will not install by default onto a hard disk that has linux on it.
Why not? I have no idea. I'm fine with it obliterating all the data - I want it to actually. But it will say "Setup is investigating your something or other..." then get stuck on a black screen. The installer doesn't really start.
The solution? Boot the machine with some linux install cd (or something similar that you have handy) and zero out the first part of the hard disk. The first 800MB did it for me (it did that before I could even hit ctrl-c, probably just a few MB is enough). It is not enough to just re-partition the drive without zeroing out some data. (specifically I popped a fedora core install CD into the drive, typed "linux rescue" at the boot prompt, told it to skip networking and skip finding linux installs, then at the root prompt said 'dd if=/dev/zero of=/dev/hda bs=1M', let it run for a second, then hit ctrl-c, then when the prompt came back, said 'exit' and rebooted)
After that, you can use the windows installation cd with no issues.
Wednesday, April 16, 2008
$PATH issues on windows
If you're busy perl-scripting on a windows machine, and you're getting unexpected behavior from the command-line utilities your shelling out to (say, 'find', or something), it may be because instead of getting the utility you think you're getting (/usr/bin/find, for example, from cygwin) you're getting something totally different (dos find, for example)
This can lead to a lot of confusion when you try to figure out why you aren't getting consistent results between systems you're working on.
Solution? Use full paths. If you want the cygwin find, say "/usr/bin/find" or you just can't be sure.
This can lead to a lot of confusion when you try to figure out why you aren't getting consistent results between systems you're working on.
Solution? Use full paths. If you want the cygwin find, say "/usr/bin/find" or you just can't be sure.
Subscribe to:
Posts (Atom)