Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Hi, Kai wrote: > Another ™.02, > > Today I'm installing Freebsd 6 from a CD, and I'm having to jump through > loops to get it up-to-date. Take for example FreeBSD-SA-06:03.cpio. > > First I need to install the sources for the complete OS, then run a patch on > it, and all that for the installation of 1 measily binary, and then keep > track of the fact that I did this. > > Supplying kernel-source patches is fine, but IMHO there is something really > wrong with this. I don't want to be bothered by the hassle of keeping track > of which security update I patched in my sourcetree and which not. > > So, please pretty please make something that lets us admins just download a > binary package for an updated cpio, and let something whine if its installed > already on a system. > You can just use freebsd-update for these binaries (and not for the kernel), can't you? And then only make buildkernel / installkernel instead. I did use freebsd-update on machines with a custom / modified kernel - it just left the kernel untouched, detecting that it was modified, and update only the rest, like cpio, ee, whatever recent update there was... (Good to have a choice, and it saves a lot of time in cases where I don't need or want to build the world.) Paul P.S. Maybe freebsd-update could have an option for leaving out kernel updates? ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Kai <[EMAIL PROTECTED]> wrote > Hello, > > Another ™.02, > > Today I'm installing Freebsd 6 from a CD, and I'm having to jump through > loops to get it up-to-date. Take for example FreeBSD-SA-06:03.cpio. > > First I need to install the sources for the complete OS, then run a patch on > it, and all that for the installation of 1 measily binary, and then keep > track of the fact that I did this. And all I had to do was # freebsd-update fetch # freebsd-update install Although that was a 5.4 system, not 6.0. > > Supplying kernel-source patches is fine, but IMHO there is something really > wrong with this. I don't want to be bothered by the hassle of keeping track > of which security update I patched in my sourcetree and which not. > > So, please pretty please make something that lets us admins just download a > binary package for an updated cpio, and let something whine if its installed > already on a system. > > Shouldn't be too big a problem to get this done in 2006, rpm could do the > job, apt-get would suffice too? Have you looked at ports/security/freebsd-update? It handles this if you are using a GENERIC kernel (and it works fine for non-generic kernels if what needs updating is not part of the kernel). As near as I can tell, the discussion here is (a) why not make freebsd-update part of the base distribution instead of a port, and (b) we need a tool that can do the same job on non-generic kernels (which leads to a discussion of the best way to accomplish that). But I'm not trying real hard to follow it closely, although I agree that moving freebsd-update into the base system would be a good idea. - Bob ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 5 Jan 2006, Jo Rhett wrote: > > Look around. Every major commercial OS does it just fine. Most of the > open source OSes do it just fine. Debian had probably the easiest to use > system, and they've risen, owned the world and fallen all while FreeBSD has > been debating this issue. > Hello, Another ™.02, Today I'm installing Freebsd 6 from a CD, and I'm having to jump through loops to get it up-to-date. Take for example FreeBSD-SA-06:03.cpio. First I need to install the sources for the complete OS, then run a patch on it, and all that for the installation of 1 measily binary, and then keep track of the fact that I did this. Supplying kernel-source patches is fine, but IMHO there is something really wrong with this. I don't want to be bothered by the hassle of keeping track of which security update I patched in my sourcetree and which not. So, please pretty please make something that lets us admins just download a binary package for an updated cpio, and let something whine if its installed already on a system. Shouldn't be too big a problem to get this done in 2006, rpm could do the job, apt-get would suffice too? Regards, Kai -- begin 600 .signature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On 22. des. 2005, at 22.17, Jo Rhett wrote: On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote: FreeBSD Update was written by, and is continuously maintained by the actual FreeBSD Security Officer. It's as official as it gets. If the only barrier to acceptance is that it's not distributed from the FreeBSD.org domain, then a) that's a silly argument, and b) it's easily solvable so long as Colin agrees. But FreeBSD Update suffers from all of the same limitations that I've been describing because of lack of integration with the Core OS. 1. modified kernels are foobar ..yet are practically mandatory on production systems 2. modified sources are foobar ..yet many common production situations require source compilation options Modified files cannot be patched, period. No matter what system you are on. A nice user-experience of backing up the modified file and reinstalling the default could be added on top to resemble other systems, but it would not solve your problem. What you are looking for is enough run-time knobs and a stable ABI layer for third party drivers so the need for compiling your own kernel disappears. 3. FreeBSD Update can't handle updates of jails and other situations that package systems deal with just fine. freebsd-update -b /usr/jail/foo ? From the manual: Act on a FreeBSD world based at the directory basedir. This is suitable for updating jails, but note that the usual rules about updating locally modified (or compiled) files apply, and the jail must belong to the same release version as the run- ning kernel. Frode Nordahl [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
> >On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
> >> While I agree with much of your reasoning, I know exactly zero
> >> people running a modified kernel of any version of Windows,
> >> Mac OS X or Solaris, to name just three commercial OS's.
> On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
> >You're tickling a different subject here. All three of these operating
> >systems have loadable kernel modules that work.
On Sat, Jan 07, 2006 at 07:31:20AM +1100, Peter Jeremy wrote:
> As does FreeBSD.
No. See below.
> > I mean, they dynamically
> >load the modules they need, and you can disable kernel modules in
> >configuration files. FreeBSD has loadable kernel modules, but they don't
> >autoload (you have to modify rc files)
>
> This isn't quite true. FreeBSD does not currently have the tools to
> automatically load kernel modules for most hardware device drivers and
[cut more explanation of the "state of" which we both know]
Let me rephrase it for you. One cannot run GENERIC on FreeBSD (like on
these platforms) because one has to REMOVE drivers from the kernel in order
to successfully use the hardware.
Vendor supplies updated driver (.ko) for hardware. But you can't use this
without either re-compiling the kernel with the new driver, or recompiling
the kernel with that driver disabled. In either case, no GENERIC for you.
This isn't true on any of the platforms above you have named. Thus,
freebsd doesn't have a loadable modules interface that works well enough
for this situation.
> >To give you a specific example: if we could remove NFS and the 3ware
> >driver from the kernel in a configuration file, we could probably run
> >GENERIC.
>
> IMHO, NFS server could be removed without problems (it will autoload),
> as could tw{a,e} (which are loadable). NFS client can't be removed
> because it has to be built in to support diskless operation.
We don't need either, we just need those resources (memory) back.
And back to the topic: this is why we can't run FreeBSD GENERIC, but
nobody has to tune their kernels on the major OSes ;-)
> >hog we have to remove on small footprint systems
>
> FreeBSD has never claimed to optimally support small footprint systems
> without customisation. There are too many variables and some kernel
> functionality can't be readily converted to modules (eg IPv6 support).
> In any case, the way to minimise the kernel footprint is to statically
> load all the required functionality and not have any modules.
Either way, it's non GENERIC. So you have strongly and clearly made my own
arguement for me about why you have to modify GENERIC on FreeBSD but not
on the other major OSes.
--
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
>On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
>> While I agree with much of your reasoning, I know exactly zero
>> people running a modified kernel of any version of Windows,
>> Mac OS X or Solaris, to name just three commercial OS's.
>
>You're tickling a different subject here. All three of these operating
>systems have loadable kernel modules that work.
As does FreeBSD.
> I mean, they dynamically
>load the modules they need, and you can disable kernel modules in
>configuration files. FreeBSD has loadable kernel modules, but they don't
>autoload (you have to modify rc files)
This isn't quite true. FreeBSD does not currently have the tools to
automatically load kernel modules for most hardware device drivers and
they need to either be built into the kernel or specified in
loader.conf. Writing a tool to do this automatically would be fairly
simple - either use pciconf(8) and a database of PCI ID to driver
mappings or (as Solaris and X do) load every module and see if it can
attach to anything, unload it if it can't. To date, no-one has been
sufficiently motivated to do so.
FreeBSD will autoload kernel modules for many software functions if
their functionality is required (NFS, SysV IPC, firewalls). In some
cases this is automatic (NFS client loads automatically if NFS
filesystems are found). In other cases, (eg firewalls) you need to
configure the functionality anyway.
> and you can't trim down the kernel
>to minimize unused memory without recompiling.
In the absence of tools to automatically detect your configuration and
load the appropriate modules, GENERIC includes a fairly standard set
of drivers that also exist as modules. GENERIC probably could be cut
down somewhat but this isn't the forum to discuss that.
>To give you a specific example: if we could remove NFS and the 3ware
>driver from the kernel in a configuration file, we could probably run
>GENERIC.
IMHO, NFS server could be removed without problems (it will autoload),
as could tw{a,e} (which are loadable). NFS client can't be removed
because it has to be built in to support diskless operation.
>hog we have to remove on small footprint systems
FreeBSD has never claimed to optimally support small footprint systems
without customisation. There are too many variables and some kernel
functionality can't be readily converted to modules (eg IPv6 support).
In any case, the way to minimise the kernel footprint is to statically
load all the required functionality and not have any modules.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 10:40:56PM +1100, Peter Jeremy wrote:
> >No. I want a binary update mechanism. Obviously if we have local
> >configuration options we'll have to compile our own binaries. But doing
> >the work of tracking system updates currently requires us to build our own
> >patch tracking mechanism, and then re-write it for every new release.
> On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
> If you're willing to do your own compiles:
> 1) CVSup or cvs update to whatever branch you want
> 2) make build{world,kernel}
> 3) make DESTDIR=/updates install{world,kernel}
> 4) mergemaster -D /updates
> 5) rsync or similar
Hm. So how do I know which systems need the upgrade?
So what occurs if the wrong version is rsynced to the wrong system?
What do I do if a kernel module upgrade fails? How do I restore state?
This problem is solved fairly well in every other OS I can think of. But
for FreeBSD we're currently solving it with very complex cfengine
management tied to lots of local databases and thousands of lines of our
own code. It's all the long way around a problem that is very simple to
solve in the core.
> It seems fairly obvious that you are frustrated by FreeBSD's inability
> to meet your needs as far as updating is concerned. I suspect I'm not
> alone in being uncertain exactly what your requirements are and what
> additional features FreeBSD needs to satisfy you.
Some implementation (any!) that versions the core. Something you can query
to ask what is, update to say what you've done, and revert to restore a
previous state.
> How would you like
> to write a formal requirements specification and post it here (or in
> -arch).
This has been written many times, by people better at explaining the issues
than I am. I'll find someone elses and forward it to you.
> Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?
I haven't compared bcfg2 to what we're doing now (cfengine) but it would
likely have all of the same problems. Namely, we'd have to build and
maintain a database of all possible software combinations, and what systems
are running which patches, and then write scripts that do the right updates
to the right systems.
Again, thousands of lines of perl/ruby/shell to work around a very well
known limitation in freebsd.
--
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 01:26:12PM -0500, Ender wrote: > I think what "integrated with the core OS" means from a user standpoint > is: from a fresh minimum install of freebsd I can type > "freebsd-update-whatever" and it will update my system. Just "freebsd-update" ;-) That works fairly well with the current freebsd-update (or bsdupdates.com) solutions. For most GENERIC installed systems, it works fairly well. I use on 3 systems at my home for this, and I'm pretty happy with it. It doesn't work very well in environments with compiled options, custom kernels, and other situations. That's what I'm trying to tackle here. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 09:11:58PM +1030, Daniel O'Connor wrote: > On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > > How do you expect these two to be handled in a binary upgrade? > > > I can't see how it's possible.. > > > > Look around. Every major commercial OS does it just fine. Most of the > > open source OSes do it just fine. Debian had probably the easiest to use > > system, and they've risen, owned the world and fallen all while FreeBSD has > > been debating this issue. > > You appear to be misunderstanding what I said. > > I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it > isn't NECESSARY to version and package the base install to do it. Whether or not the core is 'packaged' is an implementation detail. I've heard good arguements either way. But some sort of versioning is required. How do you know what to update? How do you know if it has been updated already? Checksum analysis is the VERY long way around and incredibly CPU intensive. And it requires an extensive database of all possible combinations. > > > I don't think integrating it with the core OS (whatever that means) will > > > magically fix this. > > > > If you knew what it meant, you would understand why it would help. > > Ah what a great explanation of what is meant. > There are several people who don't know what is meant here and I haven't seen > a decent explanation forthcoming. I had explained it several times in other replies, and wasn't going to repeat it again. Especially not against a global wide open "I don't think it will help" without any backing arguements or qualifications to the statement. It's just too broad to work with. In short, not trying to be rude but would prefer to focus on solutions that explain the 10k view. > Just because I don't run jails doesn't mean I don't know the pain of > upgrading > a system. Just because you've upgraded a system doesn't mean you understand or even grasp the issues involved in managing jails. You can tell me that driving a car should give you the experience to argue riding motorcycles with me, but I'm going to have trouble taking you seriously ;-) (no offense intended, really... just trying to be clear) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: > > > > 1. modified kernels are foobar > > > > ..yet are practically mandatory on production systems > > > Look around. Every major commercial OS does it just fine. > > While I agree with much of your reasoning, I know exactly zero > people running a modified kernel of any version of Windows, > Mac OS X or Solaris, to name just three commercial OS's. You're tickling a different subject here. All three of these operating systems have loadable kernel modules that work. I mean, they dynamically load the modules they need, and you can disable kernel modules in configuration files. FreeBSD has loadable kernel modules, but they don't autoload (you have to modify rc files) and you can't trim down the kernel to minimize unused memory without recompiling. To give you a specific example: if we could remove NFS and the 3ware driver from the kernel in a configuration file, we could probably run GENERIC. (we do *a lot* of other modifications, but NFS is the main memory hog we have to remove on small footprint systems, and the 3ware driver we have to update independently, which requires that it be a loadable module and not compiled in) So yeah, this is a different problem. However I wasn't going to tackle this issue in this thread because the -core team appears to be very aware of this issue and it seems to improve a bit in every release. > And third party drivers (which one could count as "kernel modifications") > did fail and will fail sometimes in weird ways even for minor > version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, > Mac OS X updates, reboot, *boom*, because some hardware suppliers > driver didn't adhere to the OS manufacturer's standards or because > the latter silently changed something undocumented. I don't know what you're trying to say here. I don't disagree, I'm just not sure what you mean. It almost sounds like you're trying to make my own point about having the ability to backout patches, which we don't have today. > While I would appreciate a packaged core system or at least a > better definition of "core system" at all, I strongly believe > that binary updating a custom kernel is impossible. If the kernel is consistent across the enterprise (but not, say GENERIC) then binary updates would be trivial. > With "better definition of core system" I mean, if you have a > long lived production system that you might have upgraded > from 4.x to 5.x to 6.0, you will have a lot of cruft lying > on your filesystem that once was part of the "core" and now > isn't. And there is no simple and automated way to find out > what to delete ... That's another good point for having file revisions. We don't have that particular problem, but I can easily imagine how having versioning of the core OS would be useful to help isolate these orphaned files. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Daniel O'Connor wrote: On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: How do you expect these two to be handled in a binary upgrade? I can't see how it's possible.. Look around. Every major commercial OS does it just fine. Most of the open source OSes do it just fine. Debian had probably the easiest to use system, and they've risen, owned the world and fallen all while FreeBSD has been debating this issue. You appear to be misunderstanding what I said. I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it isn't NECESSARY to version and package the base install to do it. I don't think integrating it with the core OS (whatever that means) will magically fix this. If you knew what it meant, you would understand why it would help. Ah what a great explanation of what is meant. There are several people who don't know what is meant here and I haven't seen a decent explanation forthcoming. I think what "integrated with the core OS" means from a user standpoint is: from a fresh minimum install of freebsd I can type "freebsd-update-whatever" and it will update my system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
>No. I want a binary update mechanism. Obviously if we have local
>configuration options we'll have to compile our own binaries. But doing
>the work of tracking system updates currently requires us to build our own
>patch tracking mechanism, and then re-write it for every new release.
If you're willing to do your own compiles:
1) CVSup or cvs update to whatever branch you want
2) make build{world,kernel}
3) make DESTDIR=/updates install{world,kernel}
4) mergemaster -D /updates
5) rsync or similar
It seems fairly obvious that you are frustrated by FreeBSD's inability
to meet your needs as far as updating is concerned. I suspect I'm not
alone in being uncertain exactly what your requirements are and what
additional features FreeBSD needs to satisfy you. How would you like
to write a formal requirements specification and post it here (or in
-arch).
>It's not a recompile issue. It's a tracking/update/backout issue. I don't
>mind recompiling, if I could somehow push the updates to all the right
>systems and they would have it stored somewhere that they were patched...
Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > How do you expect these two to be handled in a binary upgrade? > > I can't see how it's possible.. > > Look around. Every major commercial OS does it just fine. Most of the > open source OSes do it just fine. Debian had probably the easiest to use > system, and they've risen, owned the world and fallen all while FreeBSD has > been debating this issue. You appear to be misunderstanding what I said. I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it isn't NECESSARY to version and package the base install to do it. > > I don't think integrating it with the core OS (whatever that means) will > > magically fix this. > > If you knew what it meant, you would understand why it would help. Ah what a great explanation of what is meant. There are several people who don't know what is meant here and I haven't seen a decent explanation forthcoming. > > Not having run jails I am not very qualified to comment > > Exactly. Sorry, not trying to be rude but if you have never felt the pain > don't try and say it doesn't exist. Just because I don't run jails doesn't mean I don't know the pain of upgrading a system. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGpPXTPTxIl.pgp Description: PGP signature
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Hello! > > > 1. modified kernels are foobar > > > ..yet are practically mandatory on production systems > Look around. Every major commercial OS does it just fine. While I agree with much of your reasoning, I know exactly zero people running a modified kernel of any version of Windows, Mac OS X or Solaris, to name just three commercial OS's. And third party drivers (which one could count as "kernel modifications") did fail and will fail sometimes in weird ways even for minor version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, Mac OS X updates, reboot, *boom*, because some hardware suppliers driver didn't adhere to the OS manufacturer's standards or because the latter silently changed something undocumented. While I would appreciate a packaged core system or at least a better definition of "core system" at all, I strongly believe that binary updating a custom kernel is impossible. With "better definition of core system" I mean, if you have a long lived production system that you might have upgraded from 4.x to 5.x to 6.0, you will have a lot of cruft lying on your filesystem that once was part of the "core" and now isn't. And there is no simple and automated way to find out what to delete ... Just some thoughts, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
> On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: > >But FreeBSD Update suffers from all of the same limitations that I've been > >describing because of lack of integration with the Core OS. > > > >1. modified kernels are foobar > > ..yet are practically mandatory on production systems > > > >2. modified sources are foobar > > ..yet many common production situations require source compilation options On Fri, Dec 23, 2005 at 03:56:48PM +1100, Peter Jeremy wrote: > So you want to be able to make arbitrary changes you your source code > and compilation options and then expect the FreeBSD project to provide > a tool that will apply binary fixes to the resultant executables? No. I want a binary update mechanism. Obviously if we have local configuration options we'll have to compile our own binaries. But doing the work of tracking system updates currently requires us to build our own patch tracking mechanism, and then re-write it for every new release. If the core OS supported the necessary features for handling patches to the core, then we could stop building all these tools ourselves and focus on real work. > I don't know that modified kernels are mandatory. A lot of work has > been going on to reduce the need to re-compile the kernel for common > situations. Likewise, I don't know that "many common" and "require" > go together - IMHO, 'desire' or 'would be nice' are more appropriate > descriptions. Would you care to provide some details of what you > believe can be done to reduce your need to re-compile the OS. It's not a recompile issue. It's a tracking/update/backout issue. I don't mind recompiling, if I could somehow push the updates to all the right systems and they would have it stored somewhere that they were patched... > I'm not sure that FreeBSD Update is totally unusable for you. If you > have the situation where you have a modified FreeBSD that you need to > roll out to a large number of hosts, you just need to have your own > FreeBSD Update server - you test the changes in your environment and > then roll them out as you require. I've looked it over, and our current mechanism works better than freebsd-update at the moment. Always subject to change. > I don't run jails so I'm not familiar with the problems here. Maybe you'd > like to explain the problems you run into. It's really just the same problem. Some mechanism to find out what is, and store what has been done. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
> On Fri, 23 Dec 2005 07:47, Jo Rhett wrote: > > But FreeBSD Update suffers from all of the same limitations that I've been > > describing because of lack of integration with the Core OS. > > > > 1. modified kernels are foobar > > ..yet are practically mandatory on production systems > > > > 2. modified sources are foobar > > ..yet many common production situations require source compilation > > options On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > How do you expect these two to be handled in a binary upgrade? > I can't see how it's possible.. Look around. Every major commercial OS does it just fine. Most of the open source OSes do it just fine. Debian had probably the easiest to use system, and they've risen, owned the world and fallen all while FreeBSD has been debating this issue. > I don't think integrating it with the core OS (whatever that means) will > magically fix this. If you knew what it meant, you would understand why it would help. > Not having run jails I am not very qualified to comment Exactly. Sorry, not trying to be rude but if you have never felt the pain don't try and say it doesn't exist. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 23, 2005 at 03:38:20PM +1100, Peter Jeremy wrote: > I agree with Brooks. I don't recall ever seeing a message from -core > (or anyone else talking on behalf of the Project) stating that code to > make binary updates possible would not be integrated. For that matter, > I don't recall ever seeing code offered to implement such a feature. As stated before, let me find some threaded archives and I'll find the relevant topics. Perhaps it wasn't -core that vetoed it, but it was harshly fought against for ivory tower reasons, and nobody from -core ever stood up to show interest. > Core OS packages have been discussed but I don't recall the idea ever > being vetoed. Some work have been done in breaking bits of the base OS > out into packages (perl, games and UUCP come to mind) but packaging the > entire system is a major undertaking. In any case, I don't see how > packaging the system would help you. Taking Solaris as an example of > an OS which is broken up into lots of packages, patches don't replace > whole packages, they replace individual files. Obviously the details need to be ironed out. The current freebsd package system is certainly missing a few key features (in my mind) but most everyone agrees on the basics. Packaged cores allow identification of "what you have". Package databases can store "what you have changed". Package databases can store "how to back out the change". This is pretty much the only things that prevent freebsd-update from working perfectly in production environments, to name the most obvious candidate for adapting to this job. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 23, 2005 at 01:13:20PM -0600, Mark Linimon wrote: > On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: > > I and many others have offered to work on this. The core team has > > repeatedly stated that they won't integrate the efforts > > Please provide hard evidence for this assertion. Merely repeating it will > not be sufficiently convincing. I would like to see _specific_ references > (email or other documentation) that that is _exactly_ what core, or anyone > else, has said. I cannot recall any such thing on any of the mailing lists > that I have monitored for the past several years. > > Without that, my high degree of skepticism about this claim will remain. Sorry for the late reply. I saw this and realized that not only will we apparently need to rehash the ball-busting thread giant topic again, but now I need to prove it ever existed Ugh. Yeah, I'll do the research sometime early next week. Mostly to find archives with useful threading so that you can read all the way down the trafic tree. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: > I and many others have offered to work on this. The core team has > repeatedly stated that they won't integrate the efforts Please provide hard evidence for this assertion. Merely repeating it will not be sufficiently convincing. I would like to see _specific_ references (email or other documentation) that that is _exactly_ what core, or anyone else, has said. I cannot recall any such thing on any of the mailing lists that I have monitored for the past several years. Without that, my high degree of skepticism about this claim will remain. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: >But FreeBSD Update suffers from all of the same limitations that I've been >describing because of lack of integration with the Core OS. > >1. modified kernels are foobar > ..yet are practically mandatory on production systems > >2. modified sources are foobar > ..yet many common production situations require source compilation options So you want to be able to make arbitrary changes you your source code and compilation options and then expect the FreeBSD project to provide a tool that will apply binary fixes to the resultant executables? I don't know that modified kernels are mandatory. A lot of work has been going on to reduce the need to re-compile the kernel for common situations. Likewise, I don't know that "many common" and "require" go together - IMHO, 'desire' or 'would be nice' are more appropriate descriptions. Would you care to provide some details of what you believe can be done to reduce your need to re-compile the OS. I'm not sure that FreeBSD Update is totally unusable for you. If you have the situation where you have a modified FreeBSD that you need to roll out to a large number of hosts, you just need to have your own FreeBSD Update server - you test the changes in your environment and then roll them out as you require. AFAIK, Colin hasn't fully productised FreeBSD Update to date but has not rejected the idea of doing so. >3. FreeBSD Update can't handle updates of jails and other situations that >package systems deal with just fine. I don't run jails so I'm not familiar with the problems here. Maybe you'd like to explain the problems you run into. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Thu, 2005-Dec-22 13:10:19 -0800, Jo Rhett wrote: >I and many others have offered to work on this. The core team has >repeatedly stated that they won't integrate the efforts, which makes >os-upgrade capability minimal and easily broken. (see current efforts) On Thu, 2005-Dec-22 14:05:32 -0800, Jo Rhett wrote: >On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote: >> This statement makes no sense. The core team wouldn't have much to >> do with this other than possibly being involved in making any service >> official. Also, approval is never given to include a non-existent >> feature. Easy, binary updates sound like a great idea, but without >> seeing actual code thats all anyone can say other than offering advice. >> If volunteering is conditional on acceptance of the work, that's a >> chicken-egg problem and is not resolvable. We simply can't maintain >> quality if we accept non-existent code just because the idea sounds >> good. > >What are you talking about? These issues have been repeatedly brought up >in the mailing lists, and what it would require to make it possible to >handle appropriately (namely, core os packages or a similar versioning >mechanism) and the arguements have often been given. I agree with Brooks. I don't recall ever seeing a message from -core (or anyone else talking on behalf of the Project) stating that code to make binary updates possible would not be integrated. For that matter, I don't recall ever seeing code offered to implement such a feature. Core OS packages have been discussed but I don't recall the idea ever being vetoed. Some work have been done in breaking bits of the base OS out into packages (perl, games and UUCP come to mind) but packaging the entire system is a major undertaking. In any case, I don't see how packaging the system would help you. Taking Solaris as an example of an OS which is broken up into lots of packages, patches don't replace whole packages, they replace individual files. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Fri, 23 Dec 2005 07:47, Jo Rhett wrote: > On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote: > > FreeBSD Update was written by, and is continuously maintained by the > > actual FreeBSD Security Officer. It's as official as it gets. If > > the only barrier to acceptance is that it's not distributed from the > > FreeBSD.org domain, then a) that's a silly argument, and b) it's easily > > solvable so long as Colin agrees. > > But FreeBSD Update suffers from all of the same limitations that I've been > describing because of lack of integration with the Core OS. > > 1. modified kernels are foobar > ..yet are practically mandatory on production systems > > 2. modified sources are foobar > ..yet many common production situations require source compilation > options How do you expect these two to be handled in a binary upgrade? I can't see how it's possible.. I don't think integrating it with the core OS (whatever that means) will magically fix this. > 3. FreeBSD Update can't handle updates of jails and other situations that > package systems deal with just fine. Not having run jails I am not very qualified to comment, however, I don't see why you can't just run freebsd update inside your jail(s). If you mean that it would be good if you could automatically upgrade a large number of jails and rebuild link farms etc etc.. well sure that isn't supported, but it is a very difficult problem to solve (I believe). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpSfJi3tgpAm.pgp Description: PGP signature
Re: HEADS UP: Release schedule for 2006
On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote: > This statement makes no sense. The core team wouldn't have much to > do with this other than possibly being involved in making any service > official. Also, approval is never given to include a non-existent > feature. Easy, binary updates sound like a great idea, but without > seeing actual code thats all anyone can say other than offering advice. > If volunteering is conditional on acceptance of the work, that's a > chicken-egg problem and is not resolvable. We simply can't maintain > quality if we accept non-existent code just because the idea sounds > good. What are you talking about? These issues have been repeatedly brought up in the mailing lists, and what it would require to make it possible to handle appropriately (namely, core os packages or a similar versioning mechanism) and the arguements have often been given. And many people _ARE_ already trying to handle binary updates without core OS support. We are all struggling with the same limitations. Talk to the security officer about this if you don't believe me. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: > On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote: > > So, when will you fix it? Or hire someone to fix it? FreeBSD after > > all is mostly a volunteer operation. > > I and many others have offered to work on this. The core team has > repeatedly stated that they won't integrate the efforts, which makes > os-upgrade capability minimal and easily broken. (see current efforts) This statement makes no sense. The core team wouldn't have much to do with this other than possibly being involved in making any service official. Also, approval is never given to include a non-existent feature. Easy, binary updates sound like a great idea, but without seeing actual code thats all anyone can say other than offering advice. If volunteering is conditional on acceptance of the work, that's a chicken-egg problem and is not resolvable. We simply can't maintain quality if we accept non-existent code just because the idea sounds good. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp9pQJsguI8u.pgp Description: PGP signature
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote: > FreeBSD Update was written by, and is continuously maintained by the > actual FreeBSD Security Officer. It's as official as it gets. If > the only barrier to acceptance is that it's not distributed from the > FreeBSD.org domain, then a) that's a silly argument, and b) it's easily > solvable so long as Colin agrees. But FreeBSD Update suffers from all of the same limitations that I've been describing because of lack of integration with the Core OS. 1. modified kernels are foobar ..yet are practically mandatory on production systems 2. modified sources are foobar ..yet many common production situations require source compilation options 3. FreeBSD Update can't handle updates of jails and other situations that package systems deal with just fine. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sat, Dec 17, 2005 at 11:35:34PM +0100, K?vesd?n G?bor wrote: > I agree. And after all, tracking a security branch isn't too difficult, > but the most people think that they have to do a complete "make > buildworld" after a security advisory, but this isn't true. For example > there was that cvsbug issue in September: .. > # make obj && make depend && make && make install > > Is that difficult? I don't think so. No reboot required and it doesn't > take more than 5 minutes even on a slower machine. This comment demonstrates that you are again talking about home computers, while all of my comments indicated that I was talking about production systems. Ones that may not have sufficient memory to compile code, or local disks, or... In any case, you are right. This kind of patch is easy to apply. You can build it on a central server and synchronize it outwards to the others. The existing binary update mechanisms can handle this situation fairly well. But more "core OS" upgrades means less of these patches and more requirement for a full binary upgrade. Which is NOT easy like this. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote: > So, when will you fix it? Or hire someone to fix it? FreeBSD after > all is mostly a volunteer operation. I and many others have offered to work on this. The core team has repeatedly stated that they won't integrate the efforts, which makes os-upgrade capability minimal and easily broken. (see current efforts) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
As a FreeBSD-n00b with some 'friends' that know FreeBSD better/well I can only say Please add this kind of information to the Handbook Any addition to the handbook on tracking down problems and smarter ways to fix things would be greatly appreciated. I found myself recompiling my kernel to test changes to a device's driver, but now you tell me I could have done that a lot smarter! Whenever I get my 'knickers-in-a-twist' when using FreeBSD my first point of reference is 'The Handbook'. Any additional information in there would greatly be appreciated. Learning-curve is very, very steep when you're used to lslpp and windowsupdate to patch your system. I _do_ appreciate that most developers and users are very experienced in using FreeBSD, but that makes it increasingly difficult for the not-so-fortunate to come up to speed with the use of FreeBSD. Spil. On 12/17/05, Kövesdán Gábor <[EMAIL PROTECTED]> wrote: > Wilko Bulte wrote: > > >On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. > > > > > >>On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > >> > >> > >>>There will be three FreeBSD 6 releases in 2006. > >>> > >>> > >>While this is nice, may I suggest that it is time to put aside/delay one > >>release cycle and come up with a binary update mechanism supported well by > >>the OS? Increasing the speed of releases is good. Increasing the number > >>of deployed systems out of date because there are no easy binary upgrade > >>mechanisms is bad. > >> > >>It has been bad, it's getting worse. > >> > >> > > > >So, when will you fix it? Or hire someone to fix it? FreeBSD after > >all is mostly a volunteer operation. > > > > > > > I agree. And after all, tracking a security branch isn't too difficult, > but the most people think that they have to do a complete "make > buildworld" after a security advisory, but this isn't true. For example > there was that cvsbug issue in September: > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug.asc > One can read here: > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # cd /usr/src/gnu/usr.bin/cvs/cvsbug > # make obj && make depend && make && make install > # cd /usr/src/gnu/usr.bin/send-pr > # make obj && make depend && make && make install > > Is that difficult? I don't think so. No reboot required and it doesn't > take more than 5 minutes even on a slower machine. Only the > vulnerabilities in the kernel are problematic for servers, since they > require a reboot. I think I'll submit a PR with a patch to clarify this > in Handbook. Do you consider this useful? > > Regards, > > Gabor Kovesdan > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Kevin Oberman writes: > [discussion of USB/Cx level interactions clipped out...] > > If you unload the drivers, you should be to lower levels. Take a look at > sysctl hw.acpi.cpu for detail and to see how much time is spent in each > sleep state. > > I assume that you can unload the drivers, but my kernel has USB at this > time. I do plan on building a kernel without USB and see if unloading is > a workable solution. I think it should be. I was spending all of my time in C1. After I added performance_cx_lowest="LOW" economy_cx_lowest="LOW" to my /etc/rc.conf, I found I spent all of my time in C2. I built a kernel w/ all of the usb devices commented out (and eventually remembered to set usbd_enable="NO" in /etc/rc.conf, else the modules just get kloaded...), and now I have: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: C3 hw.acpi.cpu.cx_usage: 0.00% 15.21% 84.78% If I start usbd by hand the system starts spending time in C2. If I stop usbd and kldunload usb, the system starts spending time in C3 again. g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cx states missing after upgrade -- Was: Re: HEADS UP: Release schedule for 2006
Kevin Oberman wrote: Date: Sun, 18 Dec 2005 20:46:49 +0100 From: martinko <[EMAIL PROTECTED]> Kevin Oberman wrote: Date: Sat, 17 Dec 2005 18:14:01 +0100 From: martinko <[EMAIL PROTECTED]> Kevin Oberman wrote: Date: Fri, 16 Dec 2005 14:29:39 -0600 From: Craig Boston <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] -cpu0: on acpi0 +cpu0: on acpi0 Q: Guessing that's a formatting difference, rather then 6.x not recognizing the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) Not sure on this, but you're probably better off using EST anyway as I think it gives you more control over the processor frequency. No. There is no conflict between Cx states and EST. Cx states specifies how deeply the CPU will sleep when idle. EST controls processor speed and voltage. In most cases, your REALLY want to use both of these. They are very significant in saving power. (Of course, USB tends to limit the effectiveness of Cx states. I need to run without USB to get really good battery life and to make suspend (S3) really ut power drain. Kevin, I used to have 3 Cx states supported when I started with FreeBSD on version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see is just one supported Cx state. I much wonder why. (?) What value do you have in /etc/rc.conf (if any) for performance_cx_lowest? It defaults to HIGH which will limit you to only the most power hungry sleep state (simple halt). This was made the default because some hardware was breaking when this was defaulted to LOW. T0 get other Cx states to be utilized, add 'performance_cx_lowest="LOW"' to /etc/rc.conf. i see. anyway: # grep cx /etc/rc.conf.local economy_cx_lowest="LOW" performance_cx_lowest="LOW" still: # sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% and, imho, cx_supported should list all available states, doesn't matter what is in rc.conf. (well, at least i reckon it's supposed to work that way.) but: i already had 3 Cx states back on 5.3. and when i had them, C2 was used most often (and C3 wasn't at all iirc). so what has changed in the system please and how am i to get back my states please ?? This is a totally different problem. I thought that the problem was simply not using all of the states. Instead, you are not even showing the states as available. Looks like the kernel is not reading the capabilities of your system correctly. This seems to coincide with the new ACPI code import. Sounds like something is not being handled properly and it is likely beyond my capability to track it down. I would suggest posting your the output of 'acpidump -t -d' on a web site and then sending a report with a pointer to that ASL to [EMAIL PROTECTED] There it will be seen by the folks who really know the ACPI stuff. hello! thank you, kevin. i did as you advised and here are the outputs of acpidump: # acpidump -t -d -o asus_w1n.dsdt > asus_w1n.asl acpidump: RSDT entry 1 (sig OEMB) is corrupt http://mato.gamato.org/freebsd/aw1n/asus_w1n.dsdt http://mato.gamato.org/freebsd/aw1n/asus_w1n.asl i look forward to hearing from you folks.. :-) many thanks! regards, martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
> Date: Sun, 18 Dec 2005 20:46:49 +0100 > From: martinko <[EMAIL PROTECTED]> > > Kevin Oberman wrote: > > >>Date: Sat, 17 Dec 2005 18:14:01 +0100 > >>From: martinko <[EMAIL PROTECTED]> > >> > >>Kevin Oberman wrote: > >> > >> > Date: Fri, 16 Dec 2005 14:29:39 -0600 > From: Craig Boston <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > > > >-cpu0: on acpi0 > >+cpu0: on acpi0 > > > >Q: Guessing that's a formatting difference, rather then 6.x not > >recognizing > >the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) > > > > > Not sure on this, but you're probably better off using EST anyway as I > think it gives you more control over the processor frequency. > > > >>>No. There is no conflict between Cx states and EST. Cx states specifies > >>>how deeply the CPU will sleep when idle. EST controls processor speed > >>>and voltage. In most cases, your REALLY want to use both of these. They > >>>are very significant in saving power. (Of course, USB tends to limit the > >>>effectiveness of Cx states. I need to run without USB to get really good > >>>battery life and to make suspend (S3) really ut power drain. > >>> > >>> > >>Kevin, > >> > >>I used to have 3 Cx states supported when I started with FreeBSD on > >>version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see > >>is just one supported Cx state. I much wonder why. (?) > >> > >> > > > >What value do you have in /etc/rc.conf (if any) for > >performance_cx_lowest? It defaults to HIGH which will limit you to only > >the most power hungry sleep state (simple halt). This was made the > >default because some hardware was breaking when this was defaulted to > >LOW. T0 get other Cx states to be utilized, add > >'performance_cx_lowest="LOW"' to /etc/rc.conf. > > > > > > i see. > > anyway: > > # grep cx /etc/rc.conf.local > economy_cx_lowest="LOW" > performance_cx_lowest="LOW" > > still: > > # sysctl hw.acpi.cpu > hw.acpi.cpu.cx_supported: C1/1 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > > and, imho, cx_supported should list all available states, doesn't matter > what is in rc.conf. (well, at least i reckon it's supposed to work that > way.) > > but: > > i already had 3 Cx states back on 5.3. > and when i had them, C2 was used most often (and C3 wasn't at all iirc). > > so what has changed in the system please and how am i to get back my > states please ?? This is a totally different problem. I thought that the problem was simply not using all of the states. Instead, you are not even showing the states as available. Looks like the kernel is not reading the capabilities of your system correctly. This seems to coincide with the new ACPI code import. Sounds like something is not being handled properly and it is likely beyond my capability to track it down. I would suggest posting your the output of 'acpidump -t -d' on a web site and then sending a report with a pointer to that ASL to [EMAIL PROTECTED] There it will be seen by the folks who really know the ACPI stuff. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sunday 18 December 2005 20:46, martinko wrote: > # sysctl hw.acpi.cpu > hw.acpi.cpu.cx_supported: C1/1 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > > and, imho, cx_supported should list all available states, doesn't matter > what is in rc.conf. (well, at least i reckon it's supposed to work that > way.) > > but: > > i already had 3 Cx states back on 5.3. > and when i had them, C2 was used most often (and C3 wasn't at all iirc). > > so what has changed in the system please and how am i to get back my > states please ?? This is exactly the thing you need to report via send-pr. Developers won't be aware of regression errors if they don't get reported. Cx states are configured via acpi, so I'd visit the acpi list and prepare a dump of your acpicode for the developers to look at. See acpidump(8) for details. -- Melvyn Sopacua [EMAIL PROTECTED] FreeBSD 6.0-STABLE Qt: 3.3.5 KDE: 3.4.3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Kevin Oberman wrote: Date: Sat, 17 Dec 2005 18:14:01 +0100 From: martinko <[EMAIL PROTECTED]> Kevin Oberman wrote: Date: Fri, 16 Dec 2005 14:29:39 -0600 From: Craig Boston <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] -cpu0: on acpi0 +cpu0: on acpi0 Q: Guessing that's a formatting difference, rather then 6.x not recognizing the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) Not sure on this, but you're probably better off using EST anyway as I think it gives you more control over the processor frequency. No. There is no conflict between Cx states and EST. Cx states specifies how deeply the CPU will sleep when idle. EST controls processor speed and voltage. In most cases, your REALLY want to use both of these. They are very significant in saving power. (Of course, USB tends to limit the effectiveness of Cx states. I need to run without USB to get really good battery life and to make suspend (S3) really ut power drain. Kevin, I used to have 3 Cx states supported when I started with FreeBSD on version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see is just one supported Cx state. I much wonder why. (?) What value do you have in /etc/rc.conf (if any) for performance_cx_lowest? It defaults to HIGH which will limit you to only the most power hungry sleep state (simple halt). This was made the default because some hardware was breaking when this was defaulted to LOW. T0 get other Cx states to be utilized, add 'performance_cx_lowest="LOW"' to /etc/rc.conf. i see. anyway: # grep cx /etc/rc.conf.local economy_cx_lowest="LOW" performance_cx_lowest="LOW" still: # sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% and, imho, cx_supported should list all available states, doesn't matter what is in rc.conf. (well, at least i reckon it's supposed to work that way.) but: i already had 3 Cx states back on 5.3. and when i had them, C2 was used most often (and C3 wasn't at all iirc). so what has changed in the system please and how am i to get back my states please ?? many thanks, martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Hi, Scott Long wrote: Peter Jeremy wrote: I think FreeBSD Update shows the way forward but IMHO there needs to be an "official" binary update tool accessible from www.freebsd.org. FreeBSD Update was written by, and is continuously maintained by the actual FreeBSD Security Officer. It's as official as it gets. If the only barrier to acceptance is that it's not distributed from the FreeBSD.org domain, then a) that's a silly argument, and b) it's easily solvable so long as Colin agrees. isn't this the problem Microsoft faces all the while when users download the latest security patch from somewhere in the Internet? Teaching water and drinking wine? Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Sat, 2005-Dec-17 18:19:25 -0700, Scott Long wrote: >Peter Jeremy wrote: >>I think FreeBSD Update shows the way forward but IMHO there needs to >>be an "official" binary update tool accessible from www.freebsd.org. > >FreeBSD Update was written by, and is continuously maintained by the >actual FreeBSD Security Officer. I realise that. But nowhere does it state that it is an "official" Project tool (though it no longer seems to include the "this is not sanctioned by the FreeBSD Project" disclaimer that I thought it used to have). > If the only barrier to acceptance is that it's not distributed from the >FreeBSD.org domain, then a) that's a silly argument, and b) it's easily >solvable so long as Colin agrees. I agree it's easily solvable. I disagree that it's a silly argument. As an end user, I would expect to find online updates to Solaris at sun.com, Microsoft at microsoft.com, etc. If I run FreeBSD, I would expect to find FreeBSD updates at freebsd.org, not daemonology.net. A quick search starting at www.freebsd.org does not throw up any references to FreeBSD Update. If I didn't know that Colin Percival was the SO, there would be nothing to suggest that FreeBSD Update had any relationship to the FreeBSD Project. Computer users are slowly cottoning on to the idea of computer security. This is good. Encouraging them to find an apparently arbitrary site that says "upgrade your operating system here" does nothing to reinforce the concept that people should be careful about downloading software from "unknown" sources. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Peter Jeremy wrote: On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote: I agree. And after all, tracking a security branch isn't too difficult, ... # cd /usr/src # patch < /path/to/patch # cd /usr/src/gnu/usr.bin/cvs/cvsbug # make obj && make depend && make && make install # cd /usr/src/gnu/usr.bin/send-pr # make obj && make depend && make && make install Is that difficult? Speaking as a developer, I think it's trivially easy. As an end user, I don't think this is acceptable. Firstly, it requires that the user has installed the src distribution - which is optional. Secondly, the user is expected to use development tools without understanding what they do - this is scary for them. Running the above commands is OK as long as nothing goes wrong but the "support" group (who inhabit -questions and answer seemingly silly questions) are going to have to cope with people who've made a typo somewhere in the sequence and can't explain exactly what they did - without putting them off FreeBSD. I think FreeBSD Update shows the way forward but IMHO there needs to be an "official" binary update tool accessible from www.freebsd.org. FreeBSD Update was written by, and is continuously maintained by the actual FreeBSD Security Officer. It's as official as it gets. If the only barrier to acceptance is that it's not distributed from the FreeBSD.org domain, then a) that's a silly argument, and b) it's easily solvable so long as Colin agrees. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sunday 18 December 2005 01:13, Kevin Oberman wrote: > > Date: Sat, 17 Dec 2005 18:14:01 +0100 > > From: martinko <[EMAIL PROTECTED]> > > > > Kevin Oberman wrote: > > >>Date: Fri, 16 Dec 2005 14:29:39 -0600 > > >>From: Craig Boston <[EMAIL PROTECTED]> > > >>Sender: [EMAIL PROTECTED] > > >> > > >>>-cpu0: on acpi0 > > >>>+cpu0: on acpi0 > > >>> > > >>>Q: Guessing that's a formatting difference, rather then 6.x not > > >>> recognizing the states (sysctl hw.acpi.cpu.cx_supported confirms 4 > > >>> states) > > >> > > >>Not sure on this, but you're probably better off using EST anyway as I > > >>think it gives you more control over the processor frequency. > > > > > > No. There is no conflict between Cx states and EST. Cx states specifies > > > how deeply the CPU will sleep when idle. EST controls processor speed > > > and voltage. In most cases, your REALLY want to use both of these. They > > > are very significant in saving power. (Of course, USB tends to limit > > > the effectiveness of Cx states. I need to run without USB to get really > > > good battery life and to make suspend (S3) really ut power drain. > > > > Kevin, > > > > I used to have 3 Cx states supported when I started with FreeBSD on > > version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see > > is just one supported Cx state. I much wonder why. (?) > > What value do you have in /etc/rc.conf (if any) for > performance_cx_lowest? It defaults to HIGH which will limit you to only > the most power hungry sleep state (simple halt). This was made the > default because some hardware was breaking when this was defaulted to > LOW. T0 get other Cx states to be utilized, add > 'performance_cx_lowest="LOW"' to /etc/rc.conf. Doesn't affect hw.acpi.cpu.cx_supported though, so that's the thing to check: # sysctl hw.acpi.cpu.cx_supported; grep performance /etc/rc.conf|wc -l hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C4/185 0 -- Melvyn Sopacua [EMAIL PROTECTED] FreeBSD 6.0-STABLE Qt: 3.3.5 KDE: 3.4.3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
> Date: Sat, 17 Dec 2005 18:14:01 +0100 > From: martinko <[EMAIL PROTECTED]> > > Kevin Oberman wrote: > >>Date: Fri, 16 Dec 2005 14:29:39 -0600 > >>From: Craig Boston <[EMAIL PROTECTED]> > >>Sender: [EMAIL PROTECTED] > >> > >> > >>>-cpu0: on acpi0 > >>>+cpu0: on acpi0 > >>> > >>>Q: Guessing that's a formatting difference, rather then 6.x not > >>>recognizing > >>>the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) > >> > >>Not sure on this, but you're probably better off using EST anyway as I > >>think it gives you more control over the processor frequency. > > > > > > No. There is no conflict between Cx states and EST. Cx states specifies > > how deeply the CPU will sleep when idle. EST controls processor speed > > and voltage. In most cases, your REALLY want to use both of these. They > > are very significant in saving power. (Of course, USB tends to limit the > > effectiveness of Cx states. I need to run without USB to get really good > > battery life and to make suspend (S3) really ut power drain. > > > Kevin, > > I used to have 3 Cx states supported when I started with FreeBSD on > version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see > is just one supported Cx state. I much wonder why. (?) What value do you have in /etc/rc.conf (if any) for performance_cx_lowest? It defaults to HIGH which will limit you to only the most power hungry sleep state (simple halt). This was made the default because some hardware was breaking when this was defaulted to LOW. T0 get other Cx states to be utilized, add 'performance_cx_lowest="LOW"' to /etc/rc.conf. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
> From: George Hartzell <[EMAIL PROTECTED]> > Date: Fri, 16 Dec 2005 16:05:51 -0800 > > Kevin Oberman writes: > > [...] > > No. There is no conflict between Cx states and EST. Cx states specifies > > how deeply the CPU will sleep when idle. EST controls processor speed > > and voltage. In most cases, your REALLY want to use both of these. They > > are very significant in saving power. (Of course, USB tends to limit the > > effectiveness of Cx states. I need to run without USB to get really good > > battery life and to make suspend (S3) really ut power drain. > > Can you expand a bit on that "Of course USB...". What's the problem > with USB? Can one just kunload it before suspend? > > g. Only a bit. I believe it is the polling activity of the USB driver that causes the problem, but, if USB drivers are loaded, most systems will never get to the "deeper" sleep levels. My T30 has 3 sleep level of which C2 is only a very modest power savings over C1. C3 is a significant savings, but it is never used if USB devices are present. If you unload the drivers, you should be to lower levels. Take a look at sysctl hw.acpi.cpu for detail and to see how much time is spent in each sleep state. I assume that you can unload the drivers, but my kernel has USB at this time. I do plan on building a kernel without USB and see if unloading is a workable solution. I think it should be. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote: >I agree. And after all, tracking a security branch isn't too difficult, ... ># cd /usr/src ># patch < /path/to/patch ># cd /usr/src/gnu/usr.bin/cvs/cvsbug ># make obj && make depend && make && make install ># cd /usr/src/gnu/usr.bin/send-pr ># make obj && make depend && make && make install > >Is that difficult? Speaking as a developer, I think it's trivially easy. As an end user, I don't think this is acceptable. Firstly, it requires that the user has installed the src distribution - which is optional. Secondly, the user is expected to use development tools without understanding what they do - this is scary for them. Running the above commands is OK as long as nothing goes wrong but the "support" group (who inhabit -questions and answer seemingly silly questions) are going to have to cope with people who've made a typo somewhere in the sequence and can't explain exactly what they did - without putting them off FreeBSD. I think FreeBSD Update shows the way forward but IMHO there needs to be an "official" binary update tool accessible from www.freebsd.org. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Wilko Bulte wrote: On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: There will be three FreeBSD 6 releases in 2006. While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. So, when will you fix it? Or hire someone to fix it? FreeBSD after all is mostly a volunteer operation. I agree. And after all, tracking a security branch isn't too difficult, but the most people think that they have to do a complete "make buildworld" after a security advisory, but this isn't true. For example there was that cvsbug issue in September: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug.asc One can read here: b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/gnu/usr.bin/cvs/cvsbug # make obj && make depend && make && make install # cd /usr/src/gnu/usr.bin/send-pr # make obj && make depend && make && make install Is that difficult? I don't think so. No reboot required and it doesn't take more than 5 minutes even on a slower machine. Only the vulnerabilities in the kernel are problematic for servers, since they require a reboot. I think I'll submit a PR with a patch to clarify this in Handbook. Do you consider this useful? Regards, Gabor Kovesdan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > There will be three FreeBSD 6 releases in 2006. > > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. > > It has been bad, it's getting worse. So, when will you fix it? Or hire someone to fix it? FreeBSD after all is mostly a volunteer operation. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > There will be three FreeBSD 6 releases in 2006. While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Kevin Oberman wrote: Date: Fri, 16 Dec 2005 14:29:39 -0600 From: Craig Boston <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] -cpu0: on acpi0 +cpu0: on acpi0 Q: Guessing that's a formatting difference, rather then 6.x not recognizing the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) Not sure on this, but you're probably better off using EST anyway as I think it gives you more control over the processor frequency. No. There is no conflict between Cx states and EST. Cx states specifies how deeply the CPU will sleep when idle. EST controls processor speed and voltage. In most cases, your REALLY want to use both of these. They are very significant in saving power. (Of course, USB tends to limit the effectiveness of Cx states. I need to run without USB to get really good battery life and to make suspend (S3) really ut power drain. Kevin, I used to have 3 Cx states supported when I started with FreeBSD on version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see is just one supported Cx state. I much wonder why. (?) Cheers, Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Security updates will be maintained for quite a while. However, it takes manpower to test each proposed security change, so it's very hard to justify doing them 'indefinitely'. The stated policy from the security team is 2 years. So they will probably support 5.5 into 2008, but I wanted to be conservative in my statement in case they have different plans. It seems to me like FBSD may be pushing too much to a new major version. Although NBSD is stepping up the "-release" versions significantly, I feel that FBSD (and friends, but this is hardly the place for B&W about them) are/is moving a bit too quickly. While the SMP changes are nice and all (my main application server at home is a dual coppermine 1GHz), the tty (for example) seems to be getting more and more unstable as it goes on... this seems to a certain degree to be that features in -CURRENT are barely cooking let alone baking, and talk is already that 5.x is obsolete. Pushing off GIANT was a 5.x goal iirc, and making existing changes stable is a per-major goal (again, imho). It seems like the version numbers aren't actually meaningfull anymore. I mean... I'm used to a FBSD that would change majors when an API and/or ABI *needed* changing. It feels like it's happening 'cause it'd be "cool" to have a 7.x now. The FBSD pthread support for example has been better than Linux since libc_r... and it's only improved. But I can't actualy *rely* on anything specific working. A project I work on has had a THREADS_ACTUALLY_WORK flag available for Linux when they acually do (not yet, let's not talk about sigwait()) for the last few years. But I can't depend on a major version for strtold()... can't even depend on a > comparison. It's hard to know what to depend on now... "Things are Changing" and you need to know exactly what you need to discover what is required. A few years ago, I was flabbergasted when I was asked for a way to identify the libc version under FBSD. The need to do something like that never occured to me the possibility of having libc "out of sync" with the kernel never even crossed my mind, and the reason was that the whole thing was one system. It's starting to feel a lot more like some Linux system now... only without the spiffy up2date thinger to go with it. Upgrading from major to major has been something I never minded when needed, but it's too needed now and there's nothing to make it happy. Either the OBSD "no need to rebuild GENERIC" model is being accepted, or we're dumping the "/etc/,/usr/*/etc/*" backup and restore model. I love rcNG for example... but my OPL3 no longer does anything usefull... I had an AWE32 with gobs of RAM plugged in and had to use the Voxware drivers until I couldn't... and now I *need* to use timidity because what other choice do I have? I guess I'm old-fashioned, but I just recently managed to have my LaserWriter 16/600 (using the built-in AUI port) be as easy to set up with CUPS as with printcap I was happy and joyfull. But I had to *manually* do the /usr/bin/* and /usr/sbin/* symlinks *and rebuild KDE samba, and OOo. Why? Probobly 'cause I had lpr working before... does the vaunted handbook even suggest CUPS is there the slighest hint of a migration path? My home NIS and NFS server recently became a Solaris 10 one because it Just Works -- despite the inetd, local service, etc horribleness (still not an AMd fan... mount /home via NFS and don't worry) but I'm worried... even I, a FBSD fanatic am moving my servives off of my various FBSD boxes. Why? They may not work when Things are Better. FBSD currently out "sells" any *nix you pick... *BSD, */Linux, heck, *X.. but when Apache and PostgreSQL move to Linux as their primary system (and the world yawns... let's not talk about BDB) this is a wake-up call... I still haven't tried DragonFly, I think their development model is surpassed by FBSD. But hey, they fixed their clock and no other BSD did. Small incremental fixes. Have we lost that? One tool for the job. Perl killed it? FBSD is *NOT* a kernel bsdtar is *way* too late to make excuses for... where did the pascal compiler go? Significant performance and stability enhancements that simply cannot be broken up and backported to FreeBSD 5. We are marching towards a 'Giant-less' kernel, which means continuing better SMP performance and better UP responsiveness. With 6.0 we are finally starting to see the benefit of the SMPng work that we've been doing for 5 years. iirc, this was a 5.x goal. We get a Major with no reason. Release notes between Majors are BORING... one needs to look at the userland to get anything they expect to use, and *BASIC* subsystems like the tty suffer. Will UP ever match what it once was? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL
Re: HEADS UP: Release schedule for 2006
Melvyn Sopacua <[EMAIL PROTECTED]> wrote: > Features=0xa7e9f9bf LUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> > + Features2=0x180 > > Q: What are those extra features Enhanced Speedstep, Thermal Monitor 2. > and are they useful? ;-) Yes. The kernel's cpufreq framework will use them. > -ACPI link \\_SB_.PCI0.LNKB has invalid initial irq 11, ignoring > +pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid > > Q: Could this be midi? Possibly. Look at the output of "pciconf -lv" and search for the entry for bus 0, slot 31. > -Timecounter "TSC" frequency 1398819442 Hz quality 800 > -Timecounters tick every 10.000 msec > +Timecounter "TSC" frequency 1398819606 Hz quality 800 > +Timecounters tick every 1.000 msec > > Q: This is a big scarey difference :p This isn't a printf bug I presume? No, the default of HZ changed from 100 to 1000. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 01:42:55PM -0600, Mark Linimon wrote: > On Fri, Dec 16, 2005 at 10:41:49AM -0800, Gary Kline wrote: > > I didn't move until 5 until 5.2+; it was a major move. > > There were lots of things to get-right. So maybe by > > 6.5, 6 will be granite stable. > > (Disclaimer: I am not on re@ but I do watch the bugs come in as one of > the bugmasters). > > We completely redid the way we did release engineering between the 5.X > series and 6.X series to avoid ever inflicting that much pain again. > > The jump from 5.2 to 5.3 was huge and we learned many things not to do. > The jump from 5.3 to 5.4 was pretty minor -- but so is the jump from > 5.4 to 6.0. The emphasis was on a smaller feature set and a much longer > (painfully long :-) ) period of QA. The win for me with 5.2.1 last summer was tha it finally let me begin to get my ThinkPad 600E working. 5.3 may have been required to bring the bizarre sound chip to life. It's got some some kind of microsoft idiosyncrasy. I'm at .3-STABLE everywhere and now moving cautiously to .4. YES to your smaller jumps. If memory serves, we made two fairly hard moves. First from 2.x.y to 3.x to get rid of a.out; then 4.x to 5.x for the new filesystem paradigm. I can see anything beyond the i868 being in the 64-bit world; (*sigh*) :-) > > The result in the PR database is that for 6.0 vs 5.4, although there > are a number of regressions (in particular, certain i386 hardware), the > number of entries is far, far, less than for the 5.2.1 to 5.3 transition. > > So I would urge people to change their view of 6.0. From what I can > tell it's one of our strongest releases. It certainly must be the > strongest .0 release. > > In any case, I don't believe there are going to be .5 and .6 releases > going forwards. This will keep us, in the future, from spending so > much time on MFCs. I'm still planning on not upping to 6 until 6.2 or better. Not unless 6.0/.1 has absolutely push-button audio so I can play real, mp3, m3u, ogg, windows-audio/whatever! > > Some of this background is further detailed in an article I wrote: > > http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/version-guide/past-schedules.html > > I hope that people will find the information there useful. Good one! thanks for putting that together. == Q == Does anybody know why there is no article.freebsd.org v-site that people could find stuff like this more easily? It probab;y could be done with a link/symlink and a DNS entry for the virtual website. gary > > And, if someone ever wants to write that 5.X vs 6.X vs 7.X feature list > comparison, now would be a good time :-) > > mcl -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 02:59:09PM + I heard the voice of Joao Barros, and lo! it spake thus: > > There have been some questions on the lists about what to expect > from release x.y and I personnally have always looked at the TODO > list like http://www.freebsd.org/releases/6.0R/todo.html It's always been my impression that the todo list is put together as we close in on a release as a "these things still need to get done". It's not really a "here are the things this release offers over the previous one"... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
> Gary Kline wrote: > > Are you volunteering to post the TODO lists here on -stable > > every N months? I think it's a great idea to have some > > clues about where we're going, or hope to be going. No I am not. But you are right on the "it's a great idea to have some clues about where we're going, or hope to be going" part. That was my point. On 12/16/05, Scott Long <[EMAIL PROTECTED]> wrote: > The release TODO list is maintained on the FreeBSD.org website, As I pointed, available for anyone interested in knowing what's going on. > though > it's usually only active during release cycles. Yes, but until that time only by reading yours and other Dev's answers to the same questions one knows where a Release is heading. The users know what to expect and the Dev's know what they set themselfes to do :-) -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Kevin Oberman writes: > [...] > No. There is no conflict between Cx states and EST. Cx states specifies > how deeply the CPU will sleep when idle. EST controls processor speed > and voltage. In most cases, your REALLY want to use both of these. They > are very significant in saving power. (Of course, USB tends to limit the > effectiveness of Cx states. I need to run without USB to get really good > battery life and to make suspend (S3) really ut power drain. Can you expand a bit on that "Of course USB...". What's the problem with USB? Can one just kunload it before suspend? g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 06:31:17AM -0500, Scott Robbins wrote: > I have to add my vote for 6, as did someone else in an earlier post. > Like some others, I always found 5.x a bit slower than 4.x (No > benchmarks, completely subjective.) From the very beginning, I've found > 6.x to be stable and quickly moved some non-critical servers to it. I will add my me too here. I move my home computer to 6.0 when I get back a connexion at home. My office computer used to seem far faster than my home one (quite normal for a 3.2 GHz PIV against an Athlon 1800+, with twice memory) but after some weeks of 6.0 on my Athlon and _many_ ports building (mostly because of the damned f*** last OCaml release) the relative difference seems far less impressive. This also quite subjective, but my feeling is that speed impressions is as important as real speed improvements, at least for workstation. Just note that my actual usage is only LaTeX (PhD writing ... ) and ports building. This was my 2 cents. -- Marwan Burelle, http://www.lri.fr/~burelle ( [EMAIL PROTECTED] | [EMAIL PROTECTED] ) http://www.cduce.org pgp9QyPpZGrIm.pgp Description: PGP signature
Re: HEADS UP: Release schedule for 2006
On Friday 16 December 2005 21:45, Peter Jeremy wrote: > EST - Enhanced SpeedStep > TM2 - Thermal Monitor 2 Hm, guess I'll play with mbmon to see if this shows more then one monitor (assuming the 2 is the number of, not the protocol version). > >-pci0: at device 29.7 (no driver attached) > >+ehci0: mem > >0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 > >+ehci0: [GIANT-LOCKED] > > > >Kudos! > > I'm still trying to get my USB2 to do anything more than probe :-( Ouch, well guess I'll have to find that memory stick I should have around here somewhere. > >-Timecounter "TSC" frequency 1398819442 Hz quality 800 > >-Timecounters tick every 10.000 msec > >+Timecounter "TSC" frequency 1398819606 Hz quality 800 > >+Timecounters tick every 1.000 msec > > > >Q: This is a big scarey difference :p This isn't a printf bug I presume? > > Which bit? The TSC is notoriously unstable and a relative change of > 1.2e-7 can be ignored. If you look at kern.clockrate, you'll see that > hz now defaults to 1000. Ah! That explains why rtc was complaining on 5.x but magically stopped doing that on 6. > >-acd0: CDRW at ata1-master PIO4 > >+acd0: CDRW at ata1-master UDMA33 > > > >That's *very* nice! > > Again, that's just a change in defaults. Problems were found with DMA to > ATAPI devices so the decision was made to default to PIO4 in 5.x. You can > set hw.ata.atapi_dma to 1 in 5.x if you want to (see acd(4)). Problems as in long waits on `burncd blank` and subsequent i/o errors and unmountable disks that disappear after reboot? -- Melvyn Sopacua [EMAIL PROTECTED] FreeBSD 6.0-STABLE Qt: 3.3.5 KDE: 3.4.3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
> Date: Fri, 16 Dec 2005 14:29:39 -0600 > From: Craig Boston <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > -cpu0: on acpi0 > > +cpu0: on acpi0 > > > > Q: Guessing that's a formatting difference, rather then 6.x not recognizing > > the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) > > Not sure on this, but you're probably better off using EST anyway as I > think it gives you more control over the processor frequency. No. There is no conflict between Cx states and EST. Cx states specifies how deeply the CPU will sleep when idle. EST controls processor speed and voltage. In most cases, your REALLY want to use both of these. They are very significant in saving power. (Of course, USB tends to limit the effectiveness of Cx states. I need to run without USB to get really good battery life and to make suspend (S3) really ut power drain. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, 2005-Dec-16 21:20:44 +0100, Melvyn Sopacua wrote: >Features=0xa7e9f9bf >+ Features2=0x180 > >Q: What are those extra features and are they useful? ;-) This is just printing out the CPU features bitmasks. The difference is that the CPU identification code in 6.x looks at the bitmap returned in %ecx after a cpuid 1. The features were always there, 6.x just prints them out. As for usefulness... EST - Enhanced SpeedStep TM2 - Thermal Monitor 2 >+uhci0: [GIANT-LOCKED] >+uhci1: [GIANT-LOCKED] >+uhci2: [GIANT-LOCKED] > >Q: Again - is this formatting or are these (and the ones below) still under >Giant in 6.x but not in 5.x? No. 6.x is just more verbose. I thought these had all been hidden behind 'verbose' as they are primarily hints to the developers. >-pci0: at device 29.7 (no driver attached) >+ehci0: mem >0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 >+ehci0: [GIANT-LOCKED] > >Kudos! I'm still trying to get my USB2 to do anything more than probe :-( >-Timecounter "TSC" frequency 1398819442 Hz quality 800 >-Timecounters tick every 10.000 msec >+Timecounter "TSC" frequency 1398819606 Hz quality 800 >+Timecounters tick every 1.000 msec > >Q: This is a big scarey difference :p This isn't a printf bug I presume? Which bit? The TSC is notoriously unstable and a relative change of 1.2e-7 can be ignored. If you look at kern.clockrate, you'll see that hz now defaults to 1000. >-acd0: CDRW at ata1-master PIO4 >+acd0: CDRW at ata1-master UDMA33 > >That's *very* nice! Again, that's just a change in defaults. Problems were found with DMA to ATAPI devices so the decision was made to default to PIO4 in 5.x. You can set hw.ata.atapi_dma to 1 in 5.x if you want to (see acd(4)). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 09:20:44PM +0100, Melvyn Sopacua wrote: > + Features2=0x180 > > Q: What are those extra features and are they useful? ;-) Enhanced Speedstep and Thermal Management. They're useful if you want to use powerd to conserve power / reduce heat generation. (load the cpufreq driver and look in sysctl dev.cpu) > -cpu0: on acpi0 > +cpu0: on acpi0 > > Q: Guessing that's a formatting difference, rather then 6.x not recognizing > the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) Not sure on this, but you're probably better off using EST anyway as I think it gives you more control over the processor frequency. > +uhci0: [GIANT-LOCKED] > +uhci1: [GIANT-LOCKED] > +uhci2: [GIANT-LOCKED] > > Q: Again - is this formatting or are these (and the ones below) still under > Giant in 6.x but not in 5.x? Just formatting. USB (and a lot more) was under GIANT in 5.x as well, but 5.x didn't tell you which drivers were running under GIANT. 6.x does as a gentle reminder that those areas need to be worked on ;) Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Friday 16 December 2005 20:42, Mark Linimon wrote: > And, if someone ever wants to write that 5.X vs 6.X vs 7.X feature list > comparison, now would be a good time :-) Well, here's a nice start (and a question or two slipped in) - dmesg diff between two GENERIC kernels 5 vs 6 stable of the same date, same hardware. Noise reduced (mem range flips on hw, 'same' entries): -FreeBSD 5.4-STABLE #3: Sun Nov 20 03:52:04 CET 2005 -[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC +FreeBSD 6.0-STABLE #1: Wed Dec 7 01:36:46 CET 2005 +[EMAIL PROTECTED]:/usr/obj/usr/current/src/sys/GENERIC Features=0xa7e9f9bf + Features2=0x180 Q: What are those extra features and are they useful? ;-) +npx0: [FAST] -cpu0: on acpi0 +cpu0: on acpi0 Q: Guessing that's a formatting difference, rather then 6.x not recognizing the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) -ACPI link \\_SB_.PCI0.LNKB has invalid initial irq 11, ignoring +pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid Q: Could this be midi? +uhci0: [GIANT-LOCKED] +uhci1: [GIANT-LOCKED] +uhci2: [GIANT-LOCKED] Q: Again - is this formatting or are these (and the ones below) still under Giant in 6.x but not in 5.x? -pci0: at device 29.7 (no driver attached) +ehci0: mem 0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 +ehci0: [GIANT-LOCKED] +usb3: EHCI version 1.0 +usb3: companion controllers, 2 ports each: usb0 usb1 usb2 +usb3: on ehci0 +usb3: USB revision 2.0 +uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 +uhub3: 6 ports with 6 removable, self powered Kudos! -atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 -ata0: channel #0 on atapci0 -ata1: channel #1 on atapci0 -pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 5 at device 31.5 on pci0 -pcm0: +atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 +ata0: on atapci0 +ata1: on atapci0 +pci0: at device 31.5 (no driver attached) Didn't have snd_ich_load="YES" in loader.conf yet. pcm0 appears the same and is GIANT-LOCKED on 6. +atkbd0: [GIANT-LOCKED] +psm0: [GIANT-LOCKED] -Timecounter "TSC" frequency 1398819442 Hz quality 800 -Timecounters tick every 10.000 msec +Timecounter "TSC" frequency 1398819606 Hz quality 800 +Timecounters tick every 1.000 msec Q: This is a big scarey difference :p This isn't a printf bug I presume? -acd0: CDRW at ata1-master PIO4 +acd0: CDRW at ata1-master UDMA33 That's *very* nice! -- Melvyn Sopacua [EMAIL PROTECTED] FreeBSD 6.0-STABLE Qt: 3.3.5 KDE: 3.4.3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 10:41:49AM -0800, Gary Kline wrote: > I didn't move until 5 until 5.2+; it was a major move. > There were lots of things to get-right. So maybe by > 6.5, 6 will be granite stable. (Disclaimer: I am not on re@ but I do watch the bugs come in as one of the bugmasters). We completely redid the way we did release engineering between the 5.X series and 6.X series to avoid ever inflicting that much pain again. The jump from 5.2 to 5.3 was huge and we learned many things not to do. The jump from 5.3 to 5.4 was pretty minor -- but so is the jump from 5.4 to 6.0. The emphasis was on a smaller feature set and a much longer (painfully long :-) ) period of QA. The result in the PR database is that for 6.0 vs 5.4, although there are a number of regressions (in particular, certain i386 hardware), the number of entries is far, far, less than for the 5.2.1 to 5.3 transition. So I would urge people to change their view of 6.0. From what I can tell it's one of our strongest releases. It certainly must be the strongest .0 release. In any case, I don't believe there are going to be .5 and .6 releases going forwards. This will keep us, in the future, from spending so much time on MFCs. Some of this background is further detailed in an article I wrote: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/version-guide/past-schedules.html I hope that people will find the information there useful. And, if someone ever wants to write that 5.X vs 6.X vs 7.X feature list comparison, now would be a good time :-) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Friday 16 December 2005 10:41 am, Gary Kline wrote: > On Fri, Dec 16, 2005 at 06:31:17AM -0500, Scott Robbins wrote: > > > After upgrading to 6-stable, I got regular hang-ups of > > > the system (endless loop?) when swapspace is used > > > extensively. Never happened with 5. > > I didn't move until 5 until 5.2+; it was a major move. > There were lots of things to get-right. So maybe by > 6.5, 6 will be granite stable. I feel compelled to point out that 5 wasn't called -stable until 5.3. 5.0-5.2 were early adopter releases. So 6.n isn't comparable to 5.n (as always YMMV). My understanding is that the whole point of this expedited release process is to avoid the feature creep that leads to huge and sometimes painful leaps (like 4 to 5 was). -David -- "What's the good of having mastery over cosmic balance and knowing the secrets of fate if you can't blow something up?" -Terry Pratchett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Gary Kline wrote: On Fri, Dec 16, 2005 at 02:59:09PM +, Joao Barros wrote: On 12/16/05, Scott Long <[EMAIL PROTECTED]> wrote: FreeBSD 7 We will start preparing for FreeBSD 7.0 in June 2007. I'll hopefully update the release engineering pages soon to reflect this. If you have any questions, please feel free to contact me and the rest of the release engineering team. Thanks!ott There have been some questions on the lists about what to expect from release x.y and I personnally have always looked at the TODO list like http://www.freebsd.org/releases/6.0R/todo.html For 6.0 I noticed there were more updates on that page for bugs and their fixes than for features per se. My sugestion, maybe at a first stage setting the TODO list has it's advantages, one knows what to expect from a release, it's clearly stated and documented there and the developers can see their goals. This is valid for minor and major releases of course. How about it? Are you volunteering to post the TODO lists here on -stable every N months? I think it's a great idea to have some clues about where we're going, or hope to be going. gary The release TODO list is maintained on the FreeBSD.org website, though it's usually only active during release cycles. I used to also email it out in text format to the mailing lists on a weekly basis. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 02:59:09PM +, Joao Barros wrote: > On 12/16/05, Scott Long <[EMAIL PROTECTED]> wrote: > > > FreeBSD 7 > > We will start preparing for FreeBSD 7.0 in June 2007. > > > > I'll hopefully update the release engineering pages soon to reflect > > this. If you have any questions, please feel free to contact me and the > > rest of the release engineering team. Thanks!ott > > There have been some questions on the lists about what to expect from > release x.y and I personnally have always looked at the TODO list like > http://www.freebsd.org/releases/6.0R/todo.html > For 6.0 I noticed there were more updates on that page for bugs and > their fixes than for features per se. My sugestion, maybe at a first > stage setting the TODO list has it's advantages, one knows what to > expect from a release, it's clearly stated and documented there and > the developers can see their goals. > This is valid for minor and major releases of course. > > How about it? > Are you volunteering to post the TODO lists here on -stable every N months? I think it's a great idea to have some clues about where we're going, or hope to be going. gary > -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 06:31:17AM -0500, Scott Robbins wrote: > > A "me too" here for 5-Stable. > > > > I have a test PC, that was running 5-Stable using an > > additional swapfile to extend swap space. Never any > > problems at all with 5. > > > > After upgrading to 6-stable, I got regular hang-ups of > > the system (endless loop?) when swapspace is used > > extensively. Never happened with 5. I didn't move until 5 until 5.2+; it was a major move. There were lots of things to get-right. So maybe by 6.5, 6 will be granite stable. I've been using FBSD since 2.0.5, and while lots of solid features have been thoughtfully added, I just don't see that 6 buys that much more than 5.x. Maybe 7.x, tho... gary > > I have to add my vote for 6, as did someone else in an earlier post. > Like some others, I always found 5.x a bit slower than 4.x (No > benchmarks, completely subjective.) From the very beginning, I've found > 6.x to be stable and quickly moved some non-critical servers to it. > > After testing, we moved the more critical servers to it as well, and > have been quite happy withe results. > > Again, completely subjective, but from the beginning 6.x seemed faster > and more responsive than 5.x > Hmm. A series of benchmarks might prove some points. Back in Aug, 2001 I ran stress tests and other benchmarks to test *this* hardware. I pushed things to a loadave of > 70. Everything held. Maybe we should consider something like this. A series of hard stress tests as well as objective benchmarks as we go forward. It would give one some metrics... . gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, December 16, 2005 11:45 am, Frank Mayhar said: > Well, there is _one_ reason. I, too, have (almost) all of my machines > up to 6-stable, with the very notable exception of the one that runs > asterisk. Unfortunately, last I looked, the zaptel drivers hadn't been > ported to 6. I found this out the hard way when I upgraded and my VOIP > setup failed spectacularly. I then downgraded back to 5.4 and have been > there ever since, siiigh. -- The zaptel drivers are working fine on 6, check the archives of the asterisk-bsd list: http://lists.digium.com/pipermail/asterisk-bsd/2005-December/001363.html The latest asterisk from CVS HEAD compiles and runs very well on FreeBSD 6-STABLE -give it a try. -kim -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, 2005-12-16 at 09:57 +0100, Oliver Fromme wrote: > I've seen reports of a few people who had problems with > 6.0, but personally I didn't have any, and I wouldn't > want to go back. In fact I can't think of a single > reason why I wouldn't upgrade a FreeBSD machine to 6.x. Well, there is _one_ reason. I, too, have (almost) all of my machines up to 6-stable, with the very notable exception of the one that runs asterisk. Unfortunately, last I looked, the zaptel drivers hadn't been ported to 6. I found this out the hard way when I upgraded and my VOIP setup failed spectacularly. I then downgraded back to 5.4 and have been there ever since, siiigh. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On 12/16/05, Scott Long <[EMAIL PROTECTED]> wrote: > FreeBSD 7 > We will start preparing for FreeBSD 7.0 in June 2007. > > I'll hopefully update the release engineering pages soon to reflect > this. If you have any questions, please feel free to contact me and the > rest of the release engineering team. Thanks!ott There have been some questions on the lists about what to expect from release x.y and I personnally have always looked at the TODO list like http://www.freebsd.org/releases/6.0R/todo.html For 6.0 I noticed there were more updates on that page for bugs and their fixes than for features per se. My sugestion, maybe at a first stage setting the TODO list has it's advantages, one knows what to expect from a release, it's clearly stated and documented there and the developers can see their goals. This is valid for minor and major releases of course. How about it? -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 16, 2005 at 02:50:05AM -0800, Rob wrote: > Gary Kline wrote: > > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long > wrote: > > > >>All, > >> > >>The following is the approximate schedule for > FreeBSD releases in 2006: > >> > > Sounds like an ambitious schedule... All my FBSD > servers > > are at least up to 5.3; my laptop is happy at 5.4. > I have > > what I believe to be a rationalquestion. > > A "me too" here for 5-Stable. > > I have a test PC, that was running 5-Stable using an > additional swapfile to extend swap space. Never any > problems at all with 5. > > After upgrading to 6-stable, I got regular hang-ups of > the system (endless loop?) when swapspace is used > extensively. Never happened with 5. I have to add my vote for 6, as did someone else in an earlier post. Like some others, I always found 5.x a bit slower than 4.x (No benchmarks, completely subjective.) From the very beginning, I've found 6.x to be stable and quickly moved some non-critical servers to it. After testing, we moved the more critical servers to it as well, and have been quite happy withe results. Again, completely subjective, but from the beginning 6.x seemed faster and more responsive than 5.x - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Have I ever let you down? Giles: Do you want me to answer that, or shall I just glare? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoqWF+lTVdes0Z9YRAoKhAKCKDOxqSbwz9qwf9HowpmyOP249PwCfbjY0 LjZzXXCn/Jy76/8JA+p+0A4= =yVGK -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Gary Kline wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > >>All, >> >>The following is the approximate schedule for FreeBSD releases in 2006: >> >>Jan 30: Freeze RELENG_5 and RELENG_6 >>Mar 20: Release FreeBSD 6.1 >>Apr 3: Release FreeBSD 5.5 >>Jun 12: Freeze RELENG_6 >>Jul 31: Release FreeBSD 6.2 >>Oct 23: Freeze RELENG_6 >>Dec 11: Release FreeBSD 6.3 >> >>A 'freeze' means that the tree will be closed to changes except with >>specific approval, and the focus will be on producing, testing, and >>fixing release candidates. The release dates are targets that we hope >>to make, but we will continue with the policy of only releasing once >>all of the showstoppers are cleared, i.e. we will release when it is >>ready. >> >>FreeBSD 5 >>5.5 will be the final release from the RELENG_5 tree. We are doing it >>to provide support for users who have committed to FreeBSD 5 and who >>need more time to transition to FreeBSD 6. However, in order to keep >>forward progress with FreeBSD 6, we will produce this in parallel with >>the 6.1 release, and thus it will not be our main focus. Users who are >>using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After >>this final release, the security team will provide security update >>support through 2007. > > > Sounds like an ambitious schedule... All my FBSD servers > are at least up to 5.3; my laptop is happy at 5.4. I have > what I believe to be a rationalquestion. Why should I go > beyond v5.5? More to the point, why can't minor security > tweaks be maintained indefinitely for 5.5? What will > releases -6 and -7 offer that can;t reasonably be dropped > into -5? A "me too" here for 5-Stable. I have a test PC, that was running 5-Stable using an additional swapfile to extend swap space. Never any problems at all with 5. After upgrading to 6-stable, I got regular hang-ups of the system (endless loop?) when swapspace is used extensively. Never happened with 5. I wild guess of mine is that there's problem with the 'enhanced filesystem access' in 6. I've reported this issue, and also provided backtraces of kernel dumps, although I'm not an expert in kernel debugging. However, no reponse so far. For me 6, as of now, is not yet as stable as 5 used to be. Regards, Rob. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Gary Kline wrote: Sounds like an ambitious schedule... All my FBSD servers are at least up to 5.3; my laptop is happy at 5.4. I have what I believe to be a rationalquestion. Why should I go beyond v5.5? There is one school of thought that says you shouldn't. If it works for you, there is no real need to upgrade. More to the point, why can't minor security tweaks be maintained indefinitely for 5.5? We don't support any branch of FreeBSD indefinitely. What will releases -6 and -7 offer that can;t reasonably be dropped into -5? New features that require protocol/ABI changes, etc. for one. For example, I'm working on adding ports/local rc.d scripts to the overall rcorder, and that change won't go back into RELENG_5 because it constitutes a major paradigm shift, and we don't mess with -stable branches in that way. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Gary Kline <[EMAIL PROTECTED]> wrote: > Sounds like an ambitious schedule... All my FBSD servers > are at least up to 5.3; my laptop is happy at 5.4. I have > what I believe to be a rationalquestion. Why should I go > beyond v5.5? Because 6 better, faster, more colorful and more fun. :-) But seriously ... I'm running all my machines at home on RELENG_6 (6-stable by now) for half a year already, especially including my notebook. A lot of things that didn't work with 5.x or required a lot of fiddling now "just run" out of the box with FreeBSD 6, and it also feels a bit faster. Also, power-saving works better, so my notebook runs longer on battery. Stability is the same or even better -- I haven't had a single panic in those six months for which I've been using RELENG_6 (except a few panics upon shutdown, but after syncing the disks so it didn't hurt anything; I guess it's an ACPI issue with that particular mainboard, because it happens only on one of the machines). The upgrade from 5.x to 6.x is completely painless and no more risky or difficult than from 5.3 to 5.4. I've seen reports of a few people who had problems with 6.0, but personally I didn't have any, and I wouldn't want to go back. In fact I can't think of a single reason why I wouldn't upgrade a FreeBSD machine to 6.x. YMMV. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
Gary Kline wrote: On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: All, The following is the approximate schedule for FreeBSD releases in 2006: Jan 30: Freeze RELENG_5 and RELENG_6 Mar 20: Release FreeBSD 6.1 Apr 3: Release FreeBSD 5.5 Jun 12: Freeze RELENG_6 Jul 31: Release FreeBSD 6.2 Oct 23: Freeze RELENG_6 Dec 11: Release FreeBSD 6.3 A 'freeze' means that the tree will be closed to changes except with specific approval, and the focus will be on producing, testing, and fixing release candidates. The release dates are targets that we hope to make, but we will continue with the policy of only releasing once all of the showstoppers are cleared, i.e. we will release when it is ready. FreeBSD 5 5.5 will be the final release from the RELENG_5 tree. We are doing it to provide support for users who have committed to FreeBSD 5 and who need more time to transition to FreeBSD 6. However, in order to keep forward progress with FreeBSD 6, we will produce this in parallel with the 6.1 release, and thus it will not be our main focus. Users who are using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After this final release, the security team will provide security update support through 2007. Sounds like an ambitious schedule... All my FBSD servers are at least up to 5.3; my laptop is happy at 5.4. I have what I believe to be a rationalquestion. Why should I go beyond v5.5? More to the point, why can't minor security tweaks be maintained indefinitely for 5.5? Security updates will be maintained for quite a while. However, it takes manpower to test each proposed security change, so it's very hard to justify doing them 'indefinitely'. The stated policy from the security team is 2 years. So they will probably support 5.5 into 2008, but I wanted to be conservative in my statement in case they have different plans. What will releases -6 and -7 offer that can;t reasonably be dropped into -5? Significant performance and stability enhancements that simply cannot be broken up and backported to FreeBSD 5. We are marching towards a 'Giant-less' kernel, which means continuing better SMP performance and better UP responsiveness. With 6.0 we are finally starting to see the benefit of the SMPng work that we've been doing for 5 years. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > All, > > The following is the approximate schedule for FreeBSD releases in 2006: > > Jan 30: Freeze RELENG_5 and RELENG_6 > Mar 20: Release FreeBSD 6.1 > Apr 3: Release FreeBSD 5.5 > Jun 12: Freeze RELENG_6 > Jul 31: Release FreeBSD 6.2 > Oct 23: Freeze RELENG_6 > Dec 11: Release FreeBSD 6.3 > > A 'freeze' means that the tree will be closed to changes except with > specific approval, and the focus will be on producing, testing, and > fixing release candidates. The release dates are targets that we hope > to make, but we will continue with the policy of only releasing once > all of the showstoppers are cleared, i.e. we will release when it is > ready. > > FreeBSD 5 > 5.5 will be the final release from the RELENG_5 tree. We are doing it > to provide support for users who have committed to FreeBSD 5 and who > need more time to transition to FreeBSD 6. However, in order to keep > forward progress with FreeBSD 6, we will produce this in parallel with > the 6.1 release, and thus it will not be our main focus. Users who are > using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After > this final release, the security team will provide security update > support through 2007. Sounds like an ambitious schedule... All my FBSD servers are at least up to 5.3; my laptop is happy at 5.4. I have what I believe to be a rationalquestion. Why should I go beyond v5.5? More to the point, why can't minor security tweaks be maintained indefinitely for 5.5? What will releases -6 and -7 offer that can;t reasonably be dropped into -5? gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
