Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
How stable is Gentoo Linux 64bit ?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64
View previous topic :: View next topic  
Author Message
d2_racing
Bodhisattva
Bodhisattva


Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada

PostPosted: Sun Jul 05, 2009 2:03 pm    Post subject: Reply with quote

Also, the ~arch is pretty active too, since a lot of dev and other are running with that arch.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6102
Location: Dallas area

PostPosted: Sun Jul 05, 2009 2:13 pm    Post subject: Reply with quote

I've not had any problems over the last year with my amd64 system

Stable as can be.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
regomodo
Guru
Guru


Joined: 25 Mar 2008
Posts: 445

PostPosted: Wed Jul 08, 2009 7:35 pm    Post subject: Reply with quote

I've had amd64 for about 1.5years. It's been almost stable except for Qt4 which has had some odd bugs that pop up and disappear every now and then.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2285
Location: Adendorf, Germany

PostPosted: Wed Jul 22, 2009 8:20 am    Post subject: Reply with quote

Mind, my machine at home has 4GB Ram and will be extended to 8GB next month. Even my parents have 4GB, so it might be a good idea to be careful about statements what "others" have at home.

On the other hand we have alot of DELL Servers at work with excessive database loads (some dbs have hundreds of GB sized tables) and are still using Debian-32bit with mysql 4.1.

However, people seem to keep forgetting that we do not have 2003 anymore. Staying excessively on x86 because "we don't need 64bit" is the same what many companies did with staying on old 16bit Windows 3.1(1) in the nineties.

just my 2 (euro) cents.

PS Running "almost only" stable amd64 on my company laptop since august 2008 and "alot unstable" amd64 on my home desktop since april 2009 (with flawlessly working nvidia-drivers, btw) and didn't have a single problem since now.

PPS For xorg try "nvidia-xconfig", it works pretty well for me.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
na641
Apprentice
Apprentice


Joined: 27 Jun 2002
Posts: 169
Location: Eugene, OR

PostPosted: Wed Jul 22, 2009 1:10 pm    Post subject: Reply with quote

have been using amd64 gentoo since it was introduced. it's very stable and even the long running desktop issues (flash/java/etc.) have been rectified. I personally run ~ simply because its not 'unstable' at all. in actuality, id call it 'stable' and standard amd64 as 'stagnant'. Original question, how stable? very.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Wed Jul 22, 2009 1:45 pm    Post subject: Reply with quote

Interesting sideline...

My main machine, which is a K8 which was running x86, is now getting the amd64 side reinstalled, replacing the old 2007 installation. The immediate impetus for this action was a stupid mistake on my part. I was reading another article on Slashdot about backup, which I'm not good enough at. I've been toying on and off with doing something about my /etc directories on my various machines, and not knowing the best thing has been the enemy of doing something at all. So I finally set up some rsync space on the raid-1 volume on my server, and built a structure giving each machine an rsync target for its /etc. I then grabbed the line that I use to keep the raid-1 space on my backup server synchronized with the main server, and used it to rsync my /etc to the backup space.

I had the command line backwards. Instead of syncing /etc up to the empty space on the server, I synced the empty space on the server down to /etc. It's dead, Jim.

A bit of searching online indicates that ext3 is a sonofagun to undelete. It can be done - there's a program called "ext3grep" in portage. In fact, after I realized what I had done, I "sync ; sync ; sync"ed and shut the power off to the machine. I have an odd partition setup, so that my root is nearly-entirely-write, and most read-write activity is on /var and /home, and a set of bind-mounts to make it that way. I have about as benign a situation for undelete of /etc as can exist. But that also needs a stable platform to start the undelete, and I didn't quickly find a LiveCD that I liked with ext3grep installed.

In this case, the simplest way to a stable platform is to redo the amd64 install. It's going pretty well so far. Mythtv just failed because of USE flag issues on dependent packages. I've tweaked /etc/portage/package.use, and find that "emerge -atuvDN world" shows quite a few changes because of the install of sqlite and mysql, so that's running now. (Currently at qt-3, to be precise.)

There's so little difference to me between a "stable platform" and a complete install that right now I'm simply going for the latter. It's mostly waiting for compilation, and right now it's compiling while I'm doing other things that need to be done. Besides, the secondary deskside machine is now up in the study. My daughter is home from college, and her machine had bumped the secondary machine from it's normal niche. So this is happening at about as benign a time as possible.

The big question left is, once the amd64 install is complete, how motivated will I be to recover the /etc on the x86 install? (I may wnat to try, just for the practice/learning.)
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2285
Location: Adendorf, Germany

PostPosted: Thu Jul 23, 2009 1:07 pm    Post subject: Reply with quote

na641 wrote:
I personally run ~ simply because its not 'unstable' at all. in actuality, id call it 'stable' and standard amd64 as 'stagnant'. Original question, how stable? very.
For me it wouldn't be possible, because when I switch to ~amd64 libdrm and xf86-video-intel my xorg-server randomly freezes. Bad thing for a working machine.... ;) Thus, of course, ~ actually is *unstable* for some packages in a few situations. And I have already witnessed ~arch packages becoming hard-masked after a while and later removed from the tree. (Note: I do not doubt for a second that ~arch is stable for you, na641, but it can't be guaranteed for every user and every setting.)
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
keet
Guru
Guru


Joined: 09 Sep 2008
Posts: 571

PostPosted: Fri Jul 24, 2009 2:14 pm    Post subject: I've never compared... Reply with quote

Evincar wrote:
Phoronix begs to differ about 64-bit not bringing improvements.[/url] To be honest, I don't trust Phoronix a lot, but they do seem to have done some serious benchmarks. On Ubuntu, though.


That is an interesting benchmark. What surprises me about it is that Ubuntu outperformed MacOS in any category at all -- not because I think that MacOS is inherently faster than Ubuntu, but because the test was performed on Apple hardware, for which MacOS was specifically designed, and for which Ubuntu was certainly not.

I've never compared any 32-bit O.S. against the same version of the 64-bit O.S. on the same hardware, except for Windows XP, and that was quite shortlived and never underwent benchmarking. From my experience, though, AMD64 Gentoo has been quite fast and stable for the ~1 year that it's lived on my P.C.
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1878
Location: Switzerland (Romandie)

PostPosted: Tue Jul 28, 2009 4:21 pm    Post subject: Reply with quote

About the speed difference between 32 and 64 bits, you will notice nothing in most cases on windows because they made the choice to use the LLP64 (long long pointer 64) coding model, when all other 64 bits OS are using LP64 (long pointer 64). LP64 implies that more data types can use the 64bits capability of the processor. Porting an application from 32 to 64 bits is harder with LP64, but it will benefit much more of the speed advantage of a 64 bits processor.

For now, I am using a phenom 9600 with 8 GB ram and Nvidia graphics. It is my first amd machine and I find it wonderful: both the speed and the stability are terrific. amd64 arch at the beginning, ~amd64 from a few months ago. /etc/portage/packages.keywords was becoming so big that it was much simpler to switch to ~amd64 anyway.

The stability is so good that I usually never stop the programs I am using the most. I stop them when I stop the machine.

Edit:
I know by personal experience than your CFLAGS will have a very big impact on the stability. It is why I use only safe CFLAGS:
Code:
CFLAGS="-march=amdfam10 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

_________________
"Confirm You are a robot." - the singularity
Back to top
View user's profile Send private message
XQYZ
Apprentice
Apprentice


Joined: 19 Jul 2009
Posts: 231
Location: Europe

PostPosted: Tue Jul 28, 2009 9:36 pm    Post subject: Reply with quote

Running ~amd64. It's rock solid as far as I can tell. The stable branch is ancient compared to it and there aren't too many issues with running the newest software.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Tue Jul 28, 2009 10:19 pm    Post subject: Reply with quote

Incidentally, my former 32-bit (formerly 64-bit before that) main system is back as 64-bit. It's still got a few rough edges - primarily a few problems with CUPS/hplip. But other than that, it's been rock solid.

Much more important, my wife has been happy with it. Firefox works raliably with her highly-favored Glowy-Green theme, and flash stuff like YouTube, Daily Show, etc all work.

I don't know how hard I'm going to try to recover the 32-bit install, at this point. Right now I'm more likely to scavenge the space.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Cyker
Veteran
Veteran


Joined: 15 Jun 2006
Posts: 1746

PostPosted: Wed Jul 29, 2009 4:17 pm    Post subject: Reply with quote

TBH, the speed difference between 64 and 32-bit is very small (And can go both ways!) EXCEPT when dealing with data-types larger than 32-bit or really really big data sets (Like giant databases!)

You'd get a bigger speed increase by buying a faster CPU or maybe even tweaking CFLAGS than going from 32 to 64 for the majority of applications.

The Phoronix benchmark seems to show this (Speed differences not that much different except with specific apps which match the above criteria), although I am slightly suspicious of the test as the 64-bit Ubuntu was SLOWER than the 32-bit one for the GnuPG test; Our own tests with OpenSSL show a near-3x speedup for 64-bit compared to 32-bit (Which seems in-line with their tests), and since GnuPG is also a crypto program that deals with large numbers I'd have expected it to demolish the 32-bit version in a similar fashion.
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Wed Jul 29, 2009 5:39 pm    Post subject: Reply with quote

depontius wrote:
Incidentally, my former 32-bit (formerly 64-bit before that) main system is back as 64-bit. It's still got a few rough edges - primarily a few problems with CUPS/hplip. But other than that, it's been rock solid.
What kind of problems are you facing with cups? I want to know because cups is behaving rather strangely for the last couple of days.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1878
Location: Switzerland (Romandie)

PostPosted: Wed Jul 29, 2009 6:16 pm    Post subject: Reply with quote

Cyker wrote:
You'd get a bigger speed increase by buying a faster CPU or maybe even tweaking CFLAGS than going from 32 to 64 for the majority of applications.


Profiling each single application is a must if you want to modify the CFLAGS because only a few of them are know to be sure in any situation for a given arch. I don't know anybody that have the time to seriously do that.

Profiling each single apps is a must because the behavior of the different CFLAGS will vary according to the context (code being compiled, architecture, processor type, and even compiler version).

In consequence, it is much simpler to use the few CFLAGS know to be sure.

For a developper, it can do profiling for his application, but even here, he must be very careful because the impact of those flags on the correctness of the resulting code can vary from a machine to another machine.

The USE of non safe CFLAGS in /etc/make.conf can ruin an installation with time, because you can get very subtle bugs. They can get almost unnoticed until the day your system, during an emerge world, completely stop to collaborate: your toolchain and the base system get corrupted. And that, for a very marginal speed gain before the final crash.

Now, a specific application can benefit of the use of a given CFLAGS combination. This is part of the job of its developers to make such adjustments. If you want to try to get more speed than that, you must do profiling in order to be sure of the correctness of the compiled software. In most cases and with modern compilers, the possible spped gain will be very marginal, the compilation time will much greater, and the profiling process will take a lot of time with a lot of successive compilations and testing.

Memory is also important for both speed and stability. gcc can eat a lot of RAM with programs like oofice or hugin, firefox too. Ideally, your system should almost never swap.

And of course, the biggest speed gain is always to buy a new machine. And even here, it depend on what you are calling speed. Into a normally charged gentoo system and the same kernel preemption, the responsiveness of the system will not be so different. But with a multicore 64 bits processor, some fast hdds (at least one for the system and one for work) and a lot of RAM, you will be able to run a lot of different applications at the same time than running jackd without xrun, and you will still get the same outstanding system responsiveness from your gentoo.
_________________
"Confirm You are a robot." - the singularity
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Wed Jul 29, 2009 6:44 pm    Post subject: Reply with quote

ppurka wrote:
depontius wrote:
Incidentally, my former 32-bit (formerly 64-bit before that) main system is back as 64-bit. It's still got a few rough edges - primarily a few problems with CUPS/hplip. But other than that, it's been rock solid.
What kind of problems are you facing with cups? I want to know because cups is behaving rather strangely for the last couple of days.


Most visibly, the hp-systray applet is not starting correctly. (This is under xfce.) There is a minimal-width gap up in the systray, but the "HP" icon pops up in the center of the desktop, and I minimize it to the taskbar. (Systray apps aren't supposed to show in the taskbar, either.) Something also appears to be wacky about the way it's invoked, because in the console error log I get:
Code:
Usage: hp-systray [OPTIONS]

[OPTIONS]
  Force Qt3:          --qt3 (default)                                       
  Force Qt4:          --qt4                                                 
  Startup even if no  -x or --force-startup                                 
  hplip CUPS queues                                                         
  are present:                                                             
  Set the logging     -l<level> or --logging=<level>                       
  level:                                                                   
                      <level>: none, info*, error, warn, debug (*default)   
  Run in debug mode:  -g (same as option: -ldebug)                         
  This help           -h or --help

which is usually the type of thing that happens when the options are wrong or missing. There is more info that comes out of hp-check, but I can't get at that information here and now.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Wed Jul 29, 2009 8:54 pm    Post subject: Reply with quote

depontius wrote:
Most visibly, the hp-systray applet is not starting correctly. (This is under xfce.) There is a minimal-width gap up in the systray, but the "HP" icon pops up in the center of the desktop, and I minimize it to the taskbar. (Systray apps aren't supposed to show in the taskbar, either.) Something also appears to be wacky about the way it's invoked, because in the console error log I get:
Code:
Usage: hp-systray [OPTIONS]

[OPTIONS]
  Force Qt3:          --qt3 (default)                                       
  Force Qt4:          --qt4                                                 
  Startup even if no  -x or --force-startup                                 
  hplip CUPS queues                                                         
  are present:                                                             
  Set the logging     -l<level> or --logging=<level>                       
  level:                                                                   
                      <level>: none, info*, error, warn, debug (*default)   
  Run in debug mode:  -g (same as option: -ldebug)                         
  This help           -h or --help

which is usually the type of thing that happens when the options are wrong or missing. There is more info that comes out of hp-check, but I can't get at that information here and now.
Hmm... I am not having any problems with hplip per se. hp-systray does not start for me since I don't have local usb connected printers. I am using remote printers. However, hp-toolbox works just fine,- it provides a (pretty useless) systray too.

The problem I am having with cups is in printing. When I print my files, sometimes only one page gets printed. And sometimes it doesn't even get sent to the printer. I have tried acroread and gtklp to do the printing. This is a fairly recent development and my emerge history shows that I hadn't upgraded cups at all since 1 month ago (when I made this fresh amd64 system). The only upgrade I did was yesterday (to 1.3.10-r2) when I was troubleshooting this new cups problem. In fact my cupsd.conf is also unmodified.

I will leave it at this. If I go on with describing my cups problem, it will hijack this thread :twisted:
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Thu Jul 30, 2009 1:31 pm    Post subject: Reply with quote

ppurka wrote:
I will leave it at this. If I go on with describing my cups problem, it will hijack this thread :twisted:


Start your own. When I get some time, I plan to with my CUPS/hplip problems.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64 All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum