upgrading xorg?

[Database Administrator]

On Sat, 16 Jun 2007 13:31:13 +0200
Angel wrote:

> Hello,
>
> I am trying to find out what the minimum necessary partition size are
> for /usr and /usr/ports. I really want to separate the operating
> system from everything else (included Xorg) on different partitions.

Uh, why would you want to do that?

> At this moment I have the following partitions on a 6.2-RELEASE box:
>
> $ df -h
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ad0s1a 124M 39M 75M 34% /
> devfs 1.0K 1.0K 0B 100% /dev
> /dev/ad0s1d 124M 20M 94M 17% /var
> /dev/ad0s1e 989M 700M 210M 77% /usr
> /dev/ad0s1f 989M 843M 67M 93% /usr/local
> /dev/ad0s1g 1.6G 437M 1.0G 29% /home

Mine....
Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s1a 496M 56M 400M 12% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad4s1e 496M 22K 456M 0% /tmp
/dev/ad4s1f 140G 5.4G 124G 4% /usr
/dev/ad4s1d 1.6G 95M 1.4G 6% /var




> Xorg seems to be under /usr/X11R6:
>
> # du -h -d 1 /usr
> 2,0K ./.snap
> 24M ./bin
> 14M ./include
> 19M ./lib
> 92K ./libdata
> 15M ./libexec
> 843M ./local
> 13M ./sbin
> 221M ./share
> 2,0K ./src
> 162M ./X11R6
> 127M ./compat
> 2,0K ./games
> 2,0K ./obj
> 105M ./ports
> 1,5G .



$ du -h -d 1 /usr
2.0K /usr/.snap
28M /usr/bin
14M /usr/include
49M /usr/lib
92K /usr/libdata
19M /usr/libexec
1.0G /usr/local
14M /usr/sbin
250M /usr/share
434M /usr/src
440M /usr/ports
135M /usr/compat
2.0K /usr/games
2.0K /usr/obj

> Timmy wrote:
>
> > 2...Start the install. WHAT YOU WANT IS A MINIMAL INSTALL with no
> > xorg
>
> > 4....Reboot: login as your wheel user - su root and run portsnap
> > fetch update, after that's done run portsnap extract (It will tell
> > you) Now that you have an updated ports tree run pkg_add -r
> > xorg----------I'm on a cable modem and withing 15/20 minutes xorg
> > 7.2 was installed with no problems. Now that you have a working
> > FBSD-system with xorg-7.2 you need to install what ever ports you
> > use.
>
> Will this procedure install Xorg under /usr or already
> under /usr/local?

pkg_add -r xorg will install under /user/local

> What I would like is to substantially reduce /usr size. Will 512MB be
> alright? Assuming I take /usr/ports from /usr partition to either its
> own partition or somewhere else (sym-linking it from /usr/ports). Are
> there any other directories under /usr which contain ports 'parts' or
> something which is not part of the base operating system? What about
> /usr/obj? /usr/src? etc?

/usr/obj/ usr/src/ are all part of the base system that gets installed
be default/Minimal install, with pkg_add -r xorg you don't have to
worry about any sym-linking..


>

[Database Administrator]

On Sat, 16 Jun 2007 07:26:11 +0000 (UTC), Michel Talon wrote:
: Timmy wrote:
: > fluxbox up and running but its worth it in the long run. Needless to
: > say, it freaking flies.
: >
:
: Bull****, it doesn't make a difference.

OpenOffice is noticably snappier on a box when compiled with
CPUTYPE?=pentium4 in /etc/make.conf and the other optimizations at
their default, on my box anyway, and with everything else built the
with the default optimizations other than cputype?. YMMV

: moon. Compiling ones programs from source is only an excellent way to loose
: ones time and risk that something goes astray.

On the other hand, compiling from up to date ports insures that one's
ports have the latest security fixes generally available to the
freebsd community, as well as any new features. . The risk of things
going astray for short periods of time doesn't seem to outweigh these
two benefits.

As for time, why not do your recursive configs and fetches before
going to bed and let the thing churn away in unattended mode while
you're sleeping?

[Database Administrator]

Timmy wrote:
> On Sat, 16 Jun 2007 07:26:11 +0000 (UTC)
> talon@lpthe.jussieu.fr (Michel Talon) wrote:
>
> > Timmy wrote:
> > > fluxbox up and running but its worth it in the long run. Needless to
> > > say, it freaking flies.
> > >
> >
> > Bull****, it doesn't make a difference.
>
> Sure it does.

Only in your imagination.

>
> > Operating system programs are mostly IO bound and optimisation is
> > totally useless on them. Even on compute bound programs there are
> > many cases where high optimisation levels have negative effects.
>
> Care to back that up with a few benchmarks?
>

I have done enough computations to see repeatedly some computations run
slower when compiled with -O3 than with -O. And on a given computation,
it always take a lot of time to discover the correct configuration of
compilation flags which give good results. This even depends on the size
of the computation, because as soon as you get out of the L1 cache,
computation speed takes a big hit, and such tricks as loop unrolling
which have favorable effect on small computations can increase the
binary size to the point it doesn't fit in cache and produce disastrous
effects.

> >As
> > for architecture specific flags they give positive effects once in a
> > blue moon. Compiling ones programs from source is only an excellent
> > way to loose ones time and risk that something goes astray.
>
> Build a Gentoo system from a stage-1-tarball using -O3 opt
> and then install the same release using the Live-Cd
> installer and then come back and talk to us about what system runs
> faster on the same hardware.
>

Only in your imagination, you desperately want to see the hardware
running faster because you have spent days compiling crap, but, of
course this doesn't make a microsecond difference on the speed of the
hard disk, the memory to processor bandwith and so on, which are the
only factors of any importance. In FreeBSD the main operations which
can affect OS speed (such as bzeroing memory) are already programmed in
assembler, so optimization will be of zero effect. I am quite sure it is
the same for Linux.

> As for FBSD, mixing source and packages seems like a bad idea. Pkg_add
> -r this, and you get a bunch of warnings that this should be updated or
> that packaged is outdated etc... If you run a light system building
> from source is not a problem, fluxbox for desk, mail: postfix, Mutt,
> fetchmail, procmail and spamassassin will handle all of your mail needs,
> next firefox/opera handles all of your browsing needs, multimedia,
> xine, mplayer and xmms. If all my programs were outdated I could run
> portmaster -a and it would take less than an hour to build everything
> from source..
>

Because you are running crap software in the hope of running "faster"
when i run KDE and similar which will take days to compile. By the way,
i trade any day what i perceive as convenience against what i perceive
as speeed and which is only the computer's business, not mine.
Moreover i have hundreds of ports installed, of the order of 700 before
modularization of Xorg, hence more than a thousand after, so
running portmaster -a would take me a week. Sorry but i have other
things to do with my computer.


>

--

Michel TALON

[Database Administrator]

I absolutely agree. The upgrade really works, but takes some time.

I followed the instructions in /usr/ports/UPDATING to the letter and my
laptop runs as a charm.
Your ports collection needs to be up to date!! As is stated.
To make it happen a little bit faster I ran portupgrade -aP.

S.

Torfinn Ingolfsen wrote:
> Huub wrote:
>> gnome and everything else. And now you are telling me that it'd be
>> some kind of a miracle if xorg7.2 would build fine? In that case I'd
>> better leave this 6.2 system until 7.0 is official and not waste my
>> time any longer on upgrades that will go wrong anyway.
>
> Please stop with this nonsense.
> Ok, the xorg 7.2 upgrade is a big one, and it takes time, but it works,
> if you follow the instructions in /usr/ports/UPDATING,
> and is a bit persistent.
> If some ports fail under the upgrade, simply do a 'portupgrade -R
> ' for each one of those until you are through.
>
> Then do the mergebase step, andd you are back to normal again.
> (One caveat, for the time being, you will need "XORG_UPGRADE=yes" in
> your environment whenever you want to upgrade an xorg port)
> I have done the xorg 7.2 upgrade on two of my machines now (one i386,
> one amd64 - both running 6.2-stable), without problems.
> HTH

[Database Administrator]

Torfinn Ingolfsen wrote:

> Please stop with this nonsense.
> Ok, the xorg 7.2 upgrade is a big one, and it takes time, but it works,
> if you follow the instructions in /usr/ports/UPDATING,

No. It is completely unacceptable.

In the past the ports system did not force you to upgrade
your X to the latest bleeding edge version whenever you
touched anything. The one you had usually did just fine.

This "just do it" approach might be ok for a home machine,
but people are acutally using FreeBSD in commercial environments.

I just had the misfortune to having to install 7 test servers,
based on installationm scripts. If you actually think I have
time to babysit that ludicrous xorg7 installation process
on each of these machines you are sadly mistaken.

Result for now is I told the folks who use the machines they
would have to do without vim or emacs - joe or vi is all
there is. Same goes for cvsup, mozilla, and piles of other
applications I'd like to just have there.

But this is ridiculous. The careless and sloppy way the
xorg 7 upgrade was allowed to lay waste to the ports tree
is an embarassment and an eminent exercise in hobbyist
computing.

Regards

Christoph Weber-Fahr

[Database Administrator]

Christoph Weber-Fahr wrote:
> Torfinn Ingolfsen wrote:
>
> > Please stop with this nonsense.
> > Ok, the xorg 7.2 upgrade is a big one, and it takes time, but it works,
> > if you follow the instructions in /usr/ports/UPDATING,
>
> No. It is completely unacceptable.
>
> In the past the ports system did not force you to upgrade
> your X to the latest bleeding edge version whenever you
> touched anything. The one you had usually did just fine.
>
> This "just do it" approach might be ok for a home machine,
> but people are acutally using FreeBSD in commercial environments.
>
> I just had the misfortune to having to install 7 test servers,
> based on installationm scripts. If you actually think I have
> time to babysit that ludicrous xorg7 installation process
> on each of these machines you are sadly mistaken.
>
> Result for now is I told the folks who use the machines they
> would have to do without vim or emacs - joe or vi is all
> there is. Same goes for cvsup, mozilla, and piles of other
> applications I'd like to just have there.
>
> But this is ridiculous. The careless and sloppy way the
> xorg 7 upgrade was allowed to lay waste to the ports tree
> is an embarassment and an eminent exercise in hobbyist
> computing.

None of these problems would have happened if you had erased all
installed ports and reinstalled using precompiled packages. Contrary to
all the bull**** about portupgrade and other tools which are totally
unreliable, this is the only reliable and fast way to upgrade a
machine. I know only one system were upgrading in place works
relatively well, it is Debian. And the reason is that they use *binary
packages* and fully test them for the "stable" version.
There is no way whatsoever that a system based on compiling ports from
source be reliable. There will always be some combination of options
such that some port doesn't build and in turn blocks building
dependants. There will always be some junky who thinks that blindly
using -O3 will speed up his machine, and will only hit a compiler bug on
some library which will in turn produce misfunctions impossible to
understand in apparently unrelated places.

As for requiring an upgrade to "latest bleeding edge" X, this is a
feature of FreeBSD and has always been, ports are not branched.
Contrary to Debian, FreeBSD doesn't have the manpower to maintain both a
so-called "stable" version of ports, and an "unstable" one. You have to
live at the edge. But they do a good job to ensure that the current
ports version is indeed working. In particular the change to modular
Xorg has been an enormous work, and you can admire that they have done
it in a short amount of time, and with very few bugs. In my opinion this
is a remarkable achievement, and i much prefer to live on the edge with
FreeBSD than to lag several years with Debian. However for use in a
commercial situation in which you want only security bugs correction
and a minimum of fuss, it is clear that Debian stable is superior.




--

Michel TALON

[Database Administrator]

On 2007-06-21, Michel Talon wrote:
> Christoph Weber-Fahr wrote:
>> Torfinn Ingolfsen wrote:
>>
>> > Please stop with this nonsense.
>> > Ok, the xorg 7.2 upgrade is a big one, and it takes time, but it works,
>> > if you follow the instructions in /usr/ports/UPDATING,
>>
>> No. It is completely unacceptable.
>>
>> In the past the ports system did not force you to upgrade
>> your X to the latest bleeding edge version whenever you
>> touched anything. The one you had usually did just fine.
>>
>> This "just do it" approach might be ok for a home machine,
>> but people are acutally using FreeBSD in commercial environments.
>>
>> I just had the misfortune to having to install 7 test servers,
>> based on installationm scripts. If you actually think I have
>> time to babysit that ludicrous xorg7 installation process
>> on each of these machines you are sadly mistaken.
>>
>> Result for now is I told the folks who use the machines they
>> would have to do without vim or emacs - joe or vi is all
>> there is. Same goes for cvsup, mozilla, and piles of other
>> applications I'd like to just have there.
>>
>> But this is ridiculous. The careless and sloppy way the
>> xorg 7 upgrade was allowed to lay waste to the ports tree
>> is an embarassment and an eminent exercise in hobbyist
>> computing.
>
> None of these problems would have happened if you had erased all
> installed ports and reinstalled using precompiled packages. Contrary to
> all the bull**** about portupgrade and other tools which are totally
> unreliable, this is the only reliable and fast way to upgrade a
> machine. I know only one system were upgrading in place works
> relatively well, it is Debian. And the reason is that they use *binary
> packages* and fully test them for the "stable" version.
> There is no way whatsoever that a system based on compiling ports from
> source be reliable. There will always be some combination of options
> such that some port doesn't build and in turn blocks building
> dependants. There will always be some junky who thinks that blindly
> using -O3 will speed up his machine, and will only hit a compiler bug on
> some library which will in turn produce misfunctions impossible to
> understand in apparently unrelated places.
>
> As for requiring an upgrade to "latest bleeding edge" X, this is a
> feature of FreeBSD and has always been, ports are not branched.
> Contrary to Debian, FreeBSD doesn't have the manpower to maintain both a
> so-called "stable" version of ports, and an "unstable" one. You have to
> live at the edge. But they do a good job to ensure that the current
> ports version is indeed working. In particular the change to modular
> Xorg has been an enormous work, and you can admire that they have done
> it in a short amount of time, and with very few bugs. In my opinion this
> is a remarkable achievement, and i much prefer to live on the edge with
> FreeBSD than to lag several years with Debian. However for use in a
> commercial situation in which you want only security bugs correction
> and a minimum of fuss, it is clear that Debian stable is superior.
>
>
>
>

Michel:

Prior to switching to FreeBSD, I ran Debian. As occurs now, I often could
not "get around" to running an update. I found that with Debian, if you did
not update regularly you would eventually reach a point where an upgrade
would trash the system and make it unuseable. The only choice then was
re-install. I've never had such an issue with FreeBSD. The upgrade process
is indeed long for xorg, but as I understand it, one can run portupgrade in
such a manner as to create packages without installing anything. I would
suggest this is a better option for machines with high availability
requirements.

The upgrade process with FreeBSD has yet to make large numbers of programs
stop working, such as occured with service pack 2 for XP.

So I guess I'm saying I have to disagree. The FreeBSD upgrade process is, in
my experience, the most stable I've had to use.

Cheers.

JE

[Database Administrator]

On Thu, 21 Jun 2007 04:31:43 -0500, JE wrote:

> Prior to switching to FreeBSD, I ran Debian. As occurs now, I often could
> not "get around" to running an update. I found that with Debian, if you did
> not update regularly you would eventually reach a point where an upgrade
> would trash the system and make it unuseable.

At the risk of going OT, Michel was talking about Debian *STABLE*. There
are no upgrades to Debian stable. Updates are fixes only. Upgrades to
stable are entirely at your own risk.

The situation you describe is quite possible (even usual) when running Sid,
but that doesn't come with any guarantees. And even then, Aptitude helps
you assess the likelihood of trashing your system by pressing the "g" key :-)

The nearest to Debian stable equivalent in FreeBSD would appear to be
running x.y RELEASE.

[Database Administrator]

JE wrote:
> Michel:
>
> Prior to switching to FreeBSD, I ran Debian. As occurs now, I often could
> not "get around" to running an update. I found that with Debian, if you did
> not update regularly you would eventually reach a point where an upgrade
> would trash the system and make it unuseable.

With Debian stable? Never seen that myself. I have been told this is
very common with Gentoo.


> The only choice then was
> re-install. I've never had such an issue with FreeBSD. The upgrade process
> is indeed long for xorg, but as I understand it, one can run portupgrade in
> such a manner as to create packages without installing anything.

Yes, the idea is to create a jail, and build all the packages in the
jail. This way you can then upgrade the main installation with binary
packages that you can be sure exist and work. This is useful if you want
to compile your packages with special options. Otherwise, using the
binaries from freebsd.org is equally good.

>
> The upgrade process with FreeBSD has yet to make large numbers of programs
> stop working, such as occured with service pack 2 for XP.

Well, you have only to upgrade gettext (this occurred not long ago) and
you will see a large number of ports which stop working ... Of course
portupgrade has the useful feature of saving old shared libraries so
that you don't see the effect of this bold move.

>
> So I guess I'm saying I have to disagree. The FreeBSD upgrade process is, in
> my experience, the most stable I've had to use.



--

Michel TALON

[Database Administrator]

Christoph Weber-Fahr writes:

> No. It is completely unacceptable.
>
> In the past the ports system did not force you to upgrade
> your X to the latest bleeding edge version whenever you
> touched anything. The one you had usually did just fine.

I have two ports trees on my system now: one normal one in
/usr/ports.new, and one in /usr/ports.old that I rolled back with
cvsup to the day before the xorg7.2 merge. I link /usr/ports to one
or the other as needed. It's not that I'm unwilling to do the upgrade
-- this is my desktop machine, so downtime isn't a big issue -- but
when I tried to upgrade a couple weeks before the merge, I had
problems with my old integrated NVidia GPU not being able to handle
the 3D stuff, causing X to crash when it loaded GLX.

It works fine under 6.9, and I only expect to use this machine for a
few more months anyway, so I figured I'd just wait until I replaced it
to go to 7.2. I was disappointed to find that I could no longer
install or upgrade *any* ports requiring X at all.

Didn't you used to be able to install X-dependent ports whether you
used Xorg or Xfree86? I was surprised something like that wasn't
done, or moving 6.9 to x11/xorg6.9, like is done with many other ports
that people don't all want the latest version of. I'm certainly not a
ports developer, though, so I have to assume that wasn't possible for
some reason.



--
Aaron -- aaron.baugher.biz

"Take what you need and leave the rest."