Re: Some questions about Link Aggregation and Failover
Sorry top post, not so smartphone. Do this on your c3750, in privileged mode: Show ether 1 sum On 7 Mar 2012, at 05:41, bo wang wowo...@gmail.com wrote: Hello: Recently I want to do Link Aggregation for increasing the speed. I use a Cisco 3750 Switche and two IBM Server R with BSD 9.0 .I do link aggregation According to this page. http://www.freebsd.org/doc/en/books/handbook/network-aggregation.html I use LACP .But when i have done ,the link aggregation only can do Failover .It cann't increase the speed. What is the problem?Detailed configuration as follows in the BSD9.0 /etc/rc.conf hostname=bbc04 ifconfig_bce2=up ifconfig_bce3=up ifconfig_bce4=up ifconfig_bce5=up ifconfig_bce6=up ifconfig_bce7=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto loadbalance laggport bce2 laggport bce3 laggport bce4 laggport bce5 laggport bce6 laggport bce7 ipv4_addrs_lagg0=172.16.60.64/16 defaultrouter=172.16.0.1 sshd_enable=YES pureftpd_enable=YES # Set dumpdev to AUTO to enable crash dumps, NO to disable dumpdev=NO the Cisco 3750 configure interface range gigabitEthernet 1/0/1-6 channel-proto lacp channel-group 1 mode active interface range gigabitEthernet 1/0/13-18 channel-proto lacp channel-group 2 mode active ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Why you have to install a port to create a package (was Re: port to package amd64 to i386)
On 07/03/2012 01:39, Da Rock wrote:
On 03/07/12 04:13, Adam Vande More wrote:
On Tue, Mar 6, 2012 at 11:36 AM, Bernt Hanssonb...@bananmonarki.se
wrote:
Again, a problem is that packages can only be generated
if the port has been installed
Why is that. I hope you can educate me on that.
Because a package is the result of what is installed. It
essentially works somewhat like Debian's checkinstall by keeping
track of what's installed by the installation script, then using
the info of what's installed to build the package. I'm not exactly
sure how make package works internally, but it wouldn't surprise
me if it's almost the same as pkg_create -b.
From what I understand of ports (as a maintainer) that is the case; plus
some other bits and pieces for checking, verification, and cleanup.
DaRock has the essentials of how it works correct. When a port is
installed, the first step is to install the software, typically using
the standard install target from upstream, although it's not unusual for
the port to just copy files into place itself[*].
That miscellaneous collection of files is then turned into a package by
collecting the data on file names and checksums in the packing list, the
package comment, any install messages or install/deinstall scripts into
the package directory /var/db/pkg/pkgname-0.99 If you're interested,
this stage is dealt with by the 'fake-pkg' target in bsd.ports.mk
[[pkgng works almost identically, except the data is stored in a sqlite
DB rather than separate directories in the filesystem.]]
Note that technically, a package is that combination of the collection
of files and the metadata about those files in the package registry. A
package can be in two different states: installed, with the files spread
around the directory tree or as a tarball -- for the original pkg
format, /var/db/pkgname-0.99 and all the files owned by the package;
for pkgng, the metadata is held as a YAML file. pkg_add(1) converts
from the tarball to the installed state, 'pkg_create -b' goes in the
other direction. The difference between 'make install' and 'make
package' in the ports is simply the addition of a final pkg_create
step.
Now, there is no a priori reason why all of this has to be done using
the live /usr/local directory tree on your system. OpenBSD ports has
entirely switched to using a chroot for building package tarballs, and
in fact the FreeBSD package build cluster and Tinderbox basically work
that way already. The procedure is to install all of the required
{FETCH,PATCH,BUILD,RUN,PKG} dependencies into a chroot filesystem (from
previously built package tarballs), install the port into the same
chroot and generate a package tarball from it.
There are advantages and disadvantages either way. Building in a chroot
requires a lot more copying files around and general faff. On the other
hand; it makes it easier to build as a non-privileged user, it makes
cross-building for different architectures feasible and it completely
avoids problems to do with software arbitrarily deciding to link against
random shared libraries it finds around the system -- or indeed to
accidentally use header files from a completely different piece of
software. Converting ports to build in a chroot is one of those ideas
that is constantly bubbling up, but that never quite seems to get
implemented.
Cheers,
Matthew
[*] For completeness, the 'port' is the collection of instructions for
downloading the sources, patching, building and installing the software,
managing the dependency hierarchy required to do all that and dealing
with tracking all those files by creating the package metadata.
Although it is common to speak of 'installing a port' in fact what gets
installed is a package, and it is the port that does the installing.
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Building a releng_9_0 with sysinstall, livefs and mfsroot
Good morning, Have just sent to freebsd-hackers mailing list the way of doing this. I say this because perhaps could be useful for someone... Best regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Dynamic Libraries
I have encountered something that I do not understand. Everything works fine. Basically I have a bunch of user modules (low level) that are built into a dynamic library. If I write top level code that calls modules in that library, everything works just fine on i386 and AMD64. However, the application involved has another library of modules. Some of them call modules in the low level library. The top level code call modules in both libraries. Often when it calls a module in the mid level library, that module calls several modules in the low level library. All this works just fine on i386. However, when I compile everything on AMD64 I get an error message that says the lower level library needs to be compiled with fPIC. If I add that to the Makefile for the lower level library and rebuild everything, it all works again. I don't understand why the fPIC is required for AMD64. Also, how do I tell if the lower level library is being dynamically linked at run time, or being directly incorporated into the mid level library or top level application? Since both of these libraries are quite large, and they are in use by a number of top level applications, I want just one copy to exist in physical memory.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dynamic Libraries
Doug Hardie wrote: I have encountered something that I do not understand. Everything works fine. Basically I have a bunch of user modules (low level) that are built into a dynamic library. If I write top level code that calls modules in that library, everything works just fine on i386 and AMD64. However, the application involved has another library of modules. Some of them call modules in the low level library. The top level code call modules in both libraries. Often when it calls a module in the mid level library, that module calls several modules in the low level library. All this works just fine on i386. However, when I compile everything on AMD64 I get an error message that says the lower level library needs to be compiled with fPIC. If I add that to the Makefile for the lower level library and rebuild everything, it all works again. I don't understand why the fPIC is required for AMD64. Also, how do I tell if the lower level library is being dynamically linked at run time, or being directly incorporated into the mid level library or top level application? Since both of these libraries are quite large, and they are in use by a number of top level applications, I want just one copy to exist in physical memory. This sounds exactly like compiling with clang through ccache. There are issues with clang and ccache cooperation. Actually the one you may hit is libtool detecting implicit fPIC requirement when running clang through ccache. -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 8.2 - active plus inactive memory leak!?
On Wed, 2012-03-07 at 10:23 +0200, Konstantin Belousov wrote: On Wed, Mar 07, 2012 at 12:36:21AM +, Luke Marsden wrote: I'm trying to confirm that, on a system with no pages swapped out, that the following is a true statement: a page is accounted for in active + inactive if and only if it corresponds to one or more of the pages accounted for in the resident memory lists of all the processes on the system (as per the output of 'top' and 'ps') No. The pages belonging to vnode vm object can be active or inactive or cached but not mapped into any process address space. Thank you, Konstantin. Does the number of vnodes we've got open on this machine (272011) fully explain away the memory gap? Memory gap: 11264M active + 2598M inactive - 9297M sum-of-resident = 4565M Active vnodes: vfs.numvnodes: 272011 That gives a lower bound at 17.18Kb per vode (or higher if we take into account shared libs, etc); that seems a bit high for a vnode vm object doesn't it? If that doesn't fully explain it, what else might be chewing through active memory? Also, when are vnodes freed? This system does have some tuning... kern.maxfiles: 100 vm.pmap.pv_entry_max: 73296250 Could that be contributing to so much active + inactive memory (5GB+ more than expected), or do PV entries live in wired e.g. kernel memory? On Tue, 2012-03-06 at 17:48 -0700, Ian Lepore wrote: In my experience, the bulk of the memory in the inactive category is cached disk blocks, at least for ufs (I think zfs does things differently). On this desktop machine I have 12G physical and typically have roughly 11G inactive, and I can unmount one particular filesystem where most of my work is done and instantly I have almost no inactive and roughly 11G free. Okay, so this could be UFS disk cache, except the system is ZFS-on-root with no UFS filesystems active or mounted. Can I confirm that no double-caching of ZFS data is happening in active + inactive (+ cache) memory? Thanks, Luke -- CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Intel PCI Serial Port - no driver attached
Hello,
Intel AMT Serial over LAN does not work in FreeBSD.
PCI Serial Port device - no driver attached - ttyuX not added to system.
# pciconf
Current:
none1@pci0:0:3:3: class=0x070002 card=0x10048086 chip=0x2e178086 rev=0x03
hdr=0x00
But should be:
uart0@pci0:0:3:3: class=0x070002 card=0x10048086 chip=0x2e178086 rev=0x03
hdr=0x00
Links:
http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033504.html - not
solved.
http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057494.html - not
solved.
http://sourceforge.net/projects/openamt/ - Linux HECI-driver project. Not SOL
driver!
Intel AMT SOL work in Linux.
Linux default pci2uart bridge driver supports the operation of the device:
http://linux.die.net/man/7/amt-howto ===
If you have activated AMT and SOL the linux kernel should see an additional
serial port, like this on my machine:
# dmesg | grep ttyS2
:00:03.3: ttyS2 at I/O 0xe000 (irq = 169) is a 16550A
Issuing a
# pciconf
results in FreeBSD 8.X (device puc uart included in kernel):
none1@pci0:0:3:3: class=0x070002 card=0x10048086 chip=0x2e178086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel PCI Serial Port (CC_0700)'
class = simple comms
subclass = UART
Issuing a
# pciconf
results in FreeBSD 9.X (device puc uart included in kernel):
none1@pci0:0:3:3: class=0x070002 card=0x10048086 chip=0x2e178086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = '4 Series Chipset Serial KT Controller'
class = simple comms
subclass = UART
Ubuntu info:
*-communication:1
description: Serial controller
product: 4 Series Chipset Serial KT Controller
vendor: Intel Corporation
physical id: 3.3
bus info: pci@:00:03.3
version: 03
width: 32 bits
clock: 66MHz
capabilities: pm msi 16550 bus_master cap_list
configuration: driver=serial latency=0
resources: irq:17 ioport:ecb8(size=8) memory:fdfda000-fdfdafff
# ndisgen
Windows Intel AMT SOL (PCI Serial Port device) driver (from
MEI_AMT_ALLOS_6.1.0.1042_PV, 2009 or from LMS_SOL_AllOS_5.4.0.1065_PV, 2007) -
not possible.
FreeBSD change source:
/sys/dev/puc/pucdata.c
{ 0x8086, 0x2e17, 0x8086, 0x1004,
Intel PCI Serial Port (CC_0700),
DEFAULT_RCLK,
PUC_PORT_1S, 0x10, 0, 0,
},
No effect... :(
Full Datasheet.
http://www.intel.com/content/www/us/en/processors/xeon/4-chipset-family-datasheet.html
- Serial Port for Remote Keyboard and Text (KT) Redirection.
What are the correct settings from Datasheet be substituted into:
/sys/dev/puc/pucdata.c
???
P.S.
1. IPMI Serial over LAN driver (extended LAN interface) and Intel AMT hardware
SOL (internal PCI Serial Port device) - this is different technology!
2. Fulltext discussion: http://forums.freebsd.org/showthread.php?t=30252
Regards, Bulanov Vladimir.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 8.2 - active plus inactive memory leak!?
On Wed, 07 Mar 2012 10:23:38 +0200, Konstantin Belousov wrote: On Wed, Mar 07, 2012 at 12:36:21AM +, Luke Marsden wrote: ... I'm trying to confirm that, on a system with no pages swapped out, that the following is a true statement: a page is accounted for in active + inactive if and only if it corresponds to one or more of the pages accounted for in the resident memory lists of all the processes on the system (as per the output of 'top' and 'ps') No. The pages belonging to vnode vm object can be active or inactive or cached but not mapped into any process address space. I wonder if some ideas by Denys Vlasenko contained in this thread http://comments.gmane.org/gmane.linux.redhat.fedora.devel/157706 would be useful ? ... Today, I'm looking at my process list, sorted by amount of dirtied pages (which very closely matches amount of malloced and used space - that is, malloced, but not-written to memory areas are not included). This is the most expensive type of pages, they can't be discarded. If we would be in memory squeeze, kernel will have to swap them out, if swap exists, otherwise kernel can't do anything at all. ... Note that any shared pages (such as glibc) are not freed this way; also, non-mapped pages (such as large, but unused malloced space, or large, but unused file mappings) also do not contribute to MemFree increase. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Single boot EFI Mac install
Has anyone successfully installed FreeBSD as a single boot system on an EFI Mac? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Is it worthy upgrading to 9.0 ?
On 3/6/12 12:30 PM, krad wrote: apart from a major bump in the version of pf. Still the old syntax though, what I'm eager for is 10.0 with the upgrade to 4.8 openbsd PF. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Network interface aliasing?
Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. Thanks Brent ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network interface aliasing?
On 07/03/2012 14:39, Brent Clark wrote: I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. Yes, you can have alias addresses very easily: ifconfig em0 inet 192.0.2.2/24 alias or in /etc/rc.conf: ipv4_addrs_em0=192.0.2.1/24 192.0.2.2/24 (But I think this is what you mean by IP aliasing?) Since this is BSD, we don't have the SysV-ish idea of separate devices just for aliases. In fact, in *BSD once you've added the alias, it's just one of the addresses on the interface, co-equal with all the others. You could go on to remove the original address, which makes it easy to renumber a host without downtime. You usually don't need a separate device in any case: just configuring a daemon to listen using a specific IP is all that is needed for almost all purposes. What exactly is it you are trying to achieve and why isn't it suitable to use aliases as above? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Network interface aliasing?
On 03/07/2012 03:39 PM, Brent Clark wrote: Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. What do you want to accomplish? Processes usually listen on adresses or sockets Disclaimer: http://www.ose.nl/email ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 8.2 - active plus inactive memory leak!?
On Wed, 2012-03-07 at 13:33 +0100, J B wrote: On Wed, 07 Mar 2012 10:23:38 +0200, Konstantin Belousov wrote: On Wed, Mar 07, 2012 at 12:36:21AM +, Luke Marsden wrote: ... I'm trying to confirm that, on a system with no pages swapped out, that the following is a true statement: a page is accounted for in active + inactive if and only if it corresponds to one or more of the pages accounted for in the resident memory lists of all the processes on the system (as per the output of 'top' and 'ps') No. The pages belonging to vnode vm object can be active or inactive or cached but not mapped into any process address space. I wonder if some ideas by Denys Vlasenko contained in this thread http://comments.gmane.org/gmane.linux.redhat.fedora.devel/157706 would be useful ? https://github.com/pixelb/scripts/blob/master/scripts/ps_mem.py This looks like a really useful script, and looks like it works under FreeBSD with linprocfs. Good find! Cheers, Luke ... Today, I'm looking at my process list, sorted by amount of dirtied pages (which very closely matches amount of malloced and used space - that is, malloced, but not-written to memory areas are not included). This is the most expensive type of pages, they can't be discarded. If we would be in memory squeeze, kernel will have to swap them out, if swap exists, otherwise kernel can't do anything at all. ... Note that any shared pages (such as glibc) are not freed this way; also, non-mapped pages (such as large, but unused malloced space, or large, but unused file mappings) also do not contribute to MemFree increase. jb -- CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network interface aliasing?
On 3/7/12 9:39 AM, Brent Clark wrote: Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. Thanks Brent Brent, You can rename an interface to just about anything you wish. If the process allows for interface binding then you can use that new name. http://jafdip.com/index.php/2008/09/08/renaming-ethernet-interfaces-under-freebsd-7x/ Regards, Mikel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network interface aliasing?
On 03/07/2012 04:24 PM, Mikel King wrote: On 3/7/12 9:39 AM, Brent Clark wrote: Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. Thanks Brent Brent, You can rename an interface to just about anything you wish. If the process allows for interface binding then you can use that new name. http://jafdip.com/index.php/2008/09/08/renaming-ethernet-interfaces-under-freebsd-7x/ This gives the interface a different name. It does not create an alias name for the interface as far as I understand. Kind regards, Bas Disclaimer: http://www.ose.nl/email ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Still having trouble with package upgrades
I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade and all at once system wide upgrades actually for reasons are inferior, in that it meant often months would go by before a software program was updated, delying the application of vital security fixes. Before the age of the internet and the hacker, that may have been acceptable. Its not anymore. With Firefox and Flash for instance, security fixes are made sometimes weekly, with an system wide at once upgrade model, it could be a very long time between upgrades of such software between releases of the OS software distribution CD. The idea of waiting on a FreeBSD kernel release to upgrade firefox is absurd, and the idea that firefox must be upgraded during a kernel upgrade is also absurd. The piecemeal
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 11:50 AM, tho...@sanbe-farma.com wrote: Hmm what is the problem ? Is there a log or something that you can share ? Usually portsnap, freebsd-update, pkg_add -r or portupgrade that do binary update should be enough Ive tried them all. I will work on getting some logs to post here shortly Regards Sent from my BlackBerry® smartphone from Sinyal Bagus XL, Nyambung Teruuusss...! -Original Message- From: David Jackson djackson...@gmail.com Sender: owner-freebsd-questi...@freebsd.org Date: Wed, 7 Mar 2012 11:28:47 To: freebsd-questions@freebsd.org Subject: Still having trouble with package upgrades I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade
Re: Still having trouble with package upgrades
David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) However, when considerations of law enter the field, the problem becomes obvious: There are situations, depending on local national law or software licnsing, when it is not possible to include certain functionality by default. You know, I'd _love_ to pkg_add -r mplayer to get mplayer and mencoder with _all_ the codecs so it can play everything. Sadly, that is not the default situation. You can also encounter similar barriers with Linux when you install a distribution, and many things work out of the box, but as soon as you cross a certain line (i. e. you want to access specific media formats), you need to add something to your installation. That shouldn't be neccessary, and it is not neccessary from a technical point of view, but legal objections seem to demand it it's artificially made impossible... If people want customisations then they can build the software for themselves. That's what they'll do anyway. :-) Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. When a new kernel is released, there is no reason to reinstall all of the packages on the system at the same time. Since the kernel and userland packages have different development cycles, there is no reason why there has to be synchronization of the upgrading. It sometimes is neccessary, for example if kernel interfaces have changed. There is some means of compatibility provided by the compat_ ports. But if you start upgrading things, libraries can break, and the system may become unstable (in terms of not being able of running certain programs anymore). Just see how kernel and world are out of sync errors can even cause the system to stop booting. Degrading the inner workings of the OS to just another package can cause trouble. Simple updates as they are often performed on Linux systems can render the whole installation totally unusable because something minor went wrong. :-) An OS that requires a user to reinstall everything just to upgrade the kernel is not user friendly. Why do consider a user being supposed to mess with kernels? This question can show that I'm already too old: Programs are for users, kernels are for sysadmins. Sysadmins do stuff properly, even if they shoot their foot in order to learn an important lesson. :-) As I said before: Updating the kernel _may_ cause many dependency programs (the userland and often the installed 3rd party applications) to become target of updating in order to keep their functionality. New kernel interfaces, changes in ABI or API, new libraries, as well as obsoleted things may be a valid (!) reason. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
Hmm what is the problem ? Is there a log or something that you can share ? Usually portsnap, freebsd-update, pkg_add -r or portupgrade that do binary update should be enough Regards Sent from my BlackBerry® smartphone from Sinyal Bagus XL, Nyambung Teruuusss...! -Original Message- From: David Jackson djackson...@gmail.com Sender: owner-freebsd-questi...@freebsd.org Date: Wed, 7 Mar 2012 11:28:47 To: freebsd-questions@freebsd.org Subject: Still having trouble with package upgrades I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade and all at once system wide upgrades actually for reasons are inferior, in that it meant often months would go by before a software program was updated, delying the application of vital security fixes. Before the
Re: Network interface aliasing?
On Mar 7, 2012, at 10:59 AM, Bas Smeelen wrote: On 03/07/2012 04:24 PM, Mikel King wrote: On 3/7/12 9:39 AM, Brent Clark wrote: Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. Thanks Brent Brent, You can rename an interface to just about anything you wish. If the process allows for interface binding then you can use that new name. http://jafdip.com/index.php/2008/09/08/renaming-ethernet-interfaces-under-freebsd-7x/ This gives the interface a different name. It does not create an alias name for the interface as far as I understand. Kind regards, Bas True but the alias option in BSD only allows for assigning another IP address to an existing interface. Taking a second look at this request it appears to be more of a subinterface phenomenon and not an alias at all. As far as I recall FreeBSD does not support this sort of subinterface naming. But I wonder if there's a way to create pseudo interfaces to pull something similar off, however wonder what's the point. cheers, m ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. I am working on getting the logs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network interface aliasing?
On Wed, Mar 7, 2012 at 8:39 AM, Brent Clark brentgclarkl...@gmail.comwrote: Hiya I would like to ask. Is it possible to, do network interface aliasing. Im not talking about ip aliasing. I basically want to bind one process to network interface vr0:0 and another process to vr0:1. setfib(1) -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 10:28 AM, David Jackson djackson...@gmail.com wrote: I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade and all at once system wide upgrades actually for reasons are inferior, in that it meant often months would go by before a software program was updated, delying the application of vital security fixes. Before the age of the internet and the hacker, that may have been acceptable. Its not anymore. With Firefox and Flash for instance, security fixes are made sometimes weekly, with an system wide at once upgrade model, it could be a very long time between upgrades of such software between releases of the OS software distribution CD. The idea of waiting on a
Re: Single boot EFI Mac install
Carsten Mattner writes: Has anyone successfully installed FreeBSD as a single boot system on an EFI Mac? I'm not sure exactly what you mean by a single boot system. I have Mac Pro that runs Mac OS on on disk (actually a pair in a software RAID) and FreeBSD from another pair (gmirror RAID). I suspect that I could pull the MacOS disks from the system and it would happily run as a FreeBSD only machine. I believe that I set up the disks using the mac tools and then did an install from a DVD, but it's been a while. The only particularly trick-ish part is that I had to partition the FreeBSD disks using MBR style partitions, that's (part of?) what the Mac firmware uses to decide to turn on it's PC-style BIOS emulation, which FreeBSD needs before it can get itself going. GPT partitions will not work. Every once in a while the machine hangs at boot time but I haven't seen it in a while. What happens if you just throw a FreeBSD DVD in the drive? g. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 11:58 AM, Polytropon free...@edvax.de wrote: David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) You are talking about the codec. What Ubuntu seems to do is distribute these codecs as a seperate nonfree addon package which are then loaded by applications at run time. You see, options do not necessarily have to be compiled into programs, they can be loaded at libraries and then loaded by programs at run time if they are available. This is also a rare circumstance, and there are workaround as above. If people want customisations then they can build the software for themselves. That's what they'll do anyway. :-) No, usually they do not. Few people except for hard core geeks want to mess around with compile options. most will use runtime configuration through a GUI which is faster. Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. When a new kernel is released, there is no reason to reinstall all of the packages on the system at the same time. Since the kernel and userland packages have different development cycles, there is no reason why there has to be synchronization of the upgrading. It sometimes is neccessary, for example if kernel interfaces have changed. There is some means of compatibility provided by the compat_ ports. But if you start upgrading things, libraries can break, and the system may become unstable (in terms of not being able of running certain programs anymore). Just see how kernel and world are out of sync errors can even cause the system to stop booting. Degrading the inner workings of the OS to just another package can cause trouble. Simple updates as they are often performed on Linux systems can render the whole installation totally unusable because something minor went wrong. :-) A well designed system will provide backwards compatability through various strategies and this does not necessarily need to affect internal software design as the backwards compatability can also be provided by compatability layers and glue code. Programs communicate with the kernel via interrupts, pushing arguments for the system call onto the stack. The format of this closely matches the source code API. The API is used with the system calling convention. These are mostly mature and do not need to change much. Considering it also a bad practice to create an incompatable system API, there is little reason to change the system call interface. The system call interface has little impact on internal kernel except where adding a new feature can require additional kernel code. Most system calls are mature and do not need to change much. If a system call is needed to provide new functionality, a new system call can be added, which can if needed duplicate the functionality of an older system call. There is also ELF and binary code linking and calling conventions. This can also be maintained to be backwards compatability, if necessary through the use of compatability layers and glue in this process. Another strategy that is unlikely to be needed, since there really is not much reason to make non backwards compatable changes to the current system call set, and is only now used for Linux binary compatability is to mark a binary for a certain system call interface, that system call interface can be backed by glue code to the the main kernel interfaces. Other means of communicating with the kernel which are possible include the /proc interface and as as well UNIX domain sockets. Again if the format of these needs to changed in a non backwards compatable way, a new file or socket can be created at a new location for the new version, the old file or socket location would provide the old interface backed by glue code to the new interface. It is possible to provide backwards compatability through compatability layers and glue code like this, without in anyway impacting the internal design of a kernel or other software system. An OS that requires a user to reinstall everything just to upgrade the kernel is not user friendly. Why do consider a user being supposed to mess with kernels? This question can show that I'm already too old: Programs are for users, kernels are for sysadmins. Sysadmins do stuff properly, even if they shoot their foot in order to learn an important lesson. :-) Users have to upgrade the kernel, with a well designed OS this is a process that does not require any sort of problems for the user. Since good
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 12:42 PM, David Jackson djackson...@gmail.comwrote: Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. Again, if you want to customise your software and build it, fine, I am fully supportive of this flexibility and options being available. For many people however the extra effort to do all of this is just not worth it to save a little RAM by not loading library X. I am saying that all features included up to date prebuilt binaries should be avalable, NOT that this should be the only option. I fully support customized port build facility for those that want it. For people who just want a fully functional everything included binary package, then they should be able to use FreeBSDs binary packages. That will in no way affect your ability to compile your ports and i fully suppoert your right to conmpile your ports and configure them so things that you dont need are not compiled in. So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. I am not dissing or criticising the process of compiling your own ports, if thats what you want, fine, please do. All I am asking for is to be able to use binaries for those who want the binaries and dont want to compile their own stuff. if people dont want to use precompiled stuff, it wont be forced on them, they just compile their own stuff using the ports. I am fine with users having this choice. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
I ran into problems with pkg-upgrade when I upgraded from 8.2p6-9.0-RELEASE, and part of the problem ended up being a tool pkg_upgrade used (uma). That was the reason portupgrade didn't work as well. I ended up hacking the support tool and pkg_upgrade to do what I needed, but they are both definitely broken. iirc, one of the issues with uma was it's url generation. It would generate urls like 9-RELEASE instead of 9.0-RELEASE, the former being the format for 9-STABLE and the later (which I needed) was for an upgrade for a release. Sadly, I've forgotten the other issues, but I remember making about 3 hacks to the tools to get it working. Rob On 3/7/12 11:05 AM, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. I am working on getting the logs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 12:52 PM, Rob li...@midsummerdream.org wrote: I ran into problems with pkg-upgrade when I upgraded from 8.2p6-9.0-RELEASE, and part of the problem ended up being a tool pkg_upgrade used (uma). That was the reason portupgrade didn't work as well. I ended up hacking the support tool and pkg_upgrade to do what I needed, but they are both definitely broken. iirc, one of the issues with uma was it's url generation. It would generate urls like 9-RELEASE instead of 9.0-RELEASE, the former being the format for 9-STABLE and the later (which I needed) was for an upgrade for a release. Sadly, I've forgotten the other issues, but I remember making about 3 hacks to the tools to get it working. Well, thank you for posting. At least its just not me that seen these problems. For me, binary package updates are completely broken. I wonder how this severe and glaring problem got back FreeBSD engineers. It is such an annoying problem. Why cant they just make things work for people who want binary packages? As it is now, FreeBSD is totally unuseable to me. Rob On 3/7/12 11:05 AM, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. I am working on getting the logs __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 11:42 AM, David Jackson djackson...@gmail.com wrote: On Wed, Mar 7, 2012 at 11:58 AM, Polytropon free...@edvax.de wrote: David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) You are talking about the codec. What Ubuntu seems to do is distribute these codecs as a seperate nonfree addon package which are then loaded by applications at run time. You see, options do not necessarily have to be compiled into programs, they can be loaded at libraries and then loaded by programs at run time if they are available. This is also a rare circumstance, and there are workaround as above. If people want customisations then they can build the software for themselves. That's what they'll do anyway. :-) No, usually they do not. Few people except for hard core geeks want to mess around with compile options. most will use runtime configuration through a GUI which is faster. This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 12:56 PM, David Jackson djackson...@gmail.com wrote: This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. I disagree. I have provided a process for you (or others) to make better decisions regarding the selection of software, operating systems and hardware. How could the developers of any operating system please everyone without watering down the excellent qualities of their creation? It is good that we have so many operating systems from which to choose. This allows operating systems to specialize in their strengths and for users to prioritize their needs. To the extent that you have discussed tools that are broken, I thank you; and I hope you have reported the bugs. I'm sure the tools will be fixed. Every open source operating system is created by developers who decide the direction the operating system will take. The operating system is backed by its own community. When you throw claims about most users not wanting to compile applications from source code, it is clear that you have not taken time to learn about the operating system, its history or the culture of the community. I encourage you to do so. Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Single boot EFI Mac install
On Wed, Mar 7, 2012 at 6:13 PM, George Hartzell hartz...@alerce.com wrote: Carsten Mattner writes: Has anyone successfully installed FreeBSD as a single boot system on an EFI Mac? I'm not sure exactly what you mean by a single boot system. I have Mac Pro that runs Mac OS on on disk (actually a pair in a software RAID) and FreeBSD from another pair (gmirror RAID). I suspect that I could pull the MacOS disks from the system and it would happily run as a FreeBSD only machine. I believe that I set up the disks using the mac tools and then did an install from a DVD, but it's been a while. The only particularly trick-ish part is that I had to partition the FreeBSD disks using MBR style partitions, that's (part of?) what the Mac firmware uses to decide to turn on it's PC-style BIOS emulation, which FreeBSD needs before it can get itself going. GPT partitions will not work. Every once in a while the machine hangs at boot time but I haven't seen it in a while. What happens if you just throw a FreeBSD DVD in the drive? I'm pretty sure I can install FreeBSD. The real question is: Are there EFI bootable FreeBSD images? rEFIt works but cannot be convinced to stop delaying the boot process by ~20 seconds (even after deleting PRAM and bless'ing the partition). That's why I've been looking for native (EFI) boot options. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote: So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. Yes, this sounds awfully good, except that I think it is much harder than you think. First, some options are mutually exclusive (i.e. ncurses vs slang)... so, maybe there are two, or three versions of the same package... and again, this sounds awfully good, except for the limited and volunteered time of a port maintainer. A happy compromise might be then to have binary packages of popular ports, which is how we have it now. Second, and I think this the most important reason, ports put the responsibility of the system on the user. They force you to make decisions on exactly what software is installed. You want the stability and freedom of FreeBSD without this responsibility, and this seems very hard to compromise (e.g., macosx and most linux distributions remove the responsibility by making all these choices for you). Is this newbie friendly? Probably not. Does it need to be? Well, it would be nice if more people use it, but if we remove the responsibility from the user, then it would not be FreeBSD, it would be something else. (Like Debian GNU/kFreeBSD, which sounds like what you are looking for.) -- Benjamin Tovar pgpMtUPAwu5Qi.pgp Description: PGP signature
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 2:11 PM, Andrew Gould andrewlylego...@gmail.comwrote: On Wed, Mar 7, 2012 at 12:56 PM, David Jackson djackson...@gmail.com wrote: This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. I disagree. I have provided a process for you (or others) to make better decisions regarding the selection of software, operating systems and hardware. How could the developers of any operating system please everyone without watering down the excellent qualities of their creation? It is good that we have so many operating systems from which to choose. This allows operating systems to specialize in their strengths and for users to prioritize their needs. To the extent that you have discussed tools that are broken, I thank you; and I hope you have reported the bugs. I'm sure the tools will be fixed. Every open source operating system is created by developers who decide the direction the operating system will take. The operating system is backed by its own community. When you throw claims about most users not wanting to compile applications from source code, it is clear that you have not taken time to learn about the operating system, its history or the culture of the community. I encourage you to do so. I think that your statement here is fundamentally flawed and wrong, because you have assumed that it is impossible for the OS to be able to be user friendly and geek friendly at the same time. This is wrong. In fact, I have outlined ways repeatedly that FreeBSD could provide an easy to use package system without compromising on the flexibility of ports in any way. The idea that the OS has to be either difficult to use or it has to be easy to use for novices is wrong. The OS can be both and I have written about ways that can be done, in fact, I can show how it can be done in every area. For instance, with better binary packages, those are simply built from ports using the best set of options. Those who want to compile for themselves will still be able to do so, just fine. So you have presented a position here that is simply not true. FreeBSD can be more user friendly and as the same time be flexible and friendly to experts such as yourself. its not an either or choice. Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 1:12 PM, Benjamin Tovar b...@robotoloco.com wrote: On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote: So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. Yes, this sounds awfully good, except that I think it is much harder than you think. First, some options are mutually exclusive (i.e. ncurses vs slang)... so, maybe there are two, or three versions of the same package... and again, this sounds awfully good, except for the limited and volunteered time of a port maintainer. A happy compromise might be then to have binary packages of popular ports, which is how we have it now. Second, and I think this the most important reason, ports put the responsibility of the system on the user. They force you to make decisions on exactly what software is installed. You want the stability and freedom of FreeBSD without this responsibility, and this seems very hard to compromise (e.g., macosx and most linux distributions remove the responsibility by making all these choices for you). Is this newbie friendly? Probably not. Does it need to be? Well, it would be nice if more people use it, but if we remove the responsibility from the user, then it would not be FreeBSD, it would be something else. (Like Debian GNU/kFreeBSD, which sounds like what you are looking for.) -- Benjamin Tovar It is not newbie friendly. As a non-techie (CPA), however, I can tell you that it makes the user a better user; and **that** is a good thing. Some things are worth doing. :-) Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 3:20 PM, Andrew Gould andrewlylego...@gmail.comwrote: On Wed, Mar 7, 2012 at 1:12 PM, Benjamin Tovar b...@robotoloco.com wrote: On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote: So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. Yes, this sounds awfully good, except that I think it is much harder than you think. First, some options are mutually exclusive (i.e. ncurses vs slang)... so, maybe there are two, or three versions of the same package... and again, this sounds awfully good, except for the limited and volunteered time of a port maintainer. A happy compromise might be then to have binary packages of popular ports, which is how we have it now. Second, and I think this the most important reason, ports put the responsibility of the system on the user. They force you to make decisions on exactly what software is installed. You want the stability and freedom of FreeBSD without this responsibility, and this seems very hard to compromise (e.g., macosx and most linux distributions remove the responsibility by making all these choices for you). Is this newbie friendly? Probably not. Does it need to be? Well, it would be nice if more people use it, but if we remove the responsibility from the user, then it would not be FreeBSD, it would be something else. (Like Debian GNU/kFreeBSD, which sounds like what you are looking for.) There is a port of apt (sysutils/apt) which you can install, and use to maintain your system via apt repositories. Not sure if anyone is maintaining an apt repository out in the world, for use with FreeBSD. -- Benjamin Tovar It is not newbie friendly. As a non-techie (CPA), however, I can tell you that it makes the user a better user; and **that** is a good thing. Some things are worth doing. :-) Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- regards, matt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 2:12 PM, Benjamin Tovar b...@robotoloco.com wrote: On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote: So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. Yes, this sounds awfully good, except that I think it is much harder than you think. First, some options are mutually exclusive (i.e. ncurses vs slang)... so, maybe there are two, or three versions of the same package... and again, this sounds awfully good, except for the limited and volunteered time of a port maintainer. A happy compromise might be then to have binary packages of popular ports, which is how we have it now. its really not that difficult and this is not an issue tht cannot be dealt with in the default binary package configuration. Both slang and ncurses could be installed and applications could be linked to one or the other. If ncurses is a better choice for instance, it couild be by default linked to that. So if a package has a choice oif being linked to ncurses or slang, then one package will be built, linked to ncurses or whatever is the generally best option and that build of the application will be the binary package. The point i would like to make is, for us to have good binary packages, we dont need to create a different package for every combination of compile time options, but instead compile with the best default set of options. If a user wants more flexibility than that, they are free to compile with ports. the availability of a binary package in no way whatsoever limits the availability of the option to compile a port if the user wants to do that. its not an either or thing. Where two options are mutually exclusive, the best option should be chosen. Where the two options are not mutually exclusive and add a feature or capability to the software, the option can be included. run time configuration settigns should be set to the most reasonable values. Second, and I think this the most important reason, ports put the responsibility of the system on the user. They force you to make decisions on exactly what software is installed. You want the stability and freedom of FreeBSD without this responsibility, and this seems very hard to compromise (e.g., macosx and most linux distributions remove the responsibility by making all these choices for you). Is this newbie friendly? Probably not. Does it need to be? Well, it would be nice if more people use it, but if we remove the responsibility from the user, then it would not be FreeBSD, it would be something else. (Like Debian GNU/kFreeBSD, which sounds like what you are looking for.) The fact is, again, allowing the user to not go into that kind of detail and not mess around with compile time options, does not prevent in any way you from doing so. the OS should be about freedom, Not YOU forcing your ideas about how the system should be used on everyone else. as I repeatedly said, you are free to configure your applications compile to your hearts content, i support you having that freedom.You are the one in fact who has been trying to take away my freedom of not having to mess around with compile options if I dont want to. -- just let users decide if they want to compile port or use pre compiled package for themselves Benjamin Tovar ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dynamic Libraries
On 7 March 2012, at 01:40, Volodymyr Kostyrko wrote: Doug Hardie wrote: I have encountered something that I do not understand. Everything works fine. Basically I have a bunch of user modules (low level) that are built into a dynamic library. If I write top level code that calls modules in that library, everything works just fine on i386 and AMD64. However, the application involved has another library of modules. Some of them call modules in the low level library. The top level code call modules in both libraries. Often when it calls a module in the mid level library, that module calls several modules in the low level library. All this works just fine on i386. However, when I compile everything on AMD64 I get an error message that says the lower level library needs to be compiled with fPIC. If I add that to the Makefile for the lower level library and rebuild everything, it all works again. I don't understand why the fPIC is required for AMD64. Also, how do I tell if the lower level library is being dynamically linked at run time, or being directly incorporated into the mid level library or top level application? Since both of these libraries are quite large, and they are in use by a number of top level applications, I want just one copy to exist in physical memory. This sounds exactly like compiling with clang through ccache. There are issues with clang and ccache cooperation. Actually the one you may hit is libtool detecting implicit fPIC requirement when running clang through ccache. The Makefile specifies GCC and its FreeBSD 8.0. I don't believe clang was in that soon, but I may be wrong. How can I check that? Where is clang? I have installed 9.0 on another system but haven't had time to try that out yet. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Raspberry Pi
Has there been any movement toward getting BSD Unix systems running on the Raspberry Pi platform? I've been searching for information along those lines, but so far have seen nothing. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, 7 Mar 2012 11:28:47 -0500 David Jackson wrote: One faulty argument I heard was that it is often not a good idea to upgrade to new software release. This is an argument that you appear to have completely misunderstood. The point of suggesting that you use release package is that it's a workaround for your problems, and minor releases are not all that far apart. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. Surely that would be the standard amd64. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. Are aware that FreeBSD is mostly a server OS? doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time... The idea of waiting on a FreeBSD kernel release to upgrade firefox is absurd, and the idea that firefox must be upgraded during a kernel upgrade is also absurd. You don't have to do that, that's complete nonsense. There really should be little reason for release upgrades anymore these days, when the different parts of the system can be upgraded independantly through a binary package management tool, including kernel and user programs. When a new kernel is released, there is no reason to reinstall all of the packages on the system at the same time. You reinstall packages because there are major library changes when you cross a major base-system release. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 07, 2012 at 03:20:19PM -0500, David Jackson wrote: I think that your statement here is fundamentally flawed and wrong, because you have assumed that it is impossible for the OS to be able to be user friendly and geek friendly at the same time. This is wrong. In fact, I have outlined ways repeatedly that FreeBSD could provide an easy to use package system without compromising on the flexibility of ports in any way. The idea that the OS has to be either difficult to use or it has to be easy to use for novices is wrong. The OS can be both and I have written about ways that can be done, in fact, I can show how it can be done in every area. For instance, with better binary packages, those are simply built from ports using the best set of options. Those who want to compile for themselves will still be able to do so, just fine. So you have presented a position here that is simply not true. FreeBSD can be more user friendly and as the same time be flexible and friendly to experts such as yourself. its not an either or choice. It can be, if there aren't resources available to devote to both. You've brought this up multiple times. No one is interested in actually doing it. Maybe you should do it yourself and provide the person-power and hardware to get it done right. If it works, I suspect that the FreeBSD devs would accept it and make you an official contributor. Otherwise, as has been noted several times, you are not FreeBSD's target audience. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 10:56 AM, David Jackson djackson...@gmail.com wrote: You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. Maybe FreeBSD isn't right for them. It's not meant to be all things to all people. It may be that a different OS would fill your needs better. If so, you should use it! If you're determined to run some kind of BSD UNIX, you should investigate PC-BSD, which is meant to be easier to install and maintain for non-technical users. For someone who claims to have given up on FreeBSD, you certainly seem to have a lot of time to argue about it. Why the anger? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Raspberry Pi
People have not had a chance to get their hands on to even start on it yet. The few boards out in public before last week were developer boards that were really hard to get a hold of. Most current devel is based on linux due to the binary blob. -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Chad Perrin Sent: Wednesday, March 07, 2012 3:49 PM To: FreeBSD Questions Subject: Raspberry Pi Has there been any movement toward getting BSD Unix systems running on the Raspberry Pi platform? I've been searching for information along those lines, but so far have seen nothing. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Raspberry Pi
On Wed, Mar 07, 2012 at 04:35:47PM -0500, Sean Cavanaugh wrote: People have not had a chance to get their hands on to even start on it yet. The few boards out in public before last week were developer boards that were really hard to get a hold of. Most current devel is based on linux due to the binary blob. Okay, that makes sense. Thanks. If anyone has more information about planned BSD Unix ports to Raspberry Pi, or comes up with more in the next few weeks, I'd appreciate it if someone would let me know (perhaps with URIs or contact information for people and projects working on this). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, 7 Mar 2012 12:42:52 -0500, David Jackson wrote: On Wed, Mar 7, 2012 at 11:58 AM, Polytropon free...@edvax.de wrote: David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) You are talking about the codec. Mostly, yes, but also about what to include: For example, the mplayer port can build mplayer _and_ mencoder. For a GUI version, there's gmplayer and gmencoder. A universal package would contain them all. What Ubuntu seems to do is distribute these codecs as a seperate nonfree addon package which are then loaded by applications at run time. You see, options do not necessarily have to be compiled into programs, they can be loaded at libraries and then loaded by programs at run time if they are available. I know this approach, it's effective within the Linux eco- system and the special view at free vs. nonfree. However, delegating installation and updating tasks from system tools to individual applications looks... hmmm... looks very old-fashioned and wrong to me. Just imagine 100 installed applications would not start, instead inter- actively annoying you that there may be updates available, and you should install them now, and reboot? That kind of exaggeration is an example of how to to it totally wrong. Loading things at runtime is something different than permanently installing things to the system. A web page loads a Javascript source file at runtime, but do you want it to automatically install a web server to your system? :-) If people want customisations then they can build the software for themselves. That's what they'll do anyway. :-) No, usually they do not. Few people except for hard core geeks want to mess around with compile options. most will use runtime configuration through a GUI which is faster. Well, I'm not a hard core geek, but I have to make things running on limited resources. For example, what if you need to turn a 300 MHz P2 into a usable workstation? There's no other way than dealing with /etc/make.conf and looking at port options. Those who intend to customize things usually are familiar with the options that are presented, even though theose options might look like logorrhea to others. Most option screens are full of words (of dependencies or features) that do not make any sense (and there's no way to conclude what they do except doing a web search). For those who tweak, they are no obstacle, but for newcomers they may really be annoying: Do I need KLOMPATSH and SHLORTZ support? And if I do, what do I need them for? :-) When a new kernel is released, there is no reason to reinstall all of the packages on the system at the same time. Since the kernel and userland packages have different development cycles, there is no reason why there has to be synchronization of the upgrading. It sometimes is neccessary, for example if kernel interfaces have changed. There is some means of compatibility provided by the compat_ ports. But if you start upgrading things, libraries can break, and the system may become unstable (in terms of not being able of running certain programs anymore). Just see how kernel and world are out of sync errors can even cause the system to stop booting. Degrading the inner workings of the OS to just another package can cause trouble. Simple updates as they are often performed on Linux systems can render the whole installation totally unusable because something minor went wrong. :-) A well designed system will provide backwards compatability through various strategies and this does not necessarily need to affect internal software design as the backwards compatability can also be provided by compatability layers and glue code. Please do not underestimate the complexity of an operating system. It is not a simple brick of chocolate. It's very complicated, end even easy things like backwards compatibility and universal interfaces need a lot of complexity behind the scenes. The more versions to skip, the more work is needed to keep it running. Just have a look at today's (!) common mainframe operating systems that still allow you to address a card punch in your program. :-) An OS that requires a user to reinstall everything just to upgrade the kernel is not user friendly. Why do consider a user being supposed to mess with kernels? This question can show that I'm already too old: Programs are for users, kernels are for sysadmins. Sysadmins do stuff properly, even if they shoot their foot in order to learn an important lesson. :-) Users have to upgrade the kernel, with a well designed OS this is a process that does not
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 4:27 PM, David Brodbeck g...@gull.us wrote: On Wed, Mar 7, 2012 at 10:56 AM, David Jackson djackson...@gmail.com wrote: You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. Maybe FreeBSD isn't right for them. It's not meant to be all things to all people. It may be that a different OS would fill your needs better. If so, you should use it! If you're determined to run some kind of BSD UNIX, you should investigate PC-BSD, which is meant to be easier to install and maintain for non-technical users. I actually did try PC-BSD and its not better than FreeBSD. An OS that demands users completely reinstall the operating system just to upgrade is user friendly? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dynamic Libraries
On Wed, Mar 07, 2012 at 12:53:13AM -0800, Doug Hardie wrote: All this works just fine on i386. However, when I compile everything on AMD64 I get an error message that says the lower level library needs to be compiled with fPIC. If I add that to the Makefile for the lower level library and rebuild everything, it all works again. I don't understand why the fPIC is required for AMD64. It is a requirement of the architecture. It is explained e.g. in: http://www.technovelty.org/code/c/amd64-pic.html Also, how do I tell if the lower level library is being dynamically linked at run time, or being directly incorporated into the mid level library or top level application? Examine the application with 'ldd -a binary'. That will give you a list of all dynamic objects used by an application, and for each of those dynamic objects the dynamic objects that they depend on. See ldd(1). If your low-level libraries don't show up in that, they are not dynamically loaded. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpAWHZ4rNFFt.pgp Description: PGP signature
Re: Still having trouble with package upgrades
On 07/03/2012 18:56, David Jackson wrote: You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. You're forgetting that one size does *not* fit all. There are many systems and much hardware out there that needs to be tweaked before it will just work. And there is some hardware that is non-free and will not work without some software or firmware blob. And it's couldn't care less not could. -- freebsd at growveg dot net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
apache22 + mod_fastcgi
--- LoadModule fastcgi_module libexec/apache22/mod_fastcgi.so IfModule mod_fastcgi.c AddHandler php5-fastcgi .php FastCgiExternalServer /usr/local/www/apache22/data/php -socket /var/run/spawn_fcgi.sock /IfModule --- this works for my apache for default virtualhost, yet if i use same thing under a virtualhost it won't work VirtualHost *:* ServerName DocumentRoot /home/xxx/xxx/htdocs/ IfModule mod_fastcgi.c AddHandler php5-fastcgi .php FastCgiExternalServer /home/xxx/xxx/htdocs/php -socket /var/run/spawn_fcgi.sock /IfModule /VirtualHost in default virtual host i PHP scripts gets executed no problem, under second it actually just starts downloading that php script.. any ideas? -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
tar(1) and --uid/--gid on 9.0-RELEASE
I see in the tar(1) man-page on FreeBSD 9.0-RELEASE two options that I would like to use: --uid # --gid # Naturally, these are used to override the on-disk credentials while creating (or extracting) an archive. Problem? They don't seem to be supported. % tar cf some_archive.tar --gid 0 --uid 0 somedir tar: Option --gid is not supported ... WTF?! -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: XFCE - how to edit menu ?
On 04/03/2012 17:37, jb wrote: Hi, I find it annoying having same items listed in multiple menus, e.g. - Accessories - Bulk Rename Orage Globaltime Terminal Thunar File Manager Help - Office - Orage Globaltime - System - Bulk Rename Terminal Thunar File Manager - Applications Menu - Help How can I edit the menus ? Also, how to rename Applications Menu to e.g. just Menu as it would better reflect applications and system (utilities) components ? I started looking at this a while ago, this is incomplete but could get you started. I am sure there was a page in the xfce wiki about customising menus. What I found is you start by right clicking on the application menu and show properties where you can change from default to custom file menu - ~/.config/menus/xfce-applications.menu matches the default and is an xml file. There is also some info that comes from the applications desktop files. I think the categories field links them to the matching category entries in the menu file. This is where newly installed apps just show up. Look in ~/.local/share/applications and /usr/local/share/applications for the *.desktop files - I believe the home dir versions override the /usr ones but haven't looked at what gets overwritten by reinstall etc. -- Shane Ambler FreeBSD (at) ShaneWare (dot) Biz http://ShaneWare.Biz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Some questions about Link Aggregation and Failover
bo wang wrote: Thank your for reply. First,I think the Link Aggregation can't support too much ports aggregation.So I change the configure, just get together two ports.Below are configuration information of c3750: ??? Switch#show eth 1 sum Check your eth discriptor this is for Linux is not for FreeBSD use ed0 or other FreeBSD Flags: D - downP - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel ProtocolPorts --+-+---+--- 1 Po1(SU) LACP Gi1/0/1(P) Gi1/0/2(P) Switch#show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 1 neighbors Partner's information: LACP portAdmin Oper PortPort Port Flags Priority Dev ID AgekeyKeyNumber State Gi1/0/1 SA 32768 0010.18c0.af20 4s0x00x250 0x3 0x3D Gi1/0/2 SA 32768 0010.18c0.af20 4s0x00x250 0x4 0x3D Channel group 2 neighbors Partner's information: LACP portAdmin Oper PortPort Port Flags Priority Dev ID AgekeyKeyNumber State Gi1/0/13 SA 32768 0010.18c0.af7c 1s0x00x250 0x3 0x3D Gi1/0/14 SA 32768 0010.18c0.af7c 1s0x00x250 0x4 0x3D Switch#show lacp neighbor detail Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 1 neighbors Partner's information: Partner Partner Partner Port System ID Port Number Age Flags Gi1/0/1 32768,0010.18c0.af20 0x3 13sSA LACP Partner Partner Partner Port PriorityOper KeyPort State 327680x250 0x3D Port State Flags Decode: Activity: Timeout: Aggregation: Synchronization: Active Long YesYes Collecting: Distributing: Defaulted: Expired: Yes Yes No No Partner Partner Partner Port System ID Port Number Age Flags Gi1/0/2 32768,0010.18c0.af20 0x4 14sSA LACP Partner Partner Partner Port PriorityOper KeyPort State 327680x250 0x3D Port State Flags Decode: Activity: Timeout: Aggregation: Synchronization: Active Long YesYes Collecting: Distributing: Defaulted: Expired: Yes Yes No No Channel group 2 neighbors Partner's information: Partner Partner Partner Port System ID Port Number Age Flags Gi1/0/13 32768,0010.18c0.af7c 0x3 15sSA LACP Partner Partner Partner Port PriorityOper KeyPort State 327680x250 0x3D Port State Flags Decode: Activity: Timeout: Aggregation: Synchronization: Active Long YesYes Collecting: Distributing: Defaulted: Expired: Yes Yes No No Partner Partner Partner Port System ID Port Number Age Flags Gi1/0/14 32768,0010.18c0.af7c 0x4 16sSA LACP Partner Partner Partner Port PriorityOper KeyPort State 327680x250 0x3D Port State Flags Decode: Activity: Timeout: Aggregation: Synchronization: Active Long YesYes Collecting: Distributing: Defaulted: Expired: Yes Yes No No 2012/3/7 bo wang wowo...@gmail.com: Hello: Recently I want to do Link Aggregation for increasing the speed. I use a Cisco 3750 Switche and two IBM Server R with BSD 9.0 .I do link aggregation According to this page. http://www.freebsd.org/doc/en/books/handbook/network-aggregation.html I use LACP
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 6:51 PM, Polytropon free...@edvax.de wrote: On Wed, 7 Mar 2012 12:05:37 -0500, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. The portupgrade -PP command should be fine, if your ports tree is up to date. portupgrade -PP did not work for me, it gave me error messages about failed downloads. I am working on getting the logs Those should be interesting. From my own experience, I know there is some software that cannot be easily be updated the binary way, but for most things, it should just work, especially if you keep the default options and have sufficient time. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, 7 Mar 2012 22:04:35 -0500, David Jackson wrote: On Wed, Mar 7, 2012 at 6:51 PM, Polytropon free...@edvax.de wrote: On Wed, 7 Mar 2012 12:05:37 -0500, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. The portupgrade -PP command should be fine, if your ports tree is up to date. portupgrade -PP did not work for me, it gave me error messages about failed downloads. Have you been able to perform the download manually? This is _not_ for actual use, but for diagnostics! Is the URI accessed by portupgrade properly constructed? Typically it's a FTP URI that you can check using the system's standard FTP tool (or web browser, if you want). I had similar trouble years ago when portupgrade wasn't considered mature enough, but today there should be a good reason for a failing download. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 07, 2012 at 10:04:35PM -0500, David Jackson wrote: On Wed, Mar 7, 2012 at 6:51 PM, Polytropon free...@edvax.de wrote: On Wed, 7 Mar 2012 12:05:37 -0500, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. The portupgrade -PP command should be fine, if your ports tree is up to date. portupgrade -PP did not work for me, it gave me error messages about failed downloads. I am working on getting the logs Work harder. Try script(1). Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html pgprrmfB52EBE.pgp Description: PGP signature
Re: Some questions about Link Aggregation and Failover
On 3/6/12 11:41 PM, bo wang wrote: Hello: Recently I want to do Link Aggregation for increasing the speed. I use a Cisco 3750 Switche and two IBM Server R with BSD 9.0 .I do link aggregation According to this page. http://www.freebsd.org/doc/en/books/handbook/network-aggregation.html I use LACP .But when i have done ,the link aggregation only can do Failover .It cann't increase the speed. What is the problem?Detailed configuration as follows How are you measuring the speed to determine that there is no speed-up? You're not, by some chance, sending test data between a single source and single destination address pair are you? -- --Jon Radel j...@radel.com
Re: XFCE - how to edit menu ?
On 03/08/12 12:41, Shane Ambler wrote: On 04/03/2012 17:37, jb wrote: Hi, I find it annoying having same items listed in multiple menus, e.g. - Accessories - Bulk Rename Orage Globaltime Terminal Thunar File Manager Help - Office - Orage Globaltime - System - Bulk Rename Terminal Thunar File Manager - Applications Menu - Help How can I edit the menus ? Also, how to rename Applications Menu to e.g. just Menu as it would better reflect applications and system (utilities) components ? I started looking at this a while ago, this is incomplete but could get you started. I am sure there was a page in the xfce wiki about customising menus. What I found is you start by right clicking on the application menu and show properties where you can change from default to custom file menu - ~/.config/menus/xfce-applications.menu matches the default and is an xml file. There is also some info that comes from the applications desktop files. I think the categories field links them to the matching category entries in the menu file. This is where newly installed apps just show up. Look in ~/.local/share/applications and /usr/local/share/applications for the *.desktop files - I believe the home dir versions override the /usr ones but haven't looked at what gets overwritten by reinstall etc. You can also use alacarte. Should be in ports, you then just right click to edit the menu. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: XFCE - how to edit menu ?
Da Rock freebsd-questions at herveybayaustralia.com.au writes: ... What I found is you start by right clicking on the application menu and show properties where you can change from default to custom file menu - ~/.config/menus/xfce-applications.menu matches the default and is an xml file. ... Look in ~/.local/share/applications and /usr/local/share/applications for the *.desktop files - I believe the home dir versions override the /usr ones but haven't looked at what gets overwritten by reinstall etc. Yes, I figured it out. http://wiki.xfce.org/howto/customize-menu You can also use alacarte. Should be in ports, you then just right click to edit the menu. ,,, I used to use it under Gnome. But under Xfce, I can not bring myself to use it due to its 1537 dependencies. http://www.freebsd.org/cgi/ports.cgi?query=alacartestype=all Thanks guys. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 07, 2012 at 10:04:35PM -0500, David Jackson wrote: On Wed, Mar 7, 2012 at 6:51 PM, Polytropon free...@edvax.de wrote: On Wed, 7 Mar 2012 12:05:37 -0500, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. The portupgrade -PP command should be fine, if your ports tree is up to date. portupgrade -PP did not work for me, it gave me error messages about failed downloads. Assuming you were trying on a RELEASE: Packages for a RELEASE are frozen. Since, most of the time, versions in ports tree are newer than the frozen ones, naturally, you'll get the error about failed download(s) (disregarding that in addition to that you might have proxy problems etc. that others have mentioned). Packages built against STABLE are generally up to date, and you can safely use them with the corresponding RELEASE. To do that, change the PACKAGESITE environment variable as described in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/packages-using.html and pkg_fetch(1). -- Once the toothpaste is out of the tube, it's hard to get it back in. -- H. R. Haldeman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
