Day: October 11, 2003

  • Rendezvous Snapshot

    Here is a snapshot of the Rendezvous discoverable sites and servers during the afternoon.

    There are a lot of default Powerbook G4’s with Apache displaying the default page.

    Of course there are many other rendezvous discoverable services that I do not have access to because I am running the wrong operating system (Windows).

    Windows really needs tighter Rendezvous integration.  Things like finding local devices, printers, and music could be so much easier if Rendezvous was integrated into the OS.

    I already poked Scoble about it via IRC.

    I didn’t recognize Doc Searls passed out in the back of the room last night.  It was late.  My body was still on East Coast time.

  • AMD Opteron/Athlon XP/Athlon FX Presentation

    Rich Brunner at AMD is giving a quick talk on AMD 64 bit architecture.  They’re going to demo the new SuSe running on AMD 64.

    Of course, AMD’s x86-64 works in compatability mode for full 32 bit and also long mode, either in mixed 32/64 bit or pure 64 bit flavours.  They just extended the 32 bit space by adding another 32 bits to integer registers, as well as adding on to the SSE registers and GPR registers.

    They’re going to demo a dual proc 64 bit system with 8 gigs of memory.  The default data size is still 32 bits while allowing you to address 64 bits of memory.  Code bloat for x86-64 is about 20% more than x86.  Not bad.    Default data size helps that.  The added just two new instructions.

    The adoption curve will look like this:

    • First OSes get ported over and are adopted.  Now SuSe works, WinXP soon, etc.
    • Apps will be 32 bit for awhile, but will eventually be ported to 64 bit and will be purchased/upgraded when they require replacing.
    • Many apps will remain 32 bit for quite some time, so 32 bit performance is important.

    Hammer == K8 == core that’s in an AMD Opteron, AMD Athlon64 and AMD Athlon 64 FX.  Got it?

    AMD64 == x86-64.  Athlon’s marketing department likes AMD64 better.  I like x86-64 myself.

    Hypertransport is important for speed increases.  Memory controller is run at processor clock frequencies.  The latency to memory is reduced significantly.

    HyperTransport rules.  It removes bottlenecks between processor and memory.  This is good.  Right now it’s clocked at 800MHz, but that will ramp up and increase throughput with it.  Hypertransport is point to point.  Legacy south bridge, PCI-X 1.0, and eventually a PCI-X 2.0 tunnel.  Supports a 2GB/s (8x) AGP interface.  PCI-Express.

    Hypertransport scales quite well to mutliprocessor systems.  With HT, as you add processors, you add memory to hang off them.  Each processor has access to their own memory.  As far as they’re concerned, memory is globally addressable.  Each processor gets three HT links, so it can link to two other processors and an IO bridge, or whatever is neccesary.

     

  • Bluetooth Security

    Be afraid.  It’s easier for your phone to get owned than you think.  I’m listening to some Shmoo gurus on Bluetooth discovery.

    Finding a device

    • send out inquiry, who’s out there?
    • devices report back in, “Hey, I’m here”
      • you can set your device to be undiscoverable
      • you need to find a specifi MAC address to send a connection request to
      • it’s good for security but a pain in the butt for usability

    Bluetooth is spread out throught the spectrum.  To find a device, you have to hop around the spectrum sending out requests and waiting for responses.

    Pairing

    • first steps of bluetooth security.  It only happens once.
    • Shared secret (PIN) on both sides
    • PIN search space pretty small (4 digits), manufacturer defaults are usually pretty insecure (0000).
    • If you can intercept pairing transaction, you’re golden.  You can then brute force crack a small set of keys, one of which will work.
    • You can do authentication on a little bit or a lot of your communication.  It’s pretty flexible.
    • Why is security always optional?

    Defaults

    • Manufacturer defaults are stupid and insecure

    Profiles

    • Good for interop
    • For a specific device, talk like this.
    • Anyone can create a bluetooth profile.  Differences between Hands free and headset profile kill interop.

    Embedded Devices

    • if you use too many resources on an embedded device, it’ll bork out and you’ll have to reboot (aka 3650)
    • It’s great for tracking, and that could be good or bad, depending on how you look at it.
    • Tracking executives.  All the VP’s head into a conference room at a weird time, who’s cheating on whom in the office, etc

    Finding Undiscoverable Devices

    • Redfang: Older but the pioneer of the idea.
    • Fine Tooth Comb (bluesniff): brute force scan, low hanging fruit (discoverable) and the app itself is discoverable but not connectable, and snags you when you try to browse it.
  • Social Software

    A little online note taking.

    What is social software?

  • Foo Camp Links: Saturday

    I’ll be collecting links gathered during the various talks/sessions here:

  • Rendezvous at Camp Foo

    There is a good collection of people listening to a talk on Rendezvous.  It was nice to see a somewhat mid-level discussion of it, and it looks like we’re about to dive a little deeper.

    Links:

    • Zeroconf on the spack.org wiki is a good list of sites.
    • Howl by Swampwolf gives you a Rendezvous browser in IE.  There are lots of default apache installs on Powerbooks and Linux laptops here.
    • Zeroconf.org has some more details.
    • Apple ships an open source Rendezvous implemetation that works on Darwin, OS 9, OS X, Windows, and others.
    • zeroconf.sourceforge.net has zcip, which is another partial open source implementation of Rendezvous/Zeroconf that allows you to obtain an IP address.
    • Rendezvous under OS X from Apple.com
  • Foo

    I am here.