Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 May 2002 17:27:00 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Brad Knowles <brad.knowles@skynet.be>
Cc:        Giorgos Keramidas <keramida@ceid.upatras.gr>, Miguel Mendez <flynn@energyhq.homeip.net>, freebsd-chat@FreeBSD.ORG
Subject:   Re: The road ahead?
Message-ID:  <3CE6F154.989966DD@mindspring.com>
References:  <20020516004909.A9808@daemon.tisys.org>	 <20020516151801.A47974@energyhq.homeip.net>	 <20020516172853.A7750@daemon.tisys.org>	 <3CE40759.7C584101@mindspring.com>	 <20020516220616.A51305@energyhq.homeip.net>	 <3CE43D08.1FDBF0A3@mindspring.com>	 <20020517163624.GB9697@hades.hell.gr>	 <3CE58F73.1A7F50AF@mindspring.com> <p05111717b90b4c01f392@[10.9.8.215]> <3CE5B62B.2B26239B@mindspring.com> <p0511171bb90c8693adb1@[10.9.8.215]>

next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote:
>         No, you don't.  Just plug it in, and it works.  That's the ideal.

I need an example.

How about a shared library, which contains process attach/detach code
(.init/.fini for constructors/destructors for statically declared
classes), but not having support for thread attach/detach functions
(FreeBSD still lacks this)?

(De)Activation is seperate from (de)installation.


> >                                                     There's really
> >  no choice.  Overloading the same button to turn it off is just
> >  convenience -- you'd need a button to turn things off, even if you
> >  used the availability of electricity to turn the thing on, since
> >  even if engagement is automatic, you need to explicitly disengage.
> 
>         Again, I disagree.  If you want to turn it off, you can use the
> software.  If the software doesn't work, you can unplug it.

And if the software *does* work... 8-)... how do I turn it back
on?

One of the interesting problems with the InterJet was the LCD bezel
light.  It didn't have a "sleep mode" that turned off the light.

The other problem was the blinky lights for network activity, etc..

If it's really an appliance, like a fax machine, then it needs to be
obviously idle when it comes time to close the office at the end of
the business day.

There's a really simple equation here:

	"Lights blinking" == "Costing me money"

Go to 5 small businesses.  Watch them shut down their office at
night, and open it in the morning.  Take copius notes.

Now ask them about the difference between the things they power
off and the things they don't power off.  Ask them specifically
why they shut off the laser printers, but not the fax machine or
the telephone (hint: telephones are "off" because they have an
obvious "switch" that's default in the "off" position).  As them
about the ringer on the phone (most offices, this "turns off"
automatically, when the phone system goes into "night mode"),
and then observe what they do with the copy machine -- do they
turn it off, or do they trust the "power save mode"?  With 5
offices, you should see some variety in theis last one.  Classify
the difference in the machines that get turned off vs. those that
don't: the copy machine is good, because depending on the machine,
you'll get different answers.

One real problem we had with InterJets was that people would
actually turn them off every night before leaving the office.  It
was because of the lights.


> >  My favorite example is the Western European road-side-assistance
> >  kiosks: One big yellow button that meant "fullfill your purpose".
> 
>         I've only seen those in the Netherlands, and even then only in
> some parts.  And that's only because the device is already plugged in
> and ready to go.

Plugging something in doesn't feel like doing something to activate
it.  It's different.  Yes, the kiosks are "plugged in".  But they
aren't "on" -- where "on := active" -- until you press the button.

If nothing else, humans like control.  8-).


> >  Celestix.
> >
> >  http://www.zdnet.com/supercenter/stories/review/0,12070,478772,00.html
> >
> >  The thing runs Linux, by default.
> 
>         The device itself seems fine to me, but I want something that
> natively runs BSD.  If I was to seriously look at buying a Celestix,
> then I might as well buy a Qube instead.

One of the first things we always did in engineering at Whistle
was, as soon as we got our hands on the competitor's hardware,
if the thing was Intel-based, "turn it into an InterJet".

Mostly this was our comment on engineering's inability to understand
why we couldn't do really cheap (commodity level pricing) hardware
for the InterJet.  InterJets, even after the IBM scaling COGS, were
relatively much more expensive than comparable routers or other
edge of network equipment.

I guess it just pissed us off that we could buy a competitors product,
load our software on it, and come out with something that could still
make a profit, and was cheaper than an InterJet for someone to buy.


> >  But as I said before: I think they missed the boat with the
> >  design, since they are just copying the InterJet (IMO), and
> >  the InterJet missed the boat, too.
> 
>         For other people, the interface may not be ideal.  But for me, it
> would be good.  My problem is that I want to buy a device like this,
> but that runs FreeBSD.
> 
>         I don't want to buy a machine and then try to retro-fit FreeBSD
> onto it, because it is likely that they have included some
> proprietary hardware (e.g., an LCD display) that is not supported by
> FreeBSD, and I may not be able to get it to work at all.

Linux: demand the source code.  Most likely, they are using one
of the LCDs referenced at "linux1u" anyway (serial or parallel
commodity LCY; my bet would be on serial).


>         If I'm going to be forced to go the retro-fit route anyway, then
> I might as well buy a Qube.

Have fun porting to MIPS.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE6F154.989966DD>