Re: Video memory as swap under FreeBSD

[Alexander Motin]

Dag-Erling Smørgrav пишет:

Arne Schwabe <[EMAIL PROTECTED]> writes:

VIdeo RAM may also not be as stable as your main RAM. I mean nobody if a
bit flips in video ram.


That may have been true fifteen years ago, but not today.


Have the anybody ever seen ECC video RAM? Video RAM usually works on 
higher frequencies then main RAM and IMHO it must affect stability. For 
video RAM some percent of errors is really less important, I have seen 
it myself with my previous video card until it died completely.


--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Video memory as swap under FreeBSD

[Achim Patzner]

Am 14.10.2007 um 10:24 schrieb Alexander Motin:


Dag-Erling Smørgrav пишет:

Arne Schwabe <[EMAIL PROTECTED]> writes:
VIdeo RAM may also not be as stable as your main RAM. I mean  
nobody if a

bit flips in video ram.

That may have been true fifteen years ago, but not today.


Have the anybody ever seen ECC video RAM?


Lots. Maybe you're just not old enough but some people can still  
remember

TIGA. You could even use them as separate processor...


Achim

Re: Video memory as swap under FreeBSD

[Erich Dollansky]

Hi,

Achim Patzner wrote:


Am 14.10.2007 um 10:24 schrieb Alexander Motin:


Dag-Erling Smørgrav пишет:

Arne Schwabe <[EMAIL PROTECTED]> writes:
VIdeo RAM may also not be as stable as your main RAM. I mean nobody 
if a

bit flips in video ram.

That may have been true fifteen years ago, but not today.


Have the anybody ever seen ECC video RAM?


Lots. Maybe you're just not old enough but some people can still remember
TIGA. You could even use them as separate processor...


do you talk about the SPEA fire?

Those days, it was even possible to talk to the CEO of a company.

Erich

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Project Ideas and a question

[Alexander Leidinger]

Quoting David Naylor <[EMAIL PROTECTED]> (Sat, 13 Oct 2007 09:59:45 +0200):

> I have some project ideas (due to lack of technical skills I can not pursue 
> them at this time but that is no reason not to share :-).  If someone thinks 
> an idea is a good one could you please add it to the appropriate location 
> (the volunteer projects page???).  My ideas:
> 
> 1) Automatic module loading.  Create a discovery system that upon identifying 
> hardware that a module supports, loads the module.  This would probably be a 
> user-land implementation? 
>   Motivation: Additional ease of use (especially with sound)

You don't always want to have every device active. What about a
modification to this: Create a discovery system that upon identifying
hardware that a module supports, prints out corresponding lines for
loader.conf and/or the kernel config.

> 2) Automatic kernel customisation.  A tool that builds a custom kernel with 
> all the devices for the current system builtin and with everything not needed 
> removed.  
>   Motivation: Take the hard work out of building a custom kernel]

How do you determine what is not needed? You may want to have some more
USB drivers in the tree even when not everything is connected ATM. The
same for wlan crypto stuff or other optional things. What about a
modification again: Create a tool that prints out all kernel modules
which are not in active use currently.

A tool can not replace the knowledge someone needs about a particular
subsystem of the kernel. Such a tool would allow you to identify things
you are not using currently, but you are still in charge to decide if
you really want to remove it or not.

Bye,
Alexander.

-- 
In 1962, you could buy a pair of SHARKSKIN SLACKS, with a "Continental
Belt," for $10.99!!
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Creating install CD with custom ports - how to massage INDEX file?

[Clifton Royston]

  I've been building my own install CDs for a planned multi-server
upgrade to 6.2Rp8 and ran into one last stumbling block this week.  I
understand the process a lot better now than I did a few years back
when I was doing it for 4.8, but I'm still having trouble pieceing
together how I get my own package set onto the CD in a usable form.

  I built the release with NO_PORTS=yes, because I'm building the ports
from my own CVS tree, which is a tightly pared down subset of the
/usr/ports CVS, plus locally written software in ports format.  I've
ensured that the tree is closed under the dependency operation (to use
some math jargon) - essentially that means that my ports subset includes
all the dependencies of every port I'm including and all of *its*
run/build dependencies in the tree, even if not being built.  That
allows the dependency graph to be calculated and the INDEX-6 file to be
built properly.

  However, copying the INDEX-6 file and my private packages hierarchy
into the CD build area doesn't work; I can read them off the CD
post-install but sysinstall doesn't see them.  It's not a disaster
because I can always put the CD back in after booting and install them
then, but it would would be nice to get them all zapped in with the
initial install.

  I think from reading the assorted documentation and people's notes on
release-building that the problem is that the INDEX-6 file needs to be
massaged into a slightly different format for sysinstall, and I am not
clear on the right way to do that for an existing package set, if
you're not doing it via the release "build everything" approach and not
working off the vanilla ports CVS.  To simplify matters further, it all
fits on disc 1 - it's not a big file set, so it doesn't need to be
split onto multiple disks.

  I've looked through the many fine manuals here, here, and here:
 


  (This last comes tantalizingly close but doesn't get me quite there
  because it doesn't clarify under what directories or hierarchies these
  scripts should be installed and run, especially if you have a
  complete package set built.)

  This probably boils down to just one "make release" subcommand I need
to give at the right stage, after putting my copied ports tree and/or
package tree in the right magic place, but I'm not getting it.  I'd
appreciate a hint from anybody who knows this step. 

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

A more tenuously package-related question

[Clifton Royston]

  I used to use pkg_update from the 'pkg_install-devel' toolset to
upgrade systems via replacement of binary packages.  Its implementation
had some minor flaws - it was essentially a perl wrapper for an
iterative "pkg_delete -f" followed by "pkg_add -f", which made it
problematic to upgrade either the perl or pkg_install packages, for
instance - but the core idea was excellent.  Despite those flaws it was
very useful in maintaining servers via binary packages, because it
would reconnect the pkgdb dependencies on the old package version to
the new package version.  However, it's not part of the current base
package tools.

  Is there any better equivalent tool at the moment, or should I just
resuscitate the old "pkg_update"?  I browsed through
/usr/ports/ports-mgmt, but didn't spot anything which did this
seemingly simple and important function.  (The "pkg_replace" function
*sounds* promising but has almost no information on what it actually
does.)

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: A more tenuously package-related question

[Clifton Royston]

On Sun, Oct 14, 2007 at 04:05:20PM -0700, [EMAIL PROTECTED] wrote:
> 
> >   I used to use pkg_update from the 'pkg_install-devel' toolset to
> > upgrade systems via replacement of binary packages.  Its
> > implementation had some minor flaws - it was essentially a perl
> > wrapper for an iterative "pkg_delete -f" followed by "pkg_add -f",
> > which made it problematic to upgrade either the perl or pkg_install
> > packages, for instance - but the core idea was excellent.  Despite
> > those flaws it was very useful in maintaining servers via binary
> > packages, because it would reconnect the pkgdb dependencies on the
> > old package version to the new package version.  However, it's not
> > part of the current base package tools.
> > 
> >   Is there any better equivalent tool at the moment, or should I just
> > resuscitate the old "pkg_update"?
> 
> Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P`
> for binary updates. Besides actual 'portupgrade', it has a set of
> useful tools, too. But be warned -- the utility is snail-slow.

  I did look at it, but it appeared that it needed to run off the
FreeBSD ports tree, whereas I'm building packages from a separate
instance of the ports tree in our own CVS, with local modifications,
and then deploying these packages on multiple servers.  (This time
around, I'm planning to not even install the ports tree on servers
other than the build server.)  I therefore need to use a utility which
can operate using only the dependency information in the pkgdb and
embedded in the package files themselves.

  After posting before, I decided to explore pkg_replace, and it
appears that it might be able to do what I want with the right options.

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: A more tenuously package-related question

[soralx]

>   I used to use pkg_update from the 'pkg_install-devel' toolset to
> upgrade systems via replacement of binary packages.  Its
> implementation had some minor flaws - it was essentially a perl
> wrapper for an iterative "pkg_delete -f" followed by "pkg_add -f",
> which made it problematic to upgrade either the perl or pkg_install
> packages, for instance - but the core idea was excellent.  Despite
> those flaws it was very useful in maintaining servers via binary
> packages, because it would reconnect the pkgdb dependencies on the
> old package version to the new package version.  However, it's not
> part of the current base package tools.
> 
>   Is there any better equivalent tool at the moment, or should I just
> resuscitate the old "pkg_update"?

Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P`
for binary updates. Besides actual 'portupgrade', it has a set of
useful tools, too. But be warned -- the utility is snail-slow.


>   -- Clifton

[SorAlx]  ridin' VS1400
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Project Ideas and a question

[Tim Clewlow]

--- David Naylor <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> The question first: init does allow a chroot before booting the system
> however 
> does it allow the first device to be unmounted and use the new chroot as the 
> root device.  If it does how can that be achieved.  
> 
> My motivation for this: Allow a USB device or CDROM to boot the system, then 
> init running of the removable device to execute a script that will allow the 
> system to be setup (such as configure devices, setup gdbe and geli, etc) then
> 
> when init chroot's it unmounts the removable device and allows that device to
> 
> be physically removed.  
> 
> I have some project ideas (due to lack of technical skills I can not pursue 
> them at this time but that is no reason not to share :-).  If someone thinks 
> an idea is a good one could you please add it to the appropriate location 
> (the volunteer projects page???).  My ideas:
> 
> 1) Automatic module loading.  Create a discovery system that upon identifying
> 
> hardware that a module supports, loads the module.  This would probably be a 
> user-land implementation? 
>   Motivation: Additional ease of use (especially with sound)
> 
> 2) Automatic kernel customisation.  A tool that builds a custom kernel with 
> all the devices for the current system builtin and with everything not needed
> 
> removed.  
>   Motivation: Take the hard work out of building a custom kernel]
> 
> 3) If question above is not implemented than add to idea list...
> 
> Feedback is welcome.  Thank you for listening to me.  
> 
> David

Hello David,

These all sound like great ideas, however they may have a better chance of
being implemented on one of the sibling versions of FreeBSD, ie "Desktop BSD"
or "PC BSD". These offerings have already made quite large steps in regard to
automating the installation of a BSD system. The general aim is to make it as
easy as possible for someone unfamiliar with BSD to install a desktop, ie so it
can compete with other desktop operating systems that are already very easy to
install.

By contrast, the native version of FreeBSD is put to many uses, often not
involving a desktop, eg servers, routers, embedded systems. The ability to
customize/tune pretty much all of the kernel/world is what makes this possible.
And so having an automated installation would have to be unbelievably
intelligent, and complicated, in order to cater for all these possibilities.

Lastly, keep going with the new ideas, they are always welcome. Perhaps you may
 want to send them to [EMAIL PROTECTED] as this would seem to be more
appropriate for initial ideas postings - and more people will see them as well
:-)

Kind Regards, Tim.


  

Tonight's top picks. What will you watch tonight? Preview the hottest shows on 
Yahoo! TV.
http://tv.yahoo.com/ 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"