Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jan 2015 19:00:00 +0100
From:      Polytropon <freebsd@edvax.de>
To:        Christian Baer <christian.baer@uni-dortmund.de>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: FreeBSD with Win7 and UEFI
Message-ID:  <20150104190000.c2cb035e.freebsd@edvax.de>
In-Reply-To: <3064826.yDtrE01ODY@falbala.rz1.convenimus.net>
References:  <m7hfff$hno$1@ger.gmane.org> <20141226072950.GB13694@kontrol.kode5.net> <m7p8r5$jiv$1@ger.gmane.org> <alpine.BSF.2.11.1412281227150.86113@wonkity.com> <m7uerq$nlm$1@ger.gmane.org> <20141231044849.ebf531c1.freebsd@edvax.de> <3064826.yDtrE01ODY@falbala.rz1.convenimus.net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 04 Jan 2015 18:25:04 +0100, Christian Baer wrote:
> Polytropon wrote:
> 
> >> Yes, I've read about that and the fact that it has been quite hard. This
> >> actually did surprise me a bit, considering that UEFI has been around
> >> for a while now.
> > 
> > AS/400 is around since the 1980's, and still I can't find
> > a Linux or BSD that will run on it. ;-)
> 
> There is no support for VAX either and that has been around even longer. :-P

There's SimH and FreeVMS, that should be enough
for everyone. And IBM /360 is around even _much_
longer, and still... oh wait, I can run Linux
on /z now! :-)



> In Germany we'd say, this comparison is limping, because although quite 
> entertaining, it doesn't quite get the essence of the problem. Meaning: 
> While FreeBSD does not target AS/400, VAX or any PDP (just to get really 
> ancient here :-)) architecture, it is aimed at modern PCs like AMD64, Intel-
> i or in my case Intel XEON based. Supporting UEFI is therefore a necessity 
> since BIOS will probably die out sooner or later.

I truly understand that problem, and I'm curious
about upcoming solutions when UEFI starts getting
all messed up and incompatible. Remember that in
most cases, when some technology has been fully
supported, it was quickly obsoleted by something
different, and this applies for hardware, firmware,
and sofware (think of APM, HAL, and so on).



> Relax, I don't want to argue this through now and I understand your comment 
> was meant as a joke. I just wanted to point out that UEFI is something we 
> are going to have to deal with, whether we like it or not.

I fully agree. In order to stay relevant, this
will have to be supported. I also think that adding
FreeBSD support for ARM is a move into the right
direction.

Just as a sidenote:

http://www.alexrad.me/discourse/why-rosyna-cant-take-a-movie-screenshot.html

It's worth having options so this doesn't happen
to FreeBSD users.



> The usual problem of missing specs and documentation. I think this problem 
> has been around since the rise of open source software and probably before 
> that. OS/2 suffered from missing hardware support for similar reasons.

IBM could have open-sourced OS/2 and _maybe_ had
a chance for a revival, but they missed that too.
And: eComStation isn't much more than OS/2 on
artificial life support... :-)



> I'm not sure when this arose though. I remember the documentation of my 
> Epson EX-800 was rather lousy (as in noone really wanted to write that 
> document and the result was what the customer go anyway), but it was enough 
> for me to write a well working driver for my C=64.

In the past, documentation was an essential part
of most computer products. Especially for peri-
pherial devices such as printers or modems, it
was much more than a "set-up cheat sheet". Even
today I'm happy to have them _as paper_ for the
few occassions I have to write custom software
for very special printers, dealing with much
more special kinds of documents. Being able to
know how to make the printer do what I want is
a requirement, solved by good documentation.

Providing documentation was a valid selling point.

Today you'd probably say: There's the Internet,
all the stuff is on the web! But especially the
low-level stuff is considered a trade secret,
not something developers (or users) should have
access to.



> When did the manufacturers start making a secret of everything?

Since it paid, because people stopped caring. Keep
in mind that creating documentation adds costs to
the final product, and whenever 1/2 cent can be
spared, it will, especially when you omit something
that "nobody ever" is interested in.



> Is boot0 the prefered way to go? Or are there other tools I should take a 
> look at?

Yes, I'd say so. See "man boot0cfg" and also have a
look at "man gpart" on how to install it (except you
want to use fdisk, which should still work).



> At work I sit at a Linux machine and really don't miss Windows at all. The 
> only time when I think Windows could do something better is when I try to do 
> something non-standard. Those things usually work pretty easily under 
> Windows.

This is where you can see the tight cooperation of
the manufacturers of hardware and software with the
MICROS~1 corporation. The newer something is, the
better it tends to work. But don't try to use working
hardware that's now considered "too old"... ;-)



> I will be spending most of my time under FreeBSD anyway. For gaming however, 
> I have to boot Windows. :-)

This is a situation which will also change in the
future, as several game makers have already been
expressing their frustration about today's "Windows"
versions. There seems to be a (slow!) shift towards
Linux as a gaming platform. It's probably to early
to say that it's a "1st class citizen", but maybe
this will happen when there's enough money in it.



> > This is the typical limitation by UEFI. If you can use
> > FreeBSD's boot manager, a default will be available which
> > will boot the desired FreeBSD if no action is taken at
> > system startup. But as far as I understand, this will
> > require MBR partitioning in combination with UEFI...
> 
> I hope this also works for the combo BIOS/MBR.

The _traditional_ concept involves BIOS and MBR, and
I've been using that in the past successfully. The
FreeBSD "system" will be accessed first, the boot manager
will select how to continue, and it can be set to a
default (or "last choice") and configured with a
timeout.




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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20150104190000.c2cb035e.freebsd>