skip past navigation links
pixel

Technologists (P6 die photo) about archives notes (RSS) music vidconf.net

Technologists.com
pixel
home > tidbits
Distance Multimedia: 4 score & more

pixel
pixel

2002
pixel
(12/23) Seeking Simplifications permanent reference link
pixel
The optimism I had a couple of months ago was short lived, optimism about being ready to write a requirements document for software that would facilitate communication and collaboration amongst small groups. I've become more aware of the challenges and limitations of some of the components I hoped to "drop in". Most notably regarding LDAP, but also aspects of existing Windows applications, Jabber, and other pieces of the puzzle.
pixel
At the same time, I'm seeing new requirements and opportunities. For example, I should at least allow for the possibility that Chandler will successfully address part of the problem and look to leverage Chandler, or at least avoid duplicating what they might do. Perhaps more significantly, I'm trying to come up with a unifying access control approach that will be both secure and usable. That's not easy.
pixel
I've also allowed myself to slow down with the holiday season, and pursue some seemingly unrelated tangents. But back to the thoughts of a couple of months ago: it is time to attempt a requirements document! Beginning a document would demand a clear one sentence description. Writing a document should force much needed simplification of thoughts that are probably too ambitious. The simplifications should guide where to go next.
pixel
(12/4) Disaster Preparedness for a Small Organization permanent reference link
pixel
(With deference, but no real tie, to Frances Moore Lappé)
pixel
I target making computers more useful to organizations with minimal professional system administration (most likely, no professional system administration).
pixel
One of the worst scenarios is to become dependent on computers and suddenly not have them available! Computer disasters, small and large, are inevitable:
  • "Everybody" accidentally deletes or ruins an important file every now and then.
  • As reliable as disks have become, they still fail without notice. I've seen this happen four times recently, after a couple of years of not seeing any disk failures.
  • Portable computers get lost or stolen.
  • Fires and larger disasters happen sooner or later.
To be prepared for the inevitable, emphasize:
Redundancy

Every computer has a "hot spare" ready to take over. Besides defending against minor problems, this also means that it is relatively safe to experiment with things that might "break" any one computer.

Homogeneity

Unless there is good reason for differences, everything should be the same!

Cross-platform Heterogeneity

External (Internet) sources of problems: intrusions, viruses, etc. are unlikely to affect both Windows and Linux. So, for example, having a secondary fileserver running Linux and Samba makes it less likely that an intrusion into a primary Windows server will be a disaster.

Backups and Backup Testing!

Stop reading if you don't make backups. But only making backups can lull a false sense of security. More importantly, test those backups. I do this brutally. I take a computer I depend upon and trash it! I format the disks, and install everything from scratch. In the last couple of weeks, I've done this to the computers I depend upon the most! Since I have redundant computers, and trashed them one at a time, nothing terrible happened.

Off-site Storage for Backups

A tape in a tape-drive or a disc in a burner does little good if the computer is stolen or the building catches fire. In addition to keeping backup tapes and discs off-site, I keep the original software installation discs off-site. I make copies of the installation discs and use the copies for re-installs and maintenance. That way, I'm very confident that the off-site discs are sufficient.

pixel
(11/20) Outside/Inside Maintenance, Part I permanent reference link
pixel
I like to mow the lawn. Gardening, even weeding, can be satisfying. I like to apply preservative/stain to the deck (before or after summer!). Outside work frees me to think about things. This has been especially valuable when making major transitions, for example, when I left IBM to join Dell in 1989. (In 1989, Dell was just barely a public company. Everyone thought I was crazy. I said that Michael Dell would be comparable to Henry Ford. The people at IBM did not like hearing that, but Michael has justified my claim.)
pixel
I think I've mowed the lawn the last time this year. The chard is still producing and the Fall tomatoes are ripening. The deck is in good shape. But two different catalysts on Friday have set me about maintenance of most of the Technologists computers. First, a bad splice in an Ethernet cable in the wiring closet stopped working. I'd been sloppy and got caught. Second, stepping back from LDAP, I zoomed through a bunch of instant messaging explorations: refreshing my knowledge of "the big three" (AOL, Microsoft, Yahoo), quickly getting Jabber working on a test server, etc.
pixel
I like system administration. Doing system administration right is challenging and rewarding. The Jabber successes quickly made me think about putting Jabber into production, and I knew the servers weren't ready for that. The bad splice was also a wake-up call. So the last five days have been mostly spent on sys-admin things:
  • Testing disaster recovery by re-installing the main Linux server from the latest Red Hat 8.0 (vs. the two levels down Red Hat 7.2 that was in place) and the backups. (The primary Windows server continues to run NT4, avoiding upgrades to avoid the cost of new Win 2K and SQL Server licenses.)
  • Having succeeded (aside from minor glitches), the secondary and test servers were brought up to date. Either of these can be quickly reconfigured to take over the primary Linux or Windows server role.
  • Creating an up to date network diagram. Though Technologists is a relatively simple environment, there are four servers, four routers, half a dozen other active Ethernet devices (hubs/switches/WiFi access), four desktops and two notebooks.
  • Getting the desktops back to being as homogeneous as possible so that they can continue to be used interchangably.
  • Getting the notebooks back to being homogeneous and disposable. Not that I want to throw them out, but if a notebook gets stolen going through airport security, I don't want to think about anything but losing the hardware.
Like the work outside, the time spent on maintenance has allowed me to think more about the other things (LDAP, instant messaging, VPNs, RSS, etc.) I've been working with. Next time I expect to say a little bit more about sys-admin stuff and more than a little more about how all these things fit together.
pixel
(11/14) Small Successes and a New Course permanent reference link
pixel
I said before that I was overwhelmed by LDAP and that it fits a 90/10 rule, that most of what is there will go unused. I could repeat and amplify on all that after my last few days. This morning I was ready to give up, but somehow didn't. After plodding through a couple of tomes, a dozen LDAP "tutorials" and more utilities than I want to remember, I succeeded in getting a working directory server based on OpenLDAP, and had added a few entries to the directory. All of the books and tutorials seemed to omit key information, but the union of the tutorials got me through.
pixel
The next step was to get e-mail clients to use the directory. But I couldn't get Outlook Express to find any of the entries. The success finally came when I tried Mozilla's mail client. Then I went back to Outlook Express, figured out I needed to go to the "advanced" settings to set a parameter, and O.E. started working. Next (non-Express) Outlook, and it is working, too.
pixel
But these are small successes, and the best I can say for LDAP at the moment is that it is still probably better than the alternatives. LDAP is not focused on a "directory" in the pre-computer sense, for example, the phone book, nor is LDAP analogous to a file system "directory". LDAP is more oriented toward displacing "/etc/passwd" in *nix systems and equivalent primitives in other operating systems. I still have a ways to go before I'll use LDAP regularly myself; in particular, I need to figure out how to easily add/modify/delete entries without resorting to an "LDIF" file and the "ldapadd" command. Before I recommend LDAP to others, I need to navigate through the incomplete work on access control to figure out how a non-administrator should access/add/modify entries.
pixel
But for now I'm relieved that I got this far, can step back from LDAP, and get to the next items on my priority list.
pixel
(11/8) B.B. King & Slack Key & Back To LDAP permanent reference link
pixel
In Legendary R&B guitarist so happy to play the blues, Derek Paiva writes:
pixel
"It's not every day a Rock and Roll Hall of Fame inductee asks you to recommend a few slack-key guitarists he should have in his CD collection. But B.B. King (class of 1987) made me promise to do just that. ... "I like the sound, but ... I don't know who to listen to." ... "
pixel
Paragraphs later Derek answers "Oh, and about that promise, sir? I recommend you start your collection with CDs by Gabby Pahinui, Ray Kane, Sonny Chillingworth, Led Kaapana and Keola Beamer. But remember, that's just my opinion." That's a couple more players than my initial list, but those additions look great to me.
pixel
This article resonates with me for lots of reasons. I listen to slack key as much as any music these days. I've been a B.B. King fan since I first heard him in the mid-60's. One of my proudest moments as a musician was when my band was on the same bill with B.B. King in Houston in 1970.
pixel
Back to LDAP. I made good progress prototyping yesterday. I started reading the tome Understanding and Deploying LDAP Directory Services. I just weighed the book: 4.5 pounds.
pixel
(11/6) Truth In Naming permanent reference link
pixel
Most software is too complex. The so-called "80/20 rule" is really the 90/10 rule -- 90% of the users of a software application use less than 10% of the features. It's not just the software -- the associated protocols and data representations are comparably bloated.
pixel
Browsers, HTML and HTTP started out simple, exceptions to the 90/10 rule. Their collective lack of complexity was a catalyst to the Web/Internet explosion. Naysayers said "too simple", but the populace said "good enough". A decade later, inevitable pressure for features has taken a toll, but not noticeably in comparison to most software.
pixel
The other day I set my sights on making LDAP (Lightweight Directory Access Protocol) more usable. I've immersed myself in that pursuit and been overwhelmed. "Lightweight, my a--"! If this is lightweight, we need weightless. No wonder no one uses directory software and directories.
pixel
The "lightweight" started out as a comparision to X.500. Probably still applies. Everything is relative. Novell has been a leader in directory products, but the 90/10 rule applies. Active Directory doesn't have simplicity credibility, either.
pixel
Next step: try to prototype and subset something useful out of all of the LDAP options. As an inventory of the options, and much more, I've found Adam Williams' LDAP and OpenLDAP (on the Linux Platform) very helpful in sorting through all the options. There are 402 charts in that file, so it is not "lightweight". Though Linux-centric, it does touch on Windows software, Active Directory, and non-Linux Unix.
pixel
(10/29) It's 10 p.m. -- Have you posted your blog today? permanent reference link
pixel
You've read email today. You've probably sent email today. But if you're like most Internet users, you don't have a weblog and wouldn't distinguish a 'blog from any other web site. Irregardless, there are hundreds of thousands of active blogs and millions of blogs total. Until now, I've not called this site a "blog". I've avoided the label, but the site fits the usual definitions, especially now that I've added an "RSS feed".
pixel
Much of the focus of blogs is cultural, especially the sites with creators passionate as if their blogs were progeny. That may be overstated, but thoughts along that line prompted the "10 p.m." title. Serious blog authors update their sites multiple times per day, those who update less than daily seem compelled to defend their "at least twice a week" committment. Bloggers are passionate about what they have to say and reaching an audience with their ad hoc journalism.
pixel
(i) The labelling and the passion have a downside to the extent that blogs are treated as a category unto themselves instead of an organic part of Internet communications. (ii) Moreover, there is pervasively useful technology underlying blogs:
  • RSS feeds, used for syndication and aggregation of blogs, are probably the most widespread application of XML.
  • XML-RPC seems to have been primarily inspired by blog requirements.
  • XML-RPC and other aspects of blogs seem to have had a dramatic behind the scenes impact on Microsoft's .NET initiatives.
I'm still sorting through what all this means to enabling better Internet communication amongst small and medium-sized teams. As I better understand what is happening with Chandler, it becomes evident that they are heavily influenced by blog-oriented technologies, and probably ahead of me in thinking about this.
pixel
(10/25) One, Two, Three... A Few Dozen permanent reference link
pixel
I think I first became aware of the traditonal definition of "google" (ten to the hundredth) forty years ago when I read Gamow's One, Two, Three... Infinity. Similar to Chandler's orientation towards small and medium organizations, much of my my thinking is oriented toward software that facilitates communication and collaboration amongst groups of "one, two, three... a few dozen".
pixel
This is not just the sort of things Chandler aspires to, and not just the media breadth I referred to before (publishing, photos and video as well as interactive text), but also things such as providing directories that are simple enough for everyone to use. (That is probably not Active Directory or LDAP implementations in their current forms.) This probably DOES include "presence" in the IM sense.
pixel
I'm approaching this in a mathematically inductive sense, and think I'm almost up to two or three (users). (It works for one, maybe it works for two, so it should scale to dozens?) I'm almost ready to write a requirements document. I don't know if I will literally write one, but being able to write one is necessary. I'm also ready to do more prototyping. At the moment, making LDAP implementations more usable seems near the top of the priority list.
pixel
(10/23) Chandler and/or Conan Doyle? permanent reference link
pixel
In concluding "The Big Picture" in Mainstream Videoconferencing we wrote: "But first, we seek inspiration from Sherlock Holmes! In the early pages of "The Adventure of the Cardboard Box," Holmes and Watson are sitting in the same room. Watson believes that Holmes is not paying attention to him. After prolonged silence, Holmes tells Watson what Watson has been thinking, based on the visual clues from Holmes' observation of Watson during the silence. Predictably, Watson is amazed and Holmes represents his observations as "very superficial." Though fiction, the Holmes stories are replete with examples of the usage of all senses, particularly vision, to gain understanding. Attempts at a distance meeting with only audio seems like sensory deprivation. This is a conscious phenomenon for someone used to using videoconferencing. For others, the deprivation is no less real, but less likely to be consciously recognized."
pixel
This week, Raymond Chandler's ears are burning, thanks to the announcement of his namesake product from OSAF. I like much of what they are saying, especially today's Chandler Not Outlook Killer, After All?:
  • open source
  • targeted at small and medium organizations
  • not having "the administrative burden of Notes or Exchange"
  • "empowerment through decentralization"
I've been thinking along related lines, but more broadly regarding media (static publishing at one extreme, still images and video at the other end) yet more simplisticly (less feature depth) than Chandler. Trying to understand OSAF's plans and relate them to my own meanderings brought me back to Holmes and "The Adventure of the Cardboard Box".
pixel
More next time.
pixel
(10/18) Public WiFi Privacy, Part II permanent reference link
pixel
Part I set the stage for discussing the state of VPNs. This is both highly relevant and of broader interest, so please forgive me if I lose a little focus. VPNs are relatively mature, increasingly common, and sufficiently confusing that there is still room for new technology to make VPNs more useable and more secure. There are at least four approaches to encryption-based VPNs. (To me, private networks without encryption are not VPNs, but others would count things like MPLS, which I tend to ignore, as VPNs.)
1. IPsec
IPsec seems to dominate current thinking. IPsec is the most comprehensive, the most widely implemented, but also dauntingly complex. Unless something changes dramatically, IPsec will never be something for ordinary users without administrative assistance.
2. SSH/OpenSSH
SSH is a good option, and has plenty of advocates, but will probably remain in the province of the "tech-nerds" and those with administrative assistance -- it seems unlikely that SSH will become pervasively useable. In the short term, I suspect that SSH will be my best option for "Public WiFi Privacy", but I need to do more testing before I'm sure about that.
3. PPTP
The original, "legacy-Windows" versions of PPTP were both insecure and unstable. Starting with Windows 2000, PPTP seems stable, is relatively easy to configure and is relatively secure if you disable the legacy options. However, at least one public access environment that I've visited seems to block the ports needed by PPTP, and robust support for non-Windows platforms seems unlikely. (There are non-Windows implementations out there, so I'll hedge and say that PPTP might be the best option. But even Microsoft seems to think otherwise.)
4. TLS/SSL
There is lots of activity in this area. I prototyped some code for my own implementation of TLS-based remote access last year, and keep thinking I'll implement a robust version myself. If I do, it means I've reaffirmed my enthusiasm for this approach.

pixel
(10/17) Public WiFi Privacy, Part I permanent reference link
pixel
Privacy in Public?
  • An oxymoron? Yes
  • Achieveable via encryption? Yes
  • Practical? Not yet
For WiFi privacy at home, I've done the simple things:
  1. Access point antenna located to minimize off-premises signal.
  2. Set non-default SSID
  3. Turned off SSID broadcast
  4. Filter out unknown MACs
  5. Turned on WEP
Someone with a good enough antenna and the right software on their notebook could defeat all that, but I don't lose sleep over this possibility (especially since I have better measures in sight).
pixel
At an airport, or a Schlotzsky's, or a client's office, none of the simple measures help: 1 through 4 contradict the intent of public access, and impracticality of key distribution eliminates WEP. There are other options:
  • VPN based on PPTP, IPsec, TLS/SSL or SSH.
  • Application level encryption, email being the first candidate.
  • Wait for something better than WEP to get deployed.
Of these, only a VPN approach seems close to practical now. "Close to" because there are plenty of challenges with VPNs. But even those arguing against VPNs for WiFi security (for example, see David Berlind) seem to accept VPNs as the right answer for public access.
pixel
More on VPN approaches in Part II.
pixel
(10/16) Lull in PDA Phone market? permanent reference link

My Samsung I300 has pleased me since I got it in February. This has been my first PDA -- I'd waited until I could get Internet connectivity without a big monthly fee. I mostly use it as a phone, but having a browser, email, VNC, and an SSH client in my pocket is very appealing. I've even started to use traditional PDA apps!

However, the I300 seems to have gone out of production, as have many of the competing products. Checking out the wireless carriers' sites this week, I found no PDA phones at all at AT&T and Cingular, one Pocket PC phone at Verizon, one each of Pocket PC and PalmOS at SprintPCS, and three (RIM/PocketPC/Sidekick) at T-Mobile.

A couple of conclusions:
  1. Pocket PC phones are still way too expensive, but will become more popular as prices drop.
  2. 16 bit PalmOS phones are history, but ARM-based PalmOS phones may still compete when they become available.

pixel
(10/15) Aloha! Changes are afoot: permanent reference link
  • hotlists has been reorganized.
  • A music section has begun, starting with my favorite Hawaiian music.
More to come!
pixel

  Security: Stop ignoring the obvious mistakes (ZDNet 9-19)
  Navigating the Embedded Java Maze (SD Times 9-15)
  10 choices that were critical to the Net's success (SiliconValley.com 9-8)
  Remembering Vignette (Scripting News 9-3)
  What PDA/phone can pass the test? (ZDNet 8-15)
  Tech's 'dirty little secret'--cybersecurity (ZDNet 8-14)
  Minding Your Language (SDTimes 8-1)
  XML security: A who's who (ZDNet 7-8)
  Hot Spots for WISPs (ZDNet 6-28)
  Tempest in a coffee pot (ZDNet 6-26)
  Watch this airspace (Economist 6-20)
  Getting Started with C# On Linux (C# Help 6-10)
  Campus WLAN Design (Network Computing 5-13)
  P2P Makes a Corporate Play (ZDNet 5-7)
  .NET: Microsoft's Enterprise Ticket? (ESJ 5-2)
  Just How Trusty Is Truste? (Wired 4-9)
  Apple Ties the Wireless Knot — Again (DDJ 4-6)
  IBM's unfolding power play (ZDNet 4-3)
  Dan Bricklin review of Handspring Treo 180 (found on useit.com 3-24)
  Sun blinded by paranoia (Financial Times 3-13)
  AT&T Privacy Bird (2-22)
  Grid Project to Wed Web Services (NY Times 2-19)
  Videoconferencing Snapshot (CHS 1-30)
  Understanding the value of Web services (ZDNet 1-28)
  Shadow initiatives: .Net and Java (ZDNet 1-24)
  10 things Google has found to be true (Google Corporate Information)
  Open source, standards and Windows (ZDNet 1-22)
  The MIT Lightweight Languages Workshop (Dr. Dobb's Journal, February)

pixel

pixel
pixel


Back to Top

Copyright © 1995-2018 Charles H. Sauer. All rights reserved.

pixel