Easiest desktop BSD distro

Polytropon freebsd at edvax.de
Wed Mar 30 22:12:28 UTC 2011

On Wed, 30 Mar 2011 13:12:23 -0400, Jerry <freebsd.user at seibercom.net> wrote:
> On Wed, 30 Mar 2011 09:32:29 -0700 (PDT)
> four.harrisons at googlemail.com <four.harrisons at googlemail.com>
> articulated:
> > Once you've scaled the learning curve, you will appreciate how easy
> > it is to achieve things with FreeBSD compared to other OS which
> > attempt to make things 'easy' for you (wireless networking springs to
> > mind - in my experience if Windows can't do it 'automagically' then
> > you haven't a hope in hell of finding out what's wrong and fixing it).
> You have conveniently left out the part that if the OS does not have
> a driver for the wireless card, specifically "N" protocol cards, then
> you haven't any hope of getting it to work, period.

Although this is correct, you're concluding the wrong
thing, in my opinion.

> In any case, the easiest way to get any wireless card to work in
> Windows, at least up to Win-7, was to deactivate the Windows wireless
> utility and use the one that accompanies the device, assuming that it
> does come with a configuration utility. I have not seen any of the top
> rated ones that did not. If for some reason that did not work, you
> could still manually enter any of the specific information manually,
> assuming that you actually took the time to learn (where did I here
> that term before) how to accomplish it.

So what are you doing, basically? You're taking the operating
system's responsibility to interact with hardware. I know there
are different approaches. One approach is to let the system
interface with hardware, usually by its kernel and the
corresponding (loadable) modules. A different approach is
to use "drivers" to do that. Those drivers traditionally
come from the same source as the hardware comes. Advantage:
The hardware vendor doesn't have to pay attention to
existing standards. He just has to made sure that his
"driver" works with the system - depending on his target
audience, this may be only one special system (version) in
particular. You furthermore suggested to explicitely BYPASS
the system's means of accessing hardware and to rely on what
the hardware vendor provided. If you haven't lost control
by the OS choice yet, you have lost it by the "driver".
If you don't care for having control about who plays foul
with your system (which you can't either notice or even
test for), also fine. Dealing with "black boxes" is what
the main target customers of the home PC area are used
to. They accept it as being normal. They don't know that
there are different ways of doing things.

And: As long as everything works as intended - no problems.
But diagnosing and SOLVING problems - the not "easy" parts
of the story - you are lost without knowledge and proper
tools, and basic skills, of course. And if something doesn't
work, the typical customer does not try to solve the problem.
If he doesn't delegate it, he buys something different and
tries again. Trial & error, if you want. And it's not even
a financial problem as such hardware costs nearly less
than nothing. The targeted customers have been trained
to "think" the following: If I invest time in getting this
working, I loose money. Instead of doing that, I invest
money into a different product which hopefully will work.

What does it imply? If the "Windows" can't bring up the
wireless network, the manufacturer has to do it using his
black box "driver". If this also doesn't work (maybe because
the "driver" is not compatible to the "Windows"), the product
gets discarded, and a new one is bought.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list