Thank you everyone for helping me create a suitable project to propose. I
have submitted a draft of my proposal, though I am still in the process of
enhancing it. If anyone has the time, please check it out and I'll gladly
accept any feedback.
I am new to Google Summer of Code, and just
On Fri, May 3, 2013 at 1:51 PM, Matt Olander m...@ixsystems.com wrote:
Great proposal, Justin! I look forward to seeing your work ;)
Cheers,
-matt
Thank you very much for your support, Matt!
As soon as I start committing code, I will share a link to my repository on
this mailing-list.
Our kernel is actually very easy to configure, so I'm not convinced that
it's needed; you may be thinking of Linux's menuconfig, but I think that is
because of the complexity.
Chris
While configuring the kernel may be trivial to someone who understands the
process and their systems needs,
I agree. Also, the kind of people who compile their kernels probably
feel more comfortable in console mode :)
The frontend for pkgng and freebsd-update might have a bigger user base.
Hello Fernando, thank you for pointing me towards kports earlier. I
appreciate your help.
It is starting
Mostly off-topic for this thread, but improving the boot process to
auto-detect hardware and auto-load kernel modules would be really nice.
That way, GENERIC would be very small, with just the basic frameworks
required (CAM, USB, PCI, TCP/IP, etc), and all the actual drivers would be
loaded
I think the interface to pkgng and freebsd-update are still
interesting; at least more worthwhile than the kernel configuration
one.
I think the pkgng one has the edge, since packages are updated far
more often than base, and it's easier to track base.
Now you are at a stage where you
It _is_ easy. But having a nice graphical tool which draws a pretty table
of
GENERIC and NOTES together with useful information about the possible
options
and devices would be a handy thing to have IMHO.
Let's make FreeBSD userfriendly :-)
I agree completely, hopefully we can make that
During some tests with cut down kernels one can easily make unbuildable
kernel, for example include option A, while omit hiddenly required B.
If there could be framework at least with deps tracking/checking, what
could be good for begin.
Both for configuring, and code clean up.
If this will
Side note: I agree that we would really, really like FreeBSD more user
friendly.
However, is kernel configuration where we really want to start? Just how
much of the user base reconfigures their kernels, anyway? Wouldn't effort
be better spent on making normal installation, maintenance
You'll probably want to get in touch with the PC-BSD folks. As they are
moving to pkgng for everything, they are updating their Python-based GUIs
to work with it. Might be a possibility to work together, or to build
off what
they have, or to get ideas/inspiration for a more general tool.
I
Justin I say stick to FreeBSD-update . My reason is, as Pkgng becomes
more popular , a front end for ports will be less useful as binary packages
become more popular . Kports is a monster program , you should set a
reasonable goal ,and target dates; which may be hard with a cleanup project
Hello everyone once again,
I decided to split this from my previous thread because the nature of
my questions has changed. I benefited from the last thread, and I am
grateful to those who responded to it.
For me Google Summer of Code is a big opportunity, and my interest in
I am excited for this year's Google Summer of Code, and I have a
project in mind that I am working to propose.
I am a CS major and have experience with Qt, C++ and shell scripting.
I have been developing on FreeBSD for several years, and I am looking to
tackle developing a new Qt
Thank you for your advice! I have already sent an email to Colin, and I did
indeed take the idea from that page.
Justin Muniz
On Sun, Apr 14, 2013 at 7:04 AM, Chris Rees cr...@freebsd.org wrote:
On 14 April 2013 07:11, Justin Edward Muniz justin.mu...@maine.edu
wrote:
I am excited
I think GUI front ends to freebsd-update, portsnap, or pkgng would all be
useful.
One thing I would look into though, is what PC-BSD offers. They may
already have similar things.
Very interesting, I am checking out the source for PC-BSD's updater to
study it.
Portsnap and pkgng seem like
Please don't mix the two, they are related but their usages do not really
overlap.
portsnap(8) only deals with keeping the ports(7) tree and the
/usr/ports/INDEX file up to date.
PKGNG (like the old pkg_* tools) is mostly concerned with registering
built ports as packages or installing
It seems we already have something similar in the ports[1] collection.
There is also a newer version[2] using Qt4 but it seems more limited. It
might be worth a look at those first.
[1] ports-mgmt/kports
[2] ports-mgmt/kports-qt4
Yes, I just found those GUI programs myself. No sense
17 matches
Mail list logo
