Re: GSoC: PKGNG GUI Proposal Available for Review

> I wish you the best of luck. > Thank you very much, Fernando! > I'm also happy to see you will use packagekit as a frontend. No need to > reinvent the wheel. > It is a great utility. I have learned a lot while studying it. As a side note, I have made much progress porting PackageKit-0.8.8

Re: GSoC: PKGNG GUI Proposal Available for Review

El 03/05/2013 20:00, "Justin Edward Muniz" escribió: > > On Fri, May 3, 2013 at 1:51 PM, Matt Olander 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

Re: GSoC: PKGNG GUI Proposal Available for Review

On Fri, May 3, 2013 at 1:51 PM, Matt Olander 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. Justin Muniz __

Re: GSoC: PKGNG GUI Proposal Available for Review

te my >>> proposal after submitting it. Initially I uploaded most of the >>> proposal but >>> I am still finishing the last parts. Any advice could help me (or >>> others) >>> develop future proposals, so I hope to hear from people even after the >>>

Re: GSoC: PKGNG GUI Proposal Available for Review

ce could help me (or >> others) >> develop future proposals, so I hope to hear from people even after the >> deadline. >> >> My proposal can be read at the following address: >> https://www.google-melange.com/gsoc/proposal/rev

Re: GSoC: PKGNG GUI Proposal Available for Review

proposals, so I hope to hear from people even after the deadline. My proposal can be read at the following address: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/justin_muniz/1 I appreciate you taking the time to read this email. Happy coding everyone. Justin Muniz _

Re: GSoC: PKGNG GUI Proposal Available for Review

parts. Any advice could help me (or others) develop future proposals, so I hope to hear from people even after the deadline. My proposal can be read at the following address: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/justin_muniz/1 I appreciate you taking the time to read

GSoC project proposal for review (Port GlusterFS to FreeBSD)

Hi all, I'm planning to port GlusterFS as a GSoC project this year. And you can find the more information of the proposal here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/mikemandarine/26018 Any suggestions or comments are more than welcome. I'm looking forward

Re: My GSOC proposal for review

point c. is what i would like the most and is really the most important for NON embedded system. others for embedded ones. d. won't really cut much f. may not save much but slow things down i wish you a success. On Thu, 2 May 2013, Amit Rawat wrote: Hi, I am attaching my gsoc proposal

GSoC: PKGNG GUI Proposal Available for Review

dress: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/justin_muniz/1 I appreciate you taking the time to read this email. Happy coding everyone. Justin Muniz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/ma

GSoC proposal review

Hi, Can somebody review my proposal here and see if it can be further improved? http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/rushilpaul/12001 -- Regards, Rushil ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org

Re: My GSOC proposal for review

Hi, Here is some data I collected https://www.dropbox.com/sh/3ff3x34iq4cm2lu/RDFmXuO2xj. Thanks, Amit Rawat On Thu, May 2, 2013 at 12:58 PM, Amit Rawat wrote: > Hi, > > I am attaching my gsoc proposal with this mail for review. If any body > want any extra thing in it t

[Looking for GSoC mentor] Port NiLFS to FreeBSD

Hi, My friend has interest to apply GSoC'13 with "Port NiLFS to FreeBSD", witch is on IdeasPage(not tagged as GSoC though). https://wiki.freebsd.org/IdeasPage#Port_NiLFS_to_FreeBSD There's no technical contact on the page, who can be a mentor of the project? Or, it's

Re: Port GlusterFS as a GSoC project

On Fri, 26 Apr 2013, Mike Ma wrote: Hi there, I'm now a student and trying to get involved in GSoC this year. I found the proposal of about GlusterFS in the idea list wiki page very interesting to me, possibly it will be porting from NetBSD implementation. As I'm quite distant from

Port GlusterFS as a GSoC project

Hi there, I'm now a student and trying to get involved in GSoC this year. I found the proposal of about GlusterFS in the idea list wiki page very interesting to me, possibly it will be porting from NetBSD implementation. As I'm quite distant from idea owner, he also suggested me to t

Port GlusterFS as a GSoC 2013 project

Hi there, I'm now a student and trying to get involved in GSoC this year. I found the proposal of about GlusterFS in the idea list wiki page very interesting to me, possibly it will be porting from NetBSD implementation. As I'm quite distant from idea owner so there's a big time

Re: GSOC: Qt front-ends

On 25 April 2013 02:24, Lars Engels wrote: > Sure, but the rc.conf solution is the lower hanging fruit. :) No it's not; think about it. You need to have a few modules loaded in order to boot. * usb * maybe atkbd * da/scsi * ata / scsi block device drivers * perhaps network * perhaps vga/vesa *

Re: GSOC: Qt front-ends

On Thu, Apr 25, 2013 at 01:57:50AM -0700, Adrian Chadd wrote: > On 25 April 2013 01:38, Lars Engels wrote: > > On Thu, Apr 25, 2013 at 01:25:46AM -0700, Adrian Chadd wrote: > >> .. or we could just bite the bullet and split GENERIC into GENERIC > >> (which would have modules for everything) and GE

Re: GSOC: Qt front-ends

;re missing is a > way to load them at boot time by the bootloader. Well, enough of them > to bring up the system so the rest can be autoloaded as needed. > > _That_ whole mess would be a great GSoC project. I completely agree. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve!

Re: GSOC: Qt front-ends

On 25 April 2013 01:38, Lars Engels wrote: > On Thu, Apr 25, 2013 at 01:25:46AM -0700, Adrian Chadd wrote: >> .. or we could just bite the bullet and split GENERIC into GENERIC >> (which would have modules for everything) and GENERIC_NOMODULES. >> >> Then just populate a default module list that g

Re: GSOC: Qt front-ends

idden. > > Point is - a modular kernel works, right now. What we're missing is a > way to load them at boot time by the bootloader. Well, enough of them > to bring up the system so the rest can be autoloaded as needed. > > _That_ whole mess would be a great GSoC project. +1 pgpuBzlZI_kIu.pgp Description: PGP signature

Re: GSOC: Qt front-ends

/boot//module.conf.default, and then allow that to be overridden. Point is - a modular kernel works, right now. What we're missing is a way to load them at boot time by the bootloader. Well, enough of them to bring up the system so the rest can be autoloaded as needed. _That_ whole mess would be a

Re: GSOC: Qt front-ends

According to Freddie Cash on Wed, Apr 24, 2013 at 10:32:11AM -0700: > 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

Re: GSOC: Qt front-ends

On Apr 24, 2013, at 2:33 PM, Fernando Apesteguía wrote: El 24/04/2013 21:18, "Teske, Devin" mailto:devin.te...@fisglobal.com>> escribió: > > > On Apr 24, 2013, at 11:54 AM, Baptiste Daroussin wrote: > > > On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote: > >>> > >>> I think t

Re: GSOC: Qt front-ends

El 24/04/2013 21:18, "Teske, Devin" escribió: > > > On Apr 24, 2013, at 11:54 AM, Baptiste Daroussin wrote: > > > On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote: > >>> > >>> I think the interface to pkgng and freebsd-update are still > >>> interesting; at least more worthwhile

Re: GSOC: Qt front-ends

> 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.

Re: GSOC: Qt front-ends

On Apr 24, 2013, at 11:54 AM, Baptiste Daroussin wrote: > On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote: >>> >>> I think the interface to pkgng and freebsd-update are still >>> interesting; at least more worthwhile than the kernel configuration >>> one. >>> >>> I think the

Re: GSOC: Qt front-ends

On Apr 24, 2013, at 11:51 AM, Teske, Devin wrote: On Apr 24, 2013, at 11:10 AM, Freddie Cash wrote: On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz < justin.mu...@maine.edu> wrote: I think the interface to pkgng and freebsd-update are still interesting; at

Re: Fwd: GSOC: Qt front-ends

On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote: > > > > 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 > > mo

Re: GSOC: Qt front-ends

On Apr 24, 2013, at 11:10 AM, Freddie Cash wrote: On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz < justin.mu...@maine.edu> wrote: I think the interface to pkgng and freebsd-update are still interesting; at least more worthwhile than the kernel configuration

Re: GSOC: Qt front-ends

making normal installation, maintenance and deployment > clean and easy? > > Regards, > Tony > What you say makes a lot of sense. I am feeling confident that the kernel GUI should be a lower priority, and not used for the GSoC proposal. Thank you for your time. Justin Muniz __

Re: Fwd: GSOC: Qt front-ends

> > 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 thi

Re: Fwd: GSOC: Qt front-ends

> > 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

Re: GSOC: Qt front-ends

On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz < justin.mu...@maine.edu> wrote: > > > > 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

Fwd: GSOC: Qt front-ends

> > 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

Re: GSOC: Qt front-ends

rivers would be > loaded from modules. That would remove almost all requirements to compile > a custom kernel in the first place. :) > > Granted, changing "options" in the kernel would require recompilation, but > general use and hardware changes wouldn't. > > Mos

Fwd: GSOC: Qt front-ends

> > 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 star

Re: Fwd: GSOC: Qt front-ends

On 24 April 2013 18:30, Justin Edward Muniz wrote: >> 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 trivia

Re: GSOC: Qt front-ends

anging "options" in the kernel would require recompilation, but general use and hardware changes wouldn't. Most likely not a GSoC project. But it's still a nice dream. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-hackers@freebsd.

Re: Fwd: GSOC: Qt front-ends

> > 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

Re: Fwd: GSOC: Qt front-ends

On Wed, Apr 24, 2013 at 5:43 AM, Lars Engels wrote: > Am 24.04.2013 13:44, schrieb Chris Rees: > > 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. >> > > > It _

Re: GSOC: Qt front-ends

On Apr 24, 2013, at 5:43 AM, Lars Engels wrote: > 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 :-)

Re: Fwd: GSOC: Qt front-ends

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 come up

Re: Fwd: GSOC: Qt front-ends

Am 24.04.2013 13:44, schrieb Chris Rees: On 24 Apr 2013 05:36, "Justin Edward Muniz" wrote: 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

Re: Fwd: GSOC: Qt front-ends

El 24/04/2013 13:45, "Chris Rees" escribió: > > On 24 Apr 2013 05:36, "Justin Edward Muniz" wrote: > > > > > > > > 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 .

Re: Fwd: GSOC: Qt front-ends

On 24 Apr 2013 05:36, "Justin Edward Muniz" wrote: > > > > > 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 > > reasonabl

Fwd: GSOC: Qt front-ends

> > 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 proje

Re: GSOC: Qt front-ends

On Apr 21, 2013, at 4:11 PM, Justin Edward Muniz wrote: > 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 Goog

GSOC: Qt front-ends

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 contributing

GSOC and Contribution to open source.

Hi , I am interested in participating for GSOC -2013 . I am interested in following ideas CPU online/offline project BHyVe BIOS emulation to boot legacy systems I have two years of work exp in linux kernel device driver,C now I have selected master thesis as virtualization so I would be

Re: GSOC: Qt front-end for freebsd-update

On Sun, Apr 14, 2013 at 7:50 PM, Justin Edward Muniz wrote: >> >> 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-mgm

Re: GSOC: Qt front-end for freebsd-update

> > 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. N

Re: GSOC: Qt front-end for freebsd-update

> > 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 insta

Re: GSOC: Qt front-end for freebsd-update

On Sun, Apr 14, 2013 at 6:22 PM, Kimmo Paasiala wrote: > On Sun, Apr 14, 2013 at 7:17 PM, Eitan Adler wrote: > > On 14 April 2013 12:15, Kimmo Paasiala wrote: > >> I have to also ask, what would a GUI offer that the command line tools > >> do not offer at the moment? > > > > A GUI. > > > > > >

Re: GSOC: Qt front-end for freebsd-update

On Sun, Apr 14, 2013 at 7:17 PM, Eitan Adler wrote: > On 14 April 2013 12:15, Kimmo Paasiala wrote: >> I have to also ask, what would a GUI offer that the command line tools >> do not offer at the moment? > > A GUI. > > That's kind of given :D But does FreeBSD lack a GUI for ports/packages mana

Re: GSOC: Qt front-end for freebsd-update

On 14 April 2013 12:15, Kimmo Paasiala wrote: > I have to also ask, what would a GUI offer that the command line tools > do not offer at the moment? A GUI. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/l

Re: GSOC: Qt front-end for freebsd-update

On Sun, Apr 14, 2013 at 7:02 PM, Justin Edward Muniz wrote: >> >> 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

Re: GSOC: Qt front-end for freebsd-update

> > 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

Re: GSOC: Qt front-end for freebsd-update

On 14 April 2013 11:42, Justin Edward Muniz wrote: > Thank you for your advice! I have already sent an email to Colin, and I did > indeed take the idea from that page. 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

Re: GSOC: Qt front-end for freebsd-update

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 wrote: > On 14 April 2013 07:11, Justin Edward Muniz > wrote: > > I am excited for this year's Google Summer of Code, a

Re: GSOC: Qt front-end for freebsd-update

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 front-end for the freebsd-update command. spend your time for something more useful :) ___

Re: GSOC: Qt front-end for freebsd-update

On Sun, Apr 14, 2013 at 02:11:44AM -0400, Justin Edward Muniz wrote: > 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 Free

Re: GSOC: Qt front-end for freebsd-update

On 14 April 2013 07:11, Justin Edward Muniz wrote: > 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

GSOC: Qt front-end for freebsd-update

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 front-e

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

Am 10.04.2013 15:27, schrieb Matthew Jacob: On 4/9/2013 11:53 PM, Daniel Braniss wrote: this host can run x11 apps! so 'Huge' is a relative matter, my first PDP11/45 has 64K :-) danny Bah. Real old farts ran munix on a 32k PDP 11/03- shell and apps in the low 16k and the kernel in the upper. Or

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 2013-Apr-09 11:05:56 -0700, Freddie Cash wrote: >You have to look at the in-memory sizes, not the on-disk sizes. Or, even better, look at the difference between installed physical RAM and how much RAM is available to userland processes. -- Peter Jeremy pgpOHqKqYTU0M.pgp Description: PGP si

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 10 April 2013 13:06, Joshua Isom wrote: > > I upgraded my system with 32Gb for a reason. Yes, yes you did. TO force me to fix ath(4) and busdma. ;-) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/fre

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/10/2013 9:43 AM, Jonathan Anderson wrote: The last I heard, LTO on the kernel required something like 16 GB of RAM and produced a not-quite-working image. Jon I upgraded my system with 32Gb for a reason. ___ freebsd-hackers@freebsd.org maili

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On Tuesday, 9 April 2013 at 22:18, Joshua Isom wrote: > Would clang's LTO help for size? I know work's starting on the bsd > elftools ld, but I doubt it has any LTO support yet. Running -Os on the > kernel as a whole instead of object files could probably help a lot > also. I might try to set it up

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/9/2013 11:53 PM, Daniel Braniss wrote: this host can run x11 apps! so 'Huge' is a relative matter, my first PDP11/45 has 64K :-) danny Bah. Real old farts ran munix on a 32k PDP 11/03- shell and apps in the low 16k and the kernel in the upper. Or was it the other way around? At Tektronix,

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

> > happy that FreeBSD is among the selected organization. > > > > I am a third year student interested to work in the field of embedded > > system. I applied last year and the title of my project was " Kernel Size > why only in embedded system. smaller programs are always good :) > > And yes Free

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/9/2013 1:47 PM, Edward Tomasz Napierała wrote: In order to optimize - in this case for size - we need a way to measure what should we focus on, and it looks like we don't have it yet. Would it be possible to write a tool - e.g. by instrumenting LLVM - that would make it possible to calculat

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 9 April 2013 11:47, Edward Tomasz Napierała wrote: > In order to optimize - in this case for size - we need a way to measure > what should we focus on, and it looks like we don't have it yet. We have a good starting point. We can look at the code/data/bss from each .o file that's included in t

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

In order to optimize - in this case for size - we need a way to measure what should we focus on, and it looks like we don't have it yet. Would it be possible to write a tool - e.g. by instrumenting LLVM - that would make it possible to calculate, for every function in the call graph, the amount of

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

Hello, Kimmo. You wrote 9 апреля 2013 г., 21:59:37: KP> Your comparison is far from accurate, include the memory taken by KP> loaded kernel modules on both systems and then you might get some KP> proper numbers. Linux is known to _work_ on SOHO MIPS boxes, with 4MiB of flash and 16MiB of RAM. Y

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

You have to look at the in-memory sizes, not the on-disk sizes. Linux kernels are very barebones when it comes to what is compiled directly into the kernel image on disk. Everything else is loaded from modules at boot time. Especially if using distro-provided kernels. They even use ram disks /

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On Tue, Apr 9, 2013 at 8:53 PM, Wojciech Puchar wrote: >>> And yes FreeBSD kernel is huge. doesn't really matter with 1GB or more >>> RAM but yes - it is huge even relative to linux. >> >> >> Ah, any insight as to why? > > my custom compiled kernel: > > -r-xr-xr-x 1 root wheel 8791402 6 kwi 22

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

And yes FreeBSD kernel is huge. doesn't really matter with 1GB or more RAM but yes - it is huge even relative to linux. Ah, any insight as to why? my custom compiled kernel: -r-xr-xr-x 1 root wheel 8791402 6 kwi 22:08 /boot//kernel/kernel only with features i need. linux is AFAIK like 3-4

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/9/13 10:36 AM, Wojciech Puchar wrote: happy that FreeBSD is among the selected organization. I am a third year student interested to work in the field of embedded system. I applied last year and the title of my project was " Kernel Size why only in embedded system. smaller programs are al

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

happy that FreeBSD is among the selected organization. I am a third year student interested to work in the field of embedded system. I applied last year and the title of my project was " Kernel Size why only in embedded system. smaller programs are always good :) And yes FreeBSD kernel is huge.

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/8/13 6:42 PM, Adrian Chadd wrote: Well, it's relatively easy to experience what it's like. No it's not. We all have jobs that demand different things from us. Taking the time to guess at the problem, only to be told "you're doing it wrong" by someone actually in the position to build t

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 8 April 2013 19:28, Kevin Day wrote: > Ages ago we had to make things work in 16 or 32MB of total system memory on > i386. > > For the most part, disabling every compiled-in option/driver we didn't need > was 90% of the effort. Which options/drivers is going to be totally > application depe

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On Apr 8, 2013, at 7:34 PM, Alfred Perlstein wrote: > However, until a bunch of embedded folks come forward and state what they are > really willing to sacrifice, then we won't really have anything to go on, and > it will be guessing at what will work for a space that not all of us are > famil

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

Well, it's relatively easy to experience what it's like. Reboot your machine with 32mb. Try to do things like bring up network interfaces. Snark when stupid stuff occurs, like you can't allocate enough mbufs for the driver RX path _and_ run the ifconfig command to completion to bring said interfac

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On 4/8/13 4:10 PM, Adrian Chadd wrote: Hi, Your idea is interesting, but it doesn't fix the underlying problem - there's just too much code. :( If you were to API'ify some of the more basic things such as fget, fdrop, filedesc stuff you could potentially swap out the systems for simpler (albe

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

Hi, On Mon, 8 Apr 2013 20:28:04 + Amit Rawat wrote: > GSOC posted the list of selected organization for GSOC 2013 and I am > highly happy that FreeBSD is among the selected organization. > > I am a third year student interested to work in the field of embedded > system. I ap

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

Hi, Your idea is interesting, but it doesn't fix the underlying problem - there's just too much code. :( Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "fr

Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "

On Mon, Apr 08, 2013 at 08:28:04PM +, Amit Rawat wrote: > GSOC posted the list of selected organization for GSOC 2013 and I am > highly happy that FreeBSD is among the selected organization. > I am a third year student interested to work in the field of embedded > system. I appli

GSOC 2013 project " Kernel Size Reduction for Embedded System "

GSOC posted the list of selected organization for GSOC 2013 and I am highly happy that FreeBSD is among the selected organization. I am a third year student interested to work in the field of embedded system. I applied last year and the title of my project was " Kernel Size Reduction for Emb

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

1) tar up files 2) encrypt tarball 3) copy encrypted tarball with rcp, ftp, uucp, ... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@free

[ GSOC ] Project: Parallelization in the ports collection

Hello Community. My name is Alexander Pronin. I am a GSOC student at The FreeBSD Project. My project is "Parallelization in the ports collection and pkgng utility" I have created wiki page where I described problems that I have to solve and approaches to solving this problem

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

return (NULL); } Adding HTTP PUT support to libfetch would be cool, but I doubt that it's worth wasting GSoC time for that. Most people use curl for that just because Google tells them to. On the other hand, SSH is available in FreeBSD system in 99% of use cases, and it would be quite easy to

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

On 19-5-2012 5:54, Tim Kientzle wrote: > > On May 18, 2012, at 7:51 AM, Mel Flynn wrote: > >> On 17-5-2012 14:53, Mateusz Guzik wrote: >>> On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote: >> Nice. What about curl over the HTTPS protocol? >>> >>> curl would be ok, exc

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

On May 18, 2012, at 7:51 AM, Mel Flynn wrote: > On 17-5-2012 14:53, Mateusz Guzik wrote: >> On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote: > >>> Nice. What about curl over the HTTPS protocol? >>> >> >> curl would be ok, except it's not in the base system. > > For this re

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

hi, first of; grats on getting the project. very interesting. > * Can you recommend a secure way of sending a report from a FreeBSD system > to the Central Collector machine? i don't know if the use of a gnu tool would conflict with FreeBSD politics but you could use tar(1) or an equivalent and G

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

On 17-5-2012 14:53, Mateusz Guzik wrote: > On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote: >> Nice. What about curl over the HTTPS protocol? >> > > curl would be ok, except it's not in the base system. For this reason, it's probably best to use tar(1) to package up multiple

Re: GSoC Project: EFI on amd64/i386

On 17.05.2012 17:28, Eric McCorkle wrote: >> As i see we already have sys/boot/efi/libefi/efipart.c that uses >> EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL >> provides access to each disk and partition. AFAIK it supports only >> GPT and MBR+EBR, so there might be some problem

Re: GSoC Project: EFI on amd64/i386

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/12 13:35, Eric McCorkle wrote: > Hello everyone, > > I'm going to be working on EFI boot support on the amd64/i386 > platforms as a GSoC project. The idea is to allow booting from > EFI (as opposed to legacy BIOS) on

Re: GSoC Project: EFI on amd64/i386

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/17/12 10:36, John Baldwin wrote: >> Do the kernel and modules actually do anything that depends on >> being in a contiguous space in some way (ie some relocation >> trick)? Because it seems like it shouldn't really matter >> otherwise. > > The

Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion

On Wednesday, May 16, 2012 10:00:33 am Mateusz Guzik wrote: > Are you going to support textdumps? > > I would like to note that some machines have swap space only for > textdumps, so I think you should support these. > > ddb is equiped with a lot of cool commands that show various important > deb

  1   2   3   4   5   >