Wednesday September 26, 2007 Keith Bierman's Weblog
Keith Bierman's Weblog
Wednesday September 26, 2007 Since Gartner's silly pronouncement the pundits are in play. The silliest bit I've seen yet is this gem: litigious process than, say, porting from Solaris to AIX. As if porting from one Standards compliant (and Unix certified) system to another would require any litigation. And this guy thinks he's defending Unix against Linux.
Tuesday August 28, 2007 My current (and past to be candid) laptop of choice is a Mac. Laptops being easily stolen, an encryption technology like Apple's FileVault really is a must. But what happens when Something Bad(tm) happens during shutdown? Well, the image can become corrupt and then opening it is... well impossible.
Or so everyone told me. Google helped a bit., if I had kept backups of the * sparse image itself, I might have been able to use this technique.
Not being one to give up easily, I copied the sparse image to another machine and started experimenting. having had good results from DataRescue in the past, I tried it. But as their support organization confirmed, they do can do nothignng for sparse images.
Diskwarrior could, but not so much with the version I had. So time to upgrade. Much to my annoyance, in the laptop itself the application bailed with a numeric error message. However, working on the desktop copy it ran flawlessly and restored the sparse image. It was then a simple matter to delete the version on the laptop and copy it over.
Several lessons:
- Always make sure there is a second account on the laptop (good hygene suggests making it be the adminstrative account. But at least having a second account ensures a way forward ;>).
- Backups of course; but there's almost always some window of vulenerability where the backup isn't current. So keep current on your restoration/hacking options ;> Alsoft only offered the upgrade via CD, so by not having updated aggressively I cost myself a week of data outage.
- Things which aren't really secret, put them in the /Users/Shared area. That way they don't take up space in the sparse image, and are there post data disaster.
I still enjoy the strange looks I get running Solaris in full screen mode in coffee shops (via VMware's Fusion). Of course that requires an Intel based Mac.
Thursday August 09, 2007 Commuting between Linux and Solaris?
Often I find myself switching back and forth between systems, for a variety of reasons. While one certainly could use blastwave (or equivalent) to equip the systems identically, there's a couple of things which work just fine with some simple "mapping".
For example, if I've assigned myself the "Primary Administrator" role in my Solaris installation, there's no need for sudo. But it gets tiresome to retrain my fingers sometimes, so
alias sudo="pfexec"
does the trick. Similarly for prstat (alias to top).
Friday November 03, 2006 Ever wonder if your HVAC system was installed correctly?
Often they aren't (hence short lived components, great variability in longevity from installation to installation, etc.).
If you have a Bryant Evolution Thermostat (or it's identical twin with the Carrier badge) you can get some useful measurements pretty easily. One of the key "figures of merit" for such a system is the "static pressure" essentially how well does air flow through the system (the lower the number the better, less "friction". Numbers larger than 1 are very bad).
If you have one of the current Evolution Thermostats, open up the panel and locate the button marked "Advanced" for a very, very long time. It will eventually come up with a screen you probably have never seen.
If you select "setup" you can "reinstall" the system, which includes a calibration run (this takes several minutes, as first it polls all the devices in the network, and then finally gets to work). You will have to verify the various devices (typically just say yes, but if the installer accidentally left you with some devices unconfigured or configured ones you don't have, make the necessary adjustments). Eventually it will do the calibration run, which only takes a minute or three.
It will report the static pressure in "inches of water" (you'd have to ask someone else why that's the unit of measure). 0 is impossible, about .5 is good and if you have some of the fancier filters you may well see .8 or .9. If you get a higher result, try again after removing the filter media (you could have a clogged filter). If it's still high, you probably have a problem in the ducting, especially near the furnance.
With modern multi-stage equipment, the peak value (which the installation/setup program is discovering) is only part of the story. The other bit, is what's happening at any given point in time. The "Advance" menu let's you see the ongoing static pressure, speed, various critical temps (see the "Service" menu).
Needless to say these options aren't covered in the version of the manual they hand out to homeowners.
So if you have an Evolution or an Infinity thermostat give it whirl. Let me know what you're results are. If I get enough data, I'll post a table.
Should have posted this back in September, but was too caught up in stuff.
I'm back.
Thursday August 03, 2006 Departing SMI At least for a time. Assuming that my blog access eventually ceases, future posts may be found at: http://khbkhb.blogspot.com/ (2006-08-03 11:31:35.0) Permalink Comments [3]
Friday February 17, 2006 Linux on UltraSPARC T: That didn't take long at all! See this for details.rel="tag">NiagaraCMT
(2006-02-17 11:09:15.0) Permalink
Wednesday January 25, 2006
Porting OS to SPARC (e.g. Linux, BSD, etc.) In the old days, it was a bit of Black Art, mostly restricted to people at Sun or people who knew which bar stools to sit on (so they could ask questions of the RightPeople off the record ;>).
It's just gotten a lot easier. For formal documents for theUltraSPARC T1
As for where to ask those questions, there's the formal forum
Not that I'd discourage anyone from buying the appropriate lads and lassies a good drink to pick their brains, but it'll be a lot more helpful if the questions (for any OS port) start out on the OpenSPARC site. That way, one answer will go to a lot of people ;>
Thursday January 12, 2006
I like Coffee, I like Tea.... Enough people have asked me about some of our beverage options at Hacendia Bierman, that I thought I'd record our usual recommendations here. It's nontechnical, other than the frequent association of caffine with programming ;>. I have no finanical stake in any of these providers ... other than hoping they stick around because I like their stuff.
For green beans and supplies, I rather like Sweet Maria's. Good prices, good service and good products. We have an Alpenroast drum roaster. Given that my wife really likes light roasts and I prefer dark roasts we might have been better off with two smaller roasters. But it's a good roaster and a lot of fun. I haven't managed to reproduce Peet's Mocha-Java :<
For brewing, we have several systems. The one we use the most is the fully automatic expresso machine, an older Saeco Magic Delux.
For tea, our favorite oriential tea shop is in Mountain View California. The nice thing about using real tea leaf (rather than chopped up dust in bags) is both taste and reuse (typically I get 5-8 pots out of one batch of leaves). The folks at MVTV import directly from plaintation .. so there's very good consistency and pricing. Really nice tea isn't cheap, but it's worth every penny.
(2006-01-12 12:23:30.0)
Permalink
slashdot on Linux Stability I found this to be an interesting read. (2006-01-12 11:45:58.0) Permalink
New SPARC architecture documents Are on the way. See this thread on the OpenSPARC site.
Wednesday January 11, 2006
What license should OpenSPARC employ?
The discussion has just begun over on the OpenSPARC site
[ T: OpenSPARC ]
(2006-01-11 01:37:20.0) Permalink
Thursday January 05, 2006
An old classic...available online! It's been so long since I read CAR Hoare's CSP tome that I'd completely forgotten about it, until I spotted a reference in an archived email that I'd completely missed.
For those interested in formal reasoning about some special kinds of parallel processing, CSP is probably worth revisiting (if you are old enough to remember when it was published) or worth a read for the first time if you are young enough to have missed it ;>
(2006-01-05 11:32:03.0)
Permalink
Monday January 02, 2006
Why worry about my workload?
The folks at Anandtech have again proved that they understand a lot more than just desktop games. The article is worth a close read. There's a handy table comparing the IPC (instructions per cycle) of several famous "standard" benchmarks.
Understanding how the workload you have (or expect to have) relates to standard benchmarks is vital if one is to have any hope of having benchmark performance reflect what you will see down the road ;>
href="http://technorati.com/tag/NiagaraCMT"
(2006-01-02 15:22:39.0)
Permalink
Thursday December 15, 2005
Language Standardization considered harmful?
Les Hatton makes a reasonable argument for it.
....This is exacerbated by the process of language standardisation. We would all agree that standardisation is an important step forward in engineering maturity, however, if the
process of standardisation ignores historical lessons, then this may well be worse than useless. Language standardisation suffers from two important drawbacks as practised today. First of all, language committees (and I’ve sat on a few in my time), have an irresistible temptation to fiddle. They will persist in adding features which seem
like a good idea at the time, without any notion as to whether they will work or not. Of course, this is normal in engineering. It is similar to the role of mutation in Darwinian evolution. What is not normal however is the second drawback. This embodies the opposing principle to control process feedback. It is called “backwards compatibility” and is often expressed in the hallowed rule that “thou shalt not break old code”. So drawback one guarantees the continual injection of features which may or may not work, (most don’t) and drawback two guarantees that you can’t take them out again. In other words it is a technique whereby learning from previous mistakes is guaranteed not to take place. In backwards compatibility, you take as a starting point all the failure modes which have occurred so far and then add new and poorly understood failure modes. We call the result a modern programming language. If other engineering disciplines pursued this doctrine, hammers for example would have micro-processor controlled ejection mechanisms to cause the head to fly off randomly every few minutes as they used to about 40 years ago when made with wooden handles. Not surprisingly, they were redesigned fairly quickly.
The longtime reader (all three of you) may recognize some resonance to my comments to Bill Moffitt in a previous entry. I think that the rule about not breaking existing code is a must; but that the consequence is that (as I described to Bill in the case of Fortran) that the model for language evolution ought to be more like Algol (begat C, begat C++ begat Java) not that the old language necessarily dies ... but that the Standards group should restrict itself to a revision or two with new substantive features and then restrict themselves to cannonization of existing practice and harmonization of feature sets (or bindings to other things, etc.). The creative energy of the language's supporters should go into the "next language" which will be free to discard the bits of the original language found to be errors in practice.process of standardisation ignores historical lessons, then this may well be worse than useless. Language standardisation suffers from two important drawbacks as practised today. First of all, language committees (and I’ve sat on a few in my time), have an irresistible temptation to fiddle. They will persist in adding features which seem
like a good idea at the time, without any notion as to whether they will work or not. Of course, this is normal in engineering. It is similar to the role of mutation in Darwinian evolution. What is not normal however is the second drawback. This embodies the opposing principle to control process feedback. It is called “backwards compatibility” and is often expressed in the hallowed rule that “thou shalt not break old code”. So drawback one guarantees the continual injection of features which may or may not work, (most don’t) and drawback two guarantees that you can’t take them out again. In other words it is a technique whereby learning from previous mistakes is guaranteed not to take place. In backwards compatibility, you take as a starting point all the failure modes which have occurred so far and then add new and poorly understood failure modes. We call the result a modern programming language. If other engineering disciplines pursued this doctrine, hammers for example would have micro-processor controlled ejection mechanisms to cause the head to fly off randomly every few minutes as they used to about 40 years ago when made with wooden handles. Not surprisingly, they were redesigned fairly quickly.
(2005-12-15 15:39:39.0) Permalink Comments [3]
Calendar
| « November 2009 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | |||||
| Today | ||||||
RSS Feeds
All
/General
/Java
/Music
Search
Links
Navigation
Referers
Today's Page Hits: 155