[PC-BSD Dev] Dev Digest, Vol 22, Issue 3
yerenkow at uct.ua
Wed Dec 3 23:34:21 PST 2008
On 04.12.2008 2:36, Eric Nicholson wrote:
> On Wed, Dec 3, 2008 at 3:00 PM,<dev-request at lists.pcbsd.org> wrote:
>> Send Dev mailing list submissions to
>> dev at lists.pcbsd.org
>> To subscribe or unsubscribe via the World Wide Web, visit
>> or, via email, send a message with subject or body 'help' to
>> dev-request at lists.pcbsd.org
>> You can reach the person managing the list at
>> dev-owner at lists.pcbsd.org
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Dev digest..."
>> Today's Topics:
>> 1. Re: Meeting&& questions (Kris Moore)
>> Message: 1
>> Date: Tue, 02 Dec 2008 15:14:21 -0500
>> From: Kris Moore<kris at pcbsd.com>
>> Subject: Re: [PC-BSD Dev] Meeting&& questions
>> To: "A.Y."<yerenkow at uct.ua>
>> Cc: dev at lists.pcbsd.org
>> Message-ID:<4935971D.4050007 at pcbsd.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> A.Y. wrote:
>>> Hello all! how about make a small meeting-talk on irc at this week?
>>> I'm free to any time.
>> Sure! Lets plan for early next week if possible. I've still got a ton of
>> stuff to get finished this week, after the Holiday last week :) Does
>> Tuesday next week work for you?
>>> And I have some questions.
>>> 1. Remember we were discussing about making smart gui "settings editor
>>> for services" based on some definition? Is anyone looks into?
>>> I thought about this, we could make a very general-use GUI for any
>>> configuration files, that could be useful in future;
>>> Currently I'm planning a project which will make a listener to
>>> filesystem, and will trace all changes to specific files; after
>>> file-change, check for syntax, validate, if validator provided, store it
>>> to VCS, propose to user give a label (optional). So, syntax&&
>>> validation part will be a kind of similar to settings options
>>> definition. My goal - "user edit xorg.conf (or whatever), makes there
>>> some mistake, save and - he see alert about syntax error;" or other case -
>>> he changed same xorg.conf, boot unsuccessfull, he see text-based
>>> interface and can choose right-one old saved version;
>> I haven't started coding anything yet, but I think this is a feature we
>> should add to the services tool here soon. If you just want me to setup
>> the services tool to call a provided script / binary when the user
>> clicks on "configure" that would be easy enough to do. However, if we
>> want to do an entire syntax-driven configuration to provide configure
>> gui's, that will take a lot longer, and require a lot of coding.
>>> 2. Is technically possible such thing: on same FS have both i386&&
>>> amd64 files, for example
>>> /boot32 /bin32, /lib32, /libexec32...
>>> /boot64 /bin64, /lib64, /libexec64...
>>> and while booting choose one or other kernel?
>>> if make changes in /etc/login.conf and whatever :)
>>> Or, if this isn't possible - how about make two partition for both 32&
>>> 64 versions root and one partition for home?
>> I've not seen this done in BSD before, it may be possible, but I don't
>> know how much hacking it would require :P
>> I would think that the easiest thing to do would be 3 partition route,
>> x32 and x64, then a home partition. But again, I',m not sure what kind
>> of loader.conf tweaks will be needed to boot from either. If you can get
>> one working, let me know and maybe we can support something like that
>> down the road.
> If you are talking simply having 32 / 64bit files being executed, then
> can't you just just include the 32/64 libs that are required?
> As far as booting a 32/64 kernel, I think a sufficent loader.conf
> file could handle a kernel choice, as long as the libs are there
> to support 32/64 environemnt, then either should work.
>>> 3. If we have 2gb installation image for usb, why not create 5-6Gb image
>>> of already installed PC-BSD, useage will be the same, dd to usb stick,
>>> and we have live sluggish system :)
>>> BTW, for DVD-live system we need writeable /home/user&& /tmp, is this
>>> all? could we make it too in 4,3Gb?
>> I think it would be possible to do that, have a pre-built usb image
>> which can be copied with dd to a media, and booted from. As for DVD, its
>> a bit different, since we may need to do a uzip compressed FS to load
>> from disk, so there's enough room for it all. Maybe even do the same
>> thing with the USB media, so you can fit it into a 4GB USB stick or
> Correct me if I'm wrong, but from my research, to boot from USB the USB
> stick/flash drive would need to have a VFAT ( DOS ) filesystem for
> the system bios
> to recognize the USB stick/flash as a boot device then intialize the
> boot process.
> Is this possible in PC-BSD at the moment?
> Having a bootable USB stick/flash drive would be very nice!
I think it's depends on exact BIOS.
At all my places where I can check - I could successfully boot from
USB-FAT, USB-UFS, Cardreader-CF-UFS, Internal SD cardreader-UFS.
Currently I have Corsair voyager GT-16gb with installed PC-BSD, and it
In theory making a bootable image is not difficult - install PC-BSD to
totally free HDD (real or virtual) with size that we need, and then dd
it to file.
Maybe before that cut some docs or else, to shrink a bit.
>>> 4. About wine&& gaming, did you guys thought about specific wine build
>>> included in system, which will be updated a bit rarely?
>> Do you mean have one integrated, or just installed as we do now with the
>> wine PBI? The only problem I've seen with integrating it, is that wine
>> changes so often, and has so many regressions that whenever we would
>> issue an online update to the base system, it could break the users wine
>> programs. At least with the PBI method of wine, they can downgrade back
>> to a previous wine release when a regression occurs :)
>>> 5. new AsusEEEs have specific ethernet;
>>> Here are patch to src with driver.
>>> I don't know how automated all system builds on server, so question is:
>>> Is this possible to build patched kernel, and make it in PBIformat, or
>>> in plain archive, and put it on pbidir.com, so users could test it?
>> Has this patch been MFC to 7-Stable yet? I may be able to include it in
>> 7.0.2 or 7.1 when it is :)
>> As for a patch, you can build the kernel, and just tar bzip it for users
>> to test. I wouldn't want to list it on pbidir, since thats more of a
>> hard-core testing patch for users who want to try it out :)
>> Dev mailing list
>> Dev at lists.pcbsd.org
>> End of Dev Digest, Vol 22, Issue 3
> Dev mailing list
> Dev at lists.pcbsd.org
More information about the Dev