why BSDs got no love
Jan Husar
--
-----------------------------------
| Jan Husar
|
| doing what matters
| http://tinyurl.com/ya4xlqe
Earthcause - in the cause of the Planet
#1 Mission to Kosovo (2009, 2010)
#2 Mission to Cambodia (2010)
#3 Mission to Galapagos (planning)
Peer Schaefer
1st: PCBSD has a graphical installer. But I don't think a graphical
installer is needed. An installer with a curses-like menu-driven
interface is sufficient for most techy users (and face it: aunt Jamie is
not the target audience for *BSD). But I admit that some menus of the
*BSD installers are a little bit cryptic. The installer also lacks a
good help facility. Perhaps it needs a little polishing.
2nd: The lack of a live CD is a real problem. A live CD is crucial for
testing hardware compatibility and for data rescue (accessing a UFS
formatted BSD-slice from a Linux live CD should be theoretically
possible, but I never got it working).
3rd: *BSD is a great server OS. It tried to switch my desktop machine
too, but in the end two problems blocked that: (a) Automounting USB
media never worked really good. (b) I have large amount of data on
ext2/ext3 formatted media. I can't convert them online to UFS, and I
never got the ext2/ext3 fs-driver for *BSD to correct work.
Conclusion: A graphical installer is a nice add-on, but no must-have. An
curses-like interface is ok. But perhaps the installer needs some
polishing. The lack of a live CD is a real problem. And for desktop
usage *BSD needs working automounting and a good ext2/ext3 driver.
Best wishes,
--Peer
Am Dienstag, den 15.12.2009, 16:33 +0100 schrieb Jan Husar:
> http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
>
Dag-Erling Smørgrav
> 2. There is a live CD.
> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/8.0/8.0-RELEASE-i386-livefs.iso
That's a misnomer. For all practical purposes, there is no difference
between livefs and disc1 except for the lack of packages. When people
download something called a "live CD", they expect a CD that will boot a
fully functional desktop, with an option to run the installer.
DES
--
Dag-Erling Smørgrav - d...@des.no
Karel Miklav
> http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
Why a box is not an apple and how would we make a box look like an
apple? That is a question! Because if we could turn all the boxes into
apples, oh boy, how many apples would we have! Where all those apples
would be stored in the world without boxes nobody knows, but let's just
concentrate on doing one step at the time.
Seriously, power consumers get enough confirmation from the salespeople
and popular media, they should not be covered here. Or is there a need
for positioning work regarding our project?
--
Regards,
Karel Miklav
Charlie Kester
>http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
Others have pointed out that PC-BSD meets the need expressed in this
article.
As for FreeBSD itself, the question must be asked: do we WANT to get
more love from people who judge an OS by whether or not it has a
graphical installer?
Shane Calimlim
I can practically install FreeBSD blindfolded on the current one, but only
because I've done it so many times. The first few attempts were extremely
frustrating; the menu flow in the current installer makes little sense --
especially if something goes wrong. Please keep that in mind, everyone on
this list knows the installer like the back of their hand, but do you
remember the first time(s) you used it? Know a fairly seasoned linux user
that has never used FreeBSD? Sit them down at a machine and watch them try
to install it.
First impressions are important! I won't go into the gui vs non-gui
installer debate, but making the install process as slick as possible is
definitely a good thing.
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
> To unsubscribe, send any mail to "freebsd-advoca...@freebsd.org
> "
>
Chad Perrin
> http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
By the way . . . as another writer at TechRepublic, I've written another
article that responds substantially to what Jack Wallen said about the
various BSD Unix systems in his article, "Why the BSDs get no love". My
article has been submitted to the editor, and I believe it is slated to
be auto-published next week while most (if not all) of the TR staff is
off for the holidays under the title "Why security gets no love".
While the actual core topic of the article is the deplorable lack of
proper attention to security matters in the IT world in general, it uses
Wallen's article as a springboard, and the beginning of it is largely a
direct response to the "Why the BSDs get no love" article. I thought I'd
bring it up here, since there has been some concern showed on this list
about the content of Wallen's article.
I'd wait until my article gets published to mention it here, so I could
provide a direct URL to it at the time, but I might be electronically
incommunicado at the time (Christmas vacation and all), so I figured I'd
give anyone interested a heads-up that it's coming.
I welcome any (hopefully constructive) feedback from the FreeBSD Advocacy
list's members and the larger FreeBSD community, of course.
For the record, this email was composed on my ThinkPad running FreeBSD
7.2. I mention FreeBSD from time to time in my security articles, and
have been particularly focusing on some matters related to basic
filesystem security this month in my TechRepublic articles. While I will
probably have to lay off the FreeBSD stuff for a little while to keep the
editors happy, I wouldn't mind suggestions from FreeBSD advocates for
what other FreeBSD-related topics might make for good security article
content in the future -- especially if they tie in strongly with more
"mainstream" security topics.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Peer Schaefer
a little "polishing".
--Peer
Peer Schaefer
> At the risk of being challenged to produce code (Which, alas, I don't have
> sufficient skill to do. Or sufficient time.) I'd design an installer as a
> CLI program that reads in a fairly simple fixed script or language to do the
> installation work, and have separate Curses and/or X based programs to allow
> users to create the installation script interactively. I think that would
> fulfil just about everybodies' requirements, from the people that want a
> *shiny* graphical interface to people wanting to do automatic unattended
> installs over serial lines.
>
> Of course, this sort of project has been attempted before, and been a
> complete failure.
>
> Cheers,
>
> Matthew
>
BTW, the Debian installer consists (a) of a modular, frontend agnostic
backend, and (b) different frontend "plugins", e.g. a curses-frontend or
a X/GTK+-frontend. This is a modular and very elegant approach (but
surely difficult to implement).
Diane Bruce
> On Tue 15 Dec 2009 at 07:33:49 PST Jan Husar wrote:
> >http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
>
> Others have pointed out that PC-BSD meets the need expressed in this
> article.
I believe this is because of a common misconception of what FreeBSD is.
In essence FreeBSD would be the equivalent of the Linux kernel, except
we have a userland integrated. No one would claim that the Linux kernel
was a 'distro' that needed a GUI installer, yet some think that of FreeBSD.
>
> As for FreeBSD itself, the question must be asked: do we WANT to get
> more love from people who judge an OS by whether or not it has a
> graphical installer?
No, but it would be great if there were some offerings in ports for
those who wished to roll their own 'distro' ;-).
--
- d...@FreeBSD.org d...@db.net http://www.db.net/~db
Julian H. Stacey
> ... an installer as
> a
> CLI program that reads in a fairly simple fixed script or language to do
> the
> installation work, and have separate Curses and/or X based programs to al
> low
> users to create the installation script interactively.
I admit being seduced at times by graphical interfaces, but
bland blue screens hide a lot of action & info CLI allows.
I was told blind people need CLI, cos Braille output devices do one
line of 40 chars, (& expensive; possibly mass production might lower
costs / inrease resolution, but Braille is different for different
languages, discouraging mass production ).
Peer Schaefer <peer.s...@hamburg.de> wrote:
> BTW, the Debian installer consists (a) of a modular, frontend agnostic
> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
> a X/GTK+-frontend. This is a modular and very elegant approach (but
> surely difficult to implement).
Perhaps the way to go is a common table of target defaults eg
/usr/src/usr.sbin/sysinstall/install.cfg
Which could then be edited by all of
Front end CLI (*)
Front end curses GUI (*)
(*) Maybe these 2 alternatives should be
the first question the installer asks ?
Front end X11 GUI (for later after main install complete
- Shudder, Not that I'd use it, but someone
would probably want to write one).
vi - for editing, & writing back to new boot media,
to auto install on multiple identical new machines.
All of 4.11, 7.1 & 8.0 man sysinstall contain:
This product is currently at the end of its life cycle and
will eventually be replaced.
Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org
Heidi Wyss
> because I've done it so many times. The first few attempts were extremely
> frustrating; the menu flow in the current installer makes little sense --
> especially if something goes wrong. Please keep that in mind, everyone on
> this list knows the installer like the back of their hand, but do you
> remember the first time(s) you used it? Know a fairly seasoned linux user
> that has never used FreeBSD? Sit them down at a machine and watch them try
> to install it.
>
> First impressions are important! I won't go into the gui vs non-gui
> installer debate, but making the install process as slick as possible is
> definitely a good thing.
>
My first install of FreebSD, 5x, years ago, went smoothly, even with
that not-so-smooth default install script, because I had first carefully
read the handbook section on installing and hence had enough
understanding about what I was trying to do that I was able to happily
muddle through. I do recall that getting X up and running was not easy
and may have taken an hour or so, but likewise, the FreeBSD handbook and
a man page or two got me by. I was also very motivated, since my own
migration to FreeBSD was not a happenstance whim, but researched and
planned.
Last week I did a fresh install of FreeBSD 8. It was more or less a snap
(aside from some wee glitches, stuff like two WM dockapps I'd brought
forward from an earlier desktop setup working, but literally throwing
off millions of IO errors), either way, I found it rather easy only
because I'd done it a few times before and knew how to deal with what
might come up (and again, read the documentation when I didn't).
From what I've seen, almost all users (even "advanced" ones coming from
Linux) who try and fail to install FreeBSD indeed haven't read the
handbook and aren't very willing to do so. The installation dialog does
have some odd steps which, while no big thing for someone who's heeding
the docs, will likely be seen as utter failures for someone who's not.
Hence I see a FreeBSD installation as a "cultural" shift which doesn't
work for most users, who (understandably, I guess) want an easy
point-and-click installation. Likewise, most of the so very helpful and
slick things about running a FreeBSD desktop, along with all those
wonderful ports, come through at least some willingness to keep reading
man pages, beginning with running the wholly automated compile scripts
from a command line as root, never mind little tricks like typing
"rehash" when the installation's done.
A smooth graphical install program would very likely draw many new users
to FreeBSD and may be the only way to do so. Moreover, with what looks
to me like the almost wholly automated hardware detection now in Xorg
7.4, even X could be configured by scripts on the fly most of the time,
with the installation optionally offering to end with a wide choice of
windowed GUIs such as Gnome, KDE, FluxBox, WindowMaker and so on. Hey,
with a few hundred thousand more desktop users, browser-embedded, native
Flash might even show up!
I did have to configure my Swiss keyboard manually though, which was
slightly daunting (which is to say, took me about 15 minutes rather than
1 or 2) because the config terms for this kind of KB weren't
straightforwardly defined.
I'll end with this little tale, only to stir up thoughts: When I got the
new versions of mplayer and vlc installed on FBSD8, I couldn't play most
of my store-bought DVDs. Since I knew there had to be an easy fix, five
minutes of searching on the Internet brought the easy fix (FreeBSD is so
stable and reliable, once configured, I'd wholly forgotten about the
CD/DVD device permissions), but how many so-called "mainstream" desktop
users would get through that kind of glitch? Not many, however much
someone like me, who's already quite delighted with FreeBSD, might wish
otherwise.
Heidi
Tony Theodore
> On Tue, Dec 22, 2009 at 07:24:10PM -0800, Charlie Kester wrote:
>> On Tue 15 Dec 2009 at 07:33:49 PST Jan Husar wrote:
>> >http://blogs.techrepublic.com.com/opensource/?p=1123&tag=nl.e011
>>
>> Others have pointed out that PC-BSD meets the need expressed in this
>> article.
>
> I believe this is because of a common misconception of what FreeBSD is.
> In essence FreeBSD would be the equivalent of the Linux kernel, except
> we have a userland integrated. No one would claim that the Linux kernel
> was a 'distro' that needed a GUI installer, yet some think that of FreeBSD.
I think of FreeBSD as kernel/base/ports, the equivalent in the Linux
world would be a mix of Debian/Gentoo. In essence, FreeBSD is an
operating system (the primary distro of the kernel) with derivatives
that enable specific applications (FreeNAS, PC-BSD). I don't think
anyone would claim FreeBSD is a kernel and userland that required
arcane knowledge to install and run. I'd compare PC-BSD to Ubuntu, but
even kernel/base has no real equivalent in the Linux world.
I still wonder about the drive geometry messages though; but after
many years, have learnt that I can safely accept what the bios is
reporting. True, I'm ambivalent about a graphical installer, but I've
bootstrapped installs from kernel and network drivers (for fun), and I
don't think the current installer is clear or obvoius without the
handbook (if only we could get people to read it!).
>> As for FreeBSD itself, the question must be asked: do we WANT to get
>> more love from people who judge an OS by whether or not it has a
>> graphical installer?
>
> No, but it would be great if there were some offerings in ports for
> those who wished to roll their own 'distro' ;-).
In many ways, the base/ports design is of itself a way to roll your own.
Tony
Randi Harper
> Peer Schaefer <peer.s...@hamburg.de> wrote:
>
>> BTW, the Debian installer consists (a) of a modular, frontend agnostic
>> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
>> a X/GTK+-frontend. This is a modular and very elegant approach (but
>> surely difficult to implement).
>
> Perhaps the way to go is a common table of target defaults eg
> � � � �/usr/src/usr.sbin/sysinstall/install.cfg
> Which could then be edited by all of
> � � � �Front end CLI � � � � � (*)
> � � � �Front end curses GUI � �(*)
> � � � � � � � �(*) � � � � � � Maybe these 2 alternatives should be
> � � � � � � � � � � � � � � � �the first question the installer asks ?
> � � � �Front end X11 GUI (for later after main install complete
> � � � � � � � � � � � � � � � �- Shudder, Not that I'd use it, but someone
> � � � � � � � � � � � � � � � � �would probably want to write one).
> � � � �vi - for editing, & writing back to new boot media,
> � � � � � � � �to auto install on multiple identical new machines.
I would sooner stab myself in the face.
> All of 4.11, 7.1 & 8.0 man sysinstall contain:
> � � � �This product is currently at the end of its life cycle and
> � � � �will eventually be replaced.
Sure, once someone writes something everyone can agree upon. Until
then, sorry, you're stuck with sysinstall. :)
-- randi
Julian H. Stacey
> On Wed, Dec 23, 2009 at 6:50 AM, Julian H. Stacey <j...@berklix.com> wrote:
> > Peer Schaefer <peer.s...@hamburg.de> wrote:
> >
> >> BTW, the Debian installer consists (a) of a modular, frontend agnostic
> >> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
> >> a X/GTK+-frontend. This is a modular and very elegant approach (but
> >> surely difficult to implement).
> >
> > Perhaps the way to go is a common table of target defaults eg
> > � � � �/usr/src/usr.sbin/sysinstall/install.cfg
> > Which could then be edited by all of
> > � � � �Front end CLI � � � � � (*)
> > � � � �Front end curses GUI � �(*)
> > � � � � � � � �(*) � � � � � � Maybe these 2 alternatives should be
> > � � � � � � � � � � � � � � � �the first question the installer asks ?
> > � � � �Front end X11 GUI (for later after main install complete
> > � � � � � � � � � � � � � � � �- Shudder, Not that I'd use it, but someone
> > � � � � � � � � � � � � � � � � �would probably want to write one).
> > � � � �vi - for editing, & writing back to new boot media,
> > � � � � � � � �to auto install on multiple identical new machines.
>
>
> I would sooner stab myself in the face.
Not obvious at all which your personal revulsion applies to
CLI ? ncurses ? install.cfg ?, X11 ?, vi ?
I was trying to think of a unifying structure that would allow for
variant personal preferences, inc. prefs to avoid some interfaces.
(eg personally I've no use for X11 post install, or 'vi install.cfg`
mass production install, but there's others it would attract).
> > All of 4.11, 7.1 & 8.0 man sysinstall contain:
> > � � � �This product is currently at the end of its life cycle and
> > � � � �will eventually be replaced.
>
>
> Sure, once someone writes something everyone can agree upon. Until
> then, sorry, you're stuck with sysinstall. :)
Yes, & All will never agree, it's schismatic, sort of thing
attractive to PCBSD DesktopBSD or Yet-Another-BSD forks/front ends,
or about as endless discussion as which brewery brews best beer :-)
Randi Harper
correct/discuss some of his assumptions. Waiting to see if he decides
to email me back. :P
-- randi
Randi Harper
> Randi Harper wrote:
>> On Wed, Dec 23, 2009 at 6:50 AM, Julian H. Stacey <j...@berklix.com> wrote:
>> > Peer Schaefer <peer.s...@hamburg.de> wrote:
>> >
>> >> BTW, the Debian installer consists (a) of a modular, frontend agnostic
>> >> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
>> >> a X/GTK+-frontend. This is a modular and very elegant approach (but
>> >> surely difficult to implement).
>> >
>> > Perhaps the way to go is a common table of target defaults eg
>> > � � � �/usr/src/usr.sbin/sysinstall/install.cfg
>> > Which could then be edited by all of
>> > � � � �Front end CLI � � � � � (*)
>> > � � � �Front end curses GUI � �(*)
>> > � � � � � � � �(*) � � � � � � Maybe these 2 alternatives should be
>> > � � � � � � � � � � � � � � � �the first question the installer asks ?
>> > � � � �Front end X11 GUI (for later after main install complete
>> > � � � � � � � � � � � � � � � �- Shudder, Not that I'd use it, but someone
>> > � � � � � � � � � � � � � � � � �would probably want to write one).
>> > � � � �vi - for editing, & writing back to new boot media,
>> > � � � � � � � �to auto install on multiple identical new machines.
>>
>>
>> I would sooner stab myself in the face.
>
> Not obvious at all which your personal revulsion applies to
> � � � �CLI ? ncurses ? install.cfg ?, X11 ?, vi ?
All of the above. The bug list for sysinstall is not small. Even if
this wasn't the case, I'm not even going to work on introducing that
many options and obfuscating the code that much more. The mere thought
of the rewrite involved in adding that kind of support makes my head
feel like the knife is already in place.
The only support I've been *thinking* about adding is a simple CLI in
addition to the existing libdialog (ncurses) install. This would still
be a not insignificant modification, but there are issues that make
using a libdialog based installer problematic on some displays. It's a
fun idea to kick around, but it's not a priority.
I don't even know what you mean by vi, but it sounds confusing and
unnecessary. This is what install.cfg is for - so you can define the
parameters of an installation beforehand.
-- randi
Tom Rhodes
Randi Harper <ra...@freebsd.org> wrote:
> On Wed, Dec 23, 2009 at 6:50 AM, Julian H. Stacey <j...@berklix.com> wrote:
> > Peer Schaefer <peer.s...@hamburg.de> wrote:
> >
> >> BTW, the Debian installer consists (a) of a modular, frontend agnostic
> >> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
> >> a X/GTK+-frontend. This is a modular and very elegant approach (but
> >> surely difficult to implement).
> >
> > Perhaps the way to go is a common table of target defaults eg
> > � � � �/usr/src/usr.sbin/sysinstall/install.cfg
> > Which could then be edited by all of
> > � � � �Front end CLI � � � � � (*)
> > � � � �Front end curses GUI � �(*)
> > � � � � � � � �(*) � � � � � � Maybe these 2 alternatives should be
> > � � � � � � � � � � � � � � � �the first question the installer asks ?
> > � � � �Front end X11 GUI (for later after main install complete
> > � � � � � � � � � � � � � � � �- Shudder, Not that I'd use it, but someone
> > � � � � � � � � � � � � � � � � �would probably want to write one).
> > � � � �vi - for editing, & writing back to new boot media,
> > � � � � � � � �to auto install on multiple identical new machines.
>
>
> I would sooner stab myself in the face.
Editing disks in vi is fun apparently! :)
>
>
> > All of 4.11, 7.1 & 8.0 man sysinstall contain:
> > � � � �This product is currently at the end of its life cycle and
> > � � � �will eventually be replaced.
>
>
> Sure, once someone writes something everyone can agree upon. Until
> then, sorry, you're stuck with sysinstall. :)
What happened to the BSD installer? And finstall ... Ivan?
Ivan *knock knock* ;)
--
Tom Rhodes
Tony Theodore
>>> > /usr/src/usr.sbin/sysinstall/install.cfg
>>> > Which could then be edited by all of
>>> > Front end CLI (*)
>>> > Front end curses GUI (*)
>>> > (*) Maybe these 2 alternatives should be
>>> > the first question the installer asks ?
>>> > Front end X11 GUI (for later after main install complete
>>> > - Shudder, Not that I'd use it, but someone
>>> > would probably want to write one).
>>> > vi - for editing, & writing back to new boot media,
>>> > to auto install on multiple identical new machines.
>>>
>>>
>>> I would sooner stab myself in the face.
>>
>> Not obvious at all which your personal revulsion applies to
>> CLI ? ncurses ? install.cfg ?, X11 ?, vi ?
>
>
> All of the above. The bug list for sysinstall is not small. Even if
> this wasn't the case, I'm not even going to work on introducing that
> many options and obfuscating the code that much more. The mere thought
> of the rewrite involved in adding that kind of support makes my head
> feel like the knife is already in place.
The idea is that it "simplifies" the code by making it more modular.
All the final "sysinstall" has to do is execute the specifics of
install.cfg. It's just a text file, anything can modify it - of
course, in a standardised way. The suggestion is to develop front-ends
that can generate/modify such a file which the installer back-end will
execute. Think of it as functional programming for installers - define
the installations options in a declarative way, and let the installer
take care of the rest.
Yes, trying to implement such a thing may drive you to stab yourself
in the face - you can do that with a toothpick, but the idea should
cause you to sharpen a different blade. No one is asking you to do it,
just think of some possibilities.
> The only support I've been *thinking* about adding is a simple CLI in
> addition to the existing libdialog (ncurses) install. This would still
> be a not insignificant modification, but there are issues that make
> using a libdialog based installer problematic on some displays. It's a
> fun idea to kick around, but it's not a priority.
>
> I don't even know what you mean by vi, but it sounds confusing and
> unnecessary. This is what install.cfg is for - so you can define the
> parameters of an installation beforehand.
vi is an arcane, obscure text editor that is used by alpha/uber-geeks
to modify *.cfg files ;) No one in their right mind would suggest the
possibility of manually editing a text file, let alone the sysinstall
.cfg file. Who knows what configuration options would be possible?
Having cli/X11/ncurses/text interfaces to install.cfg seems ideal to
me. The technical difficulty alone would in all likelihood ground it,
it doesn't need to be shot down.
Tony
Randi Harper
Yeah... I know what vi *is*. I don't see how it's relevant as an
installation option. And by the way, you do edit the install.cfg file
by hand. We don't have a handy tool to automagically create one of
these as far as I know. You know what options are possible by looking
at the sysinstall man page, looking at the example install.cfg file,
or reading sysinstall.h.
>
> Having cli/X11/ncurses/text interfaces to install.cfg seems ideal to
> me. The technical difficulty alone would in all likelihood ground it,
> it doesn't need to be shot down.
I'm shooting it down as in "I am not doing this" because I'm currently
the person working on sysinstall. ;)
-- randi
Freddie Cash
> On wednesday, the 23.12.2009, 08:38 +0000 Matthew Seaman wrote:
> > At the risk of being challenged to produce code (Which, alas, I don't
> have
> > sufficient skill to do. Or sufficient time.) I'd design an installer as
> a
> > CLI program that reads in a fairly simple fixed script or language to do
> the
> > installation work, and have separate Curses and/or X based programs to
> allow
> > users to create the installation script interactively. I think that
> would
> > fulfil just about everybodies' requirements, from the people that want a
> > *shiny* graphical interface to people wanting to do automatic unattended
> > installs over serial lines.
> >
> > Of course, this sort of project has been attempted before, and been a
> > complete failure.
>
> BTW, the Debian installer consists (a) of a modular, frontend agnostic
> backend, and (b) different frontend "plugins", e.g. a curses-frontend or
> a X/GTK+-frontend. This is a modular and very elegant approach (but
> surely difficult to implement).
>
> This is similar to how the BSD Installer project is organised: a non-GUI
backend with various Text, GUI, and web frontends available.
--
Freddie Cash
fjw...@gmail.com
Tony Theodore
> installation option. And by the way, you do edit the install.cfg file
> by hand. We don't have a handy tool to automagically create one of
> these as far as I know. You know what options are possible by looking
> at the sysinstall man page, looking at the example install.cfg file,
> or reading sysinstall.h.
I think that's the whole point, there are some people that can/would
like to hand craft an installation file. I'm happy with the advice
from the handbook, and am curious about the man pages, example and
header files, but I've never looked at them (for sysinstall). Many
don't even follow the handbook. As FreeBSD is a general-purpose
operating system, I think it would be impossible to cover the needs of
embedded hardware developers, desktops users, server admins, and the
curious; with a single installer.
>>
>> Having cli/X11/ncurses/text interfaces to install.cfg seems ideal to
>> me. The technical difficulty alone would in all likelihood ground it,
>> it doesn't need to be shot down.
>
>
> I'm shooting it down as in "I am not doing this" because I'm currently
> the person working on sysinstall. ;)
Kudos and thanks to you; through the growing tendency of installers to
be ignorant and rude, sysinstall remains competent and polite (I have
no other words to compare them). This is advocacy, noone is asking
_you_ to do it, but if we could add friendly....
Tony
Marina Brown
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
> To unsubscribe, send any mail to "freebsd-advoca...@freebsd.org"
>
I preferr a non-graphical installer. I like the installers of the BSD's.
The simpler the better !
--- Marina Brown
Roger
I'm recently new to FreeBSD (former Linux user) and I would like to
share my thoughts in the matter.
(1)
I love *BSD, especially FreeBSD because of the way it is. I read the
handbook before installing it and my
first impressions with the installation process was fine. My biggest
problem was understanding the whole concept of
slices, partitions and the ports but once I got around that,
everything was fine. I have to admit that the installer is a little
bit confusing
at first but once you have done it 2 or 3 times it is very easy to use
and the handbook helps a lot. Also the FreeBSD
mailing lists is full of very nice and helpful people so that really
helped my move from Linux.
Note that my installation was very straight forward so maybe I did not
encounter enough situations to really provide an
accurate opinion on the matter.
(2)
I AGREE that FreeBSD needs to make it easier for new people to
FreeBSD. The reason why I believe that is because the more people
you have using FreeBSD the more feedback the project would get. At the
same time I don't think this effort should come from the core
developers. I think the core developers should concentrate on building
a base system that is stable, secure etc. and then have something
on top of that done by someone else. In other words, provide the
possibility for different type of installers to be built that target
different
audience.
(3) I have a couple of questions so I could better understand the the
whole installer business.
--- How difficult it is to add a couple extra options to the menu that
you are offered when first installing FreeBSD
so that you can choose a particular installer?
--- Assuming this installers where done, how difficult would it be to
make it part of the installation medias (CD, USB, DVD etc).
--- How difficult it is to test an installer? (VirtualBox or some
other virtualization software comes to mind for testing).
--- What kind of knowledge is required/recommended to take on this task?
--- What kind of resources are there available to help with this task?
Feel free to ignore points 1 and 2 since I'm new to FreeBSD and I
probably should be getting involved in this sort of discussions but
any input on
point 3 would be highly appreciated.
-r
Roger
From: Roger <rno...@gmail.com>
Date: Wed, Dec 23, 2009 at 11:50 AM
Subject: Re: why BSDs got no love
To: Jan Husar <jan....@skosi.org>
On Wed, Dec 23, 2009 at 11:47 AM, Roger <rno...@gmail.com> wrote:
> Feel free to ignore points 1 and 2 since I'm new to FreeBSD and I
> probably should be getting involved in this sort of discussions but
> any input on
> point 3 would be highly appreciated.
>
> -r
>
That should have been ".... SHOULD NOT BE GETTING INVOLVED.....".
-r
Allen
> +1 to a better installer, graphical or not.
>
doesn't sit there saying to switch discs in what seems to be a very
random order... I still think that would help a lot.... Why DOES the
installer do that exactly? I can't tell you how many times I've been
sitting there installing, walked away, and then saw that a package was
on another disk, and it was either switch, or, not get it installed....
And I have decided to wait for disk switching sometimes, but I noticed
the packages that get skipped for now generally don't install.
So basically, it would be nice if the install was more in the way of
installing packages in disk order. Like for example:
You start installing, and instead of it saying you need to switch disks,
it instead finds ALL the packages you're going to install that are in
that disk, installs them, THEN tells you to put in disc #2 or #3 or
whatever.
Personally I'd be happy with the BSD version of the Slackware
installation. Slackware looks a lot like FreeBSD's installation, but the
disks and package installations go in order and it doesn't ask you to
put another one back in because it installs all packages in groups on
each disk, and so after the first disk is finished, you put the second
in, and it continues, and so on, and the only time you would ever put
the first back in, is when it was Kernel time, which now isn't even a
problem either, because now it installs in disk order all the way.
Sorry, I know that was a lot of text, but I use FreeBSD and Linux, and
both are in use in my network, and I like having both. I would just
really like to see some good changes to FreeBSD, and I don't think a GUI
installer is the requirement.
A GUI install could be like an option, maybe, like Linux, where you have
the option to install either in text mode, or GUI mode, but I'd say get
the disc switching sorted first. FreeBSD is a great OS, and once the
install is done, you start up GDM or KDM, or whatever you like, and
literally anyone including my Mom, can use it.
I once set up a machine with Linux where it would auto boot into KDM, my
Mom could log in, "just like at work!" and then I set up the desktop so
that Firefox and something else was there on the desktop, and my Mom
would go and use it like it was Windows. It was very simple, and
securing it was very easy, and She asked why the anti virus wasn't
constantly asking Her to update and taking up CPU time constantly at
boot up, and I simply said it wasn't needed, nor were reboots. She Liked it.
To make FreeBSD better, try this, as it's my opinion:
1. Sort out the order in which CDs need to be switched.
2. If the installer is to be changed, why not make it similar to the
Slackware one? It's basically like FreeBSD, but goes in a specific order
someone on here said would be nice.
3. Making it easier to install patches would probably help A LOT. I know
if you could do things like you can in Linux or Windows where you just
install patches with a few clicks, it would be much easier for new
users. People who use Slackware, can use wget, and upgradepkg
packagename.tgz and it's done. SuSE is basically easier than Windows, it
grabs them for you, checks for you, everything. And if you want patches
in a different way, you tell it not to check at all and you can then do
it by hand.
Debian has apt-get, and with one line of commands, I can update servers,
then upgrade packages, and that's very simple, compared to FreeBSD,
where you have to install updates for the base system, THEN updates for
the ports, which is prone to breaking if you do something wrong.
I think FreeBSD would benefit greatly from a simpler way of installing
patches and things. freebsd-update and portupgrade are nice, but, what
about something that has a GUI that checks a server for updates, or, you
can tell it to check, and then it downloads and installs them for you?
That would probably get more Linux users in, and some Windows users who
feel like trying it.
Lowell Gilbert
> Randi Harper wrote:
>> Sure, once someone writes something everyone can agree upon. Until
>> then, sorry, you're stuck with sysinstall. :)
>
> Yes, & All will never agree, it's schismatic, sort of thing
> attractive to PCBSD DesktopBSD or Yet-Another-BSD forks/front ends,
> or about as endless discussion as which brewery brews best beer :-)
But less useful, going by the historical record. The various breweries
are already producing their products, and I may find new favorites by
discussing them. But discussing what an installer should do is useless
unless somebody implements the ideas under discussion. I'd be happy to
see any manner of improvements to/over sysinstall, but not enough to
implement them myself. [Not even close.]
Matthew D. Fuller
Julian H. Stacey, and lo! it spake thus:
>
> All of 4.11, 7.1 & 8.0 man sysinstall contain:
> This product is currently at the end of its life cycle and
> will eventually be replaced.
That's a kinder version of what it had in rev 1.1 in 1997, prior to
2.2.5-RELEASE
This utility is a prototype which lasted approximately 2 years
past its expiration date and is greatly in need of death.
--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Astrodog
be replaced... but it works well enough that it doesn't *have* to be
replaced, and most people aren't bothered enough by it to write code
to come up with something new. Certainly, having things like zfs
support in sysinstall would be nice... but most of the people using
zfs boot know the system well enough to do it from the Fixit/LiveFS
shell anyway.
Basically... if you really want to see this change, I think you're
gonna have to do it yourself.
--- Harrison
Petrus
> be replaced... but it works well enough that it doesn't *have* to be
The virtue of sysinstall, however, is that it is console based. I for one
would rather endure sysinstall's idiosyncracies, if it still means that I'm
going to be able to reliably install on whatever ancient, eldritch hardware
I happen to have with me at the time.
If someone wants to write something X based, with hardware detection a la
Ubuntu, and all the proverbial bells and whistles and flashing lights, then
by all means; (and I think they already have, with finstall) but I think
FreeBSD absolutely needs to keep a console-based installer as a fallback for
old hardware.
Mike Bybee
> From: "Petrus" <pet...@tpg.com.au>
> Subject: Re: why BSDs got no love
> Message-ID: <001001ca85c4$762faa80$0301a8c0@jim4fb89194d83>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
there, version 8 can do a pure FreeBSD 8 install *or* a PC-BSD install (with
the extra PBI bits and whatnot) and has a nice graphical installer as well
as a LiveCD image.
There is absolutely no reason to change the default FreeBSD installer in my
opinion, when the PC-BSD one will suffice for the 'snazzy' desktop installs.
--
Thanks,
Mike Bybee
jhell
Personally I would like to see something around the likes of
shells/flash menu shell implemented with some modular scripting and
drop-in binaries for other tasks that cannot be accomplished through
the use of shell scripts as elegantly as they would in C. As for
licensing of shells/flash I am unsure but it does bring the ease of
scripting into play that can shield a user from some of the behind the
scenes ugliness.
Snip of the pkg-desc:
Flash is an attempt to create a secure menu-driven shell for UNIX-derived OSes,
while providing user-friendliness and easy configurability. An ideal situation
requiring the use of flash would be a student-run telnet server which needs to:
a) shelter the users from some of the nastiness of UNIX
b) shelter the system from nasty users
c) provide an easy way to launch applications
d) support multitasking/job control as elegantly as possible
e) support easy-to-get-right configuration by administrators
----
In that type of menu it would be easy to drop a script that asks:
A) Would you like a GUI install menu...
B) Would you like a CLI install menu...
C) Get me out of here...
----
It also has a nice little notes side frame that could tell the user a
little more about what is going on if they are confused about the
choices that are selected.
As for my self, I would be willing to contribute some bits & bytes to
see this happen. As for the GUI I would be willing to write the hooks
for it in the menu system but that is as far as I am willing to go
with it. I don't see any satisfactory need or gain in GUI for
just-a-installer.
Best regards.
--
Saturday, December 26, 2009 10:59:02 PM
jhell
Petrus
> my
> opinion, when the PC-BSD one will suffice for the 'snazzy' desktop
> installs.
I won't say that sysinstall couldn't benefit from at least *some*
renovation. ;)
The interface is fine, sure, but what I'm primarily talking about is the
download mechanism. Apparently when certain files get downloaded with it,
they actually get copied in-place during the transfer process, which means
that if you abort it, you can end up with partially digested conf files (my
/etc/passwd got hosed once) all over the place.
What I'd propose would be caching whatever files the system needs to
download until everything is cached locally, and then installing the lot
after that, rather than doing both downloading and installing/copying in the
same step. That way you can safely abort during the process if you need to.
A scenario where individual files that are to be rewritten, get temporarily
backed up until the setup is complete would probably also really help.
So as said, the interface is fine, but I think the internal mechanism could
definitely benefit from being made a bit more robust.
Dag-Erling Smørgrav
> Basically... if you really want to see this change, I think you're
> gonna have to do it yourself.
What do you think this is, a collaborative open source project? Furrfu!
DES
--
Dag-Erling Smørgrav - d...@des.no
Sdävtaker
applications in the dvd use to fail the install because dependencies that
can be resolved in the ports (as portinstall/portmaster does whena package
dependency is not fulfilled).
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
> To unsubscribe, send any mail to "freebsd-advoca...@freebsd.org
> "
>
Giorgos Keramidas
> Update:
>
> I confirmed that the scheduled publication date for my article will be
> Tuesday the 29th.
It's up at http://blogs.techrepublic.com.com/security/?p=2888
Charlie Kester
Well done, Chad!
One question, however. Are we prepared to back up the claim that the
"sexy" bits of PC-BSD are the least secure? Your argument depends on
that claim, since it's also implied in your description of development
team's priorities.
Chad Perrin
> On Tue 29 Dec 2009 at 06:38:23 PST Giorgos Keramidas wrote:
> >On Wed, 23 Dec 2009 16:56:51 -0700, Chad Perrin <per...@apotheon.com>
> >wrote:
> >>Update:
> >>
> >>I confirmed that the scheduled publication date for my article will be
> >>Tuesday the 29th.
> >
> >It's up at http://blogs.techrepublic.com.com/security/?p=2888
> >
>
> Well done, Chad!
Thanks!
>
> One question, however. Are we prepared to back up the claim that the
> "sexy" bits of PC-BSD are the least secure? Your argument depends on
> that claim, since it's also implied in your description of development
> team's priorities.
Define "we". As I'm not a core developer for FreeBSD, nor anyone in a
position of official representation of either the OS development project
or the Foundation, my statements in the article should not be taken as
necessarily indicative of anyone's opinions but my own.
The claim about the "sexy" bits of PC-BSD is based on my experience with
tarted-up GUIs and "feature-rich" software. It is intended as a
generalization rather than a categorical statement of absolute truth.
All stuffy pedantry of mine aside, though, if you want to expand on your
concerns, I'd be happy to read about them.
Charlie Kester
>On Tue, Dec 29, 2009 at 12:39:01PM -0800, Charlie Kester wrote:
>>
>> One question, however. Are we prepared to back up the claim that the
>> "sexy" bits of PC-BSD are the least secure? Your argument depends on
>> that claim, since it's also implied in your description of development
>> team's priorities.
>
>Define "we". As I'm not a core developer for FreeBSD, nor anyone in a
>position of official representation of either the OS development project
>or the Foundation, my statements in the article should not be taken as
>necessarily indicative of anyone's opinions but my own.
I said "we" rather than "you" because I agree with your argument. :)
>
>The claim about the "sexy" bits of PC-BSD is based on my experience with
>tarted-up GUIs and "feature-rich" software. It is intended as a
>generalization rather than a categorical statement of absolute truth.
>
>All stuffy pedantry of mine aside, though, if you want to expand on
>your concerns, I'd be happy to read about them.
I was wondering if anyone has done a study of reported security holes
and if that data supports the assertion that the "sexy" GUI stuff PC-BSD
adds was more likely to be involved than the base OS.
But even if there hasn't been any such study, I think it would be
worthwhile to flesh out your assertion with a few examples of the kind
of security problems that arise when the "sexy" stuff is used.
As I said above, I think the argument stands or falls on our ability to
defend this point.
Chad Perrin
> On Tue 29 Dec 2009 at 14:51:23 PST Chad Perrin wrote:
> >On Tue, Dec 29, 2009 at 12:39:01PM -0800, Charlie Kester wrote:
> >>
> >>One question, however. Are we prepared to back up the claim that the
> >>"sexy" bits of PC-BSD are the least secure? Your argument depends on
> >>that claim, since it's also implied in your description of development
> >>team's priorities.
> >
> >Define "we". As I'm not a core developer for FreeBSD, nor anyone in a
> >position of official representation of either the OS development project
> >or the Foundation, my statements in the article should not be taken as
> >necessarily indicative of anyone's opinions but my own.
>
> I said "we" rather than "you" because I agree with your argument. :)
Ahh, gotcha. Thanks for clarifying.
> >
> >The claim about the "sexy" bits of PC-BSD is based on my experience with
> >tarted-up GUIs and "feature-rich" software. It is intended as a
> >generalization rather than a categorical statement of absolute truth.
> >
> >All stuffy pedantry of mine aside, though, if you want to expand on
> >your concerns, I'd be happy to read about them.
>
> I was wondering if anyone has done a study of reported security holes
> and if that data supports the assertion that the "sexy" GUI stuff PC-BSD
> adds was more likely to be involved than the base OS.
The only studies I know of that even come close to addressing these
issues are the studies that show there tends to be a semi-constant rate
of bugs per so-many lines of code for software projects within particular
subcultures. That being the case, the sheer weight of lines of code
involved in KDE (the default GUI of PC-BSD), for instance, implies
substantial increase in total number of potentially security-damaging
bugs on the system.
More to the point, though, kitchen sink style installs also tend to run
extra services, redundant server processes, auto-run a bunch of stuff,
and so on -- and I don't really feel I personally need a study to tell me
that's a recipe for security failure somewhere down the road. I totally
understand the desire for some kind of statistical study that supports
that claim, though, whether for your own edification or for that of
others.
>
> But even if there hasn't been any such study, I think it would be
> worthwhile to flesh out your assertion with a few examples of the kind
> of security problems that arise when the "sexy" stuff is used.
I don't recall off-hand whether I've written previous articles on that
subject. I may write some in the future that address that in more depth.
Since that point in particular seemed somewhat outside the scope of the
article to try to support in depth, I kinda left it where it lay. Nobody
has challenged the point in the discussion thread following the article,
last I checked. . . .
>
> As I said above, I think the argument stands or falls on our ability to
> defend this point.
Given an obvious need to do so, I'm happy to offer what support I have
for the point. You're the only person who has asked, though.