Best Linux distribution for a Mini-ITX server?

Here is an update:

I have been searching and have found that there is already a distribution specifically oriented to the Epia processor:

formatting link
This distribution is based on Gentoo, so it makes a lot of sense.

However by looking at the website it seems that it is still very green: the website only contains a forum but no "home" or "about" page, and after reading some of its posts I think that the distribution is still in beta phase.

Regards,

Luis.

Reply to
Luis
Loading thread data ...

Have you already bought your system? If you haven't why don't you get a AMD64 based system. With Cool & Quiet the cooling fan on the Athlon 64 hardly every runs, a Turion will run even cooler. If you get an A64 system you'll be able to run any distribution you want.

Reply to
General Schvantzkoph

Yabbut ... the postings will NOT be off-topic if the original posting was appropriately cross-posted. If the original poster posted to disparate groups in some of which his posting was off-topic he is hardly likely to have set a followup.

By all means set followups or (much better, IMHO) trim groups as and when the topic drifts. that's an entirely different matter.

Enough, already.

Cheers, Daniel.

Reply to
Daniel James

I've had a few.... adventures getting 64-bit versions of some applications, and been publishing notes back to the driver and software authors on how to get stuff to work under 64-bit for 18 months now. In general, they're pretty sweet and I can recommend them for high performance systems with very modest power demands.

Reply to
Nico Kadel-Garcia

You don't need to run a 64 bit distro on a A64 system, I run 32 bit FC(4 & 5) on two of my A64s and 64 bit FC4 on my X2 4400+.

Reply to
General Schvantzkoph

Well, true, and I've done that when I've been in a rush to get an app running on a 64-bit server and the app wasn't 64-bit compatible yet. (Subversion 1.3.0 comes to mind!) But why waste the money/resources on a

64-bit system and then not use it for 64-bit? It's kind of throwing away a lot of the power, and if you're doing anything computationally intensive using 64-bit apps can help lower your power requirements and runtimes.
Reply to
Nico Kadel-Garcia

It's not throwing away any power, the only reason to run 64 bits is if you need more that 4G of memory which isn't even possible on an Athlon 64 system because you can't buy an unbuffered DIMM bigger than 1G (2G registered DIMMs are available but those are for Opterons). 64 bit programs are frequently slower than the 32 bit versions. If the data set is primarily integer or pointers then there will be a significant slow down when you run in 64 bits because the memory bandwidth is effectively cut in half (think of the bandwidth in terms of integers/second as opposed to bytes/second and you'll see that this is obviously true). If a program is operating on floating point numbers then it can be faster in 64 bits then in 32 bits because the memory bandwidth for FP numbers is the same for 32 and 64 bit modes and the 64 bit mode has extra registers which will speed things up a little.

Reply to
General Schvantzkoph

Some of us are also attracted to the small footprint.

Reply to
ray

This is a misperception. The cheapest Sempron 64s are now similarly priced to the cheapest Celerons, and the motherboards for them are generally slightly cheaper.

So the price advantage is with 64-bit, and you have the choice of OS bytewidth.

--
mark south; echo znexfbhgu2000@lnubb.pb.hx|tr a-z n-za-m
"I can trace my ancestry back to a protoplasmal primordial atomic 
globule. Consequently, my family pride is something inconceivable."
-- Gilbert & Sullivan, The Mikado
Reply to
Mark South

Aren't FP numbers on X86 processors 80 bits, not 64 bits?

Reply to
me

The 64 Bit AMD architecture (that has been licensed by Intel for the new

64 bit chips has a completely different CPU structure in 64 Bit mode: a RISK-like large flat 64 bit register set. So a programmer or compiler can write code running much faster at the same clock that if using 32 Bit mode.

-Michael

Reply to
Michael Schnell

Excuse me: that's not what I meant. . I don't dispute that a 64-bit AMD CPU may match a 32-bit Intel CPU in speed and 32-bit performance. But why not enable the extra features, especially if you're doing graphics or floating point processing? More bits tends to really help graphical and number crunching performance, and if it's not too tough to get the operations converted to 64-bit, it can take a bit of work, but go for it!

Reply to
Nico Kadel-Garcia

Isn't it true that the native mode of all X86 coprocessors since the original 8087 has always been 80 bit, and that programs have to jump through hoops, see reduced performance, and suffer from less precision and/or range if they force the X86 to use 64-bit floats?

Reply to
me

Is it possible to run 64 Bit user programs in a 32 Bit OS ? (The OS needs to save the 64 bit registers when scheduling ...)

-Michael

Reply to
Michael Schnell

Nope. You absolutely need to install a 64-bit kernel and glibc.

Reply to
Nico Kadel-Garcia

Goodness what a dreadful site! You have to dig really deep to find out what Epios *is*.

From the look of it, Epios is just an attempt to bring together all the various drivers and patches that support the hardware used on EPIA mainboards. Note, though, that you don't need to be using Epios to get those drivers and patches (though it may be more convenient to do so) ... and you don't need the drivers and patches if you're not worried about some of the more advanced and hardware-specific features of the EPIA boards - sensors, MPEG acceleration, etc.

For running a headless Apache server you don't need those EPIA-specific drivers and patches, and a bog-standard install of any distro should be OK. I use a fairly standard Gentoo setup (compiled for C3_2 CPU) and it works very nicely.

Note, though, that the Epios kernel is built to run on any APIA mainboard, so the code is generated for an x586 target, which is sub-optimal for the Nehemiah processors on later EPIA boards, which are x686. Conversely, many "vanilla" distros are built for x686 and won't run on non-Nehemiah mainboards, so be sure to use a distro that does support the CPU type (should be a 386 or 586 build).

[Note also that the Nehemiah CPU, although it is a 686, does not support some "optional" 686 instructions (CMOV) that are used in code generated by some versions of gcc without any runtime checks for support (this is a now-fixed gcc bug).]

Cheers, Daniel.

Reply to
Daniel James

It's not a waste of money. A64 systems give much better 32-bit performance than most 32-bit Athlon systems and are only slightly (if at all) more costly -- and (almost conicidentally) offer an upgrade path to 64 bits should it ever be needed.

Why not use 64 bits anyway? Because the software you want to use may not yet exist in a reliable 64-bit form. Using a 64-bit system to run the

32-bit version gives you the flexibility to run with what works now, and to upgrade in the future.

OTOH, for a low-traffic Apache server the relatively modest and very low power consumption/low noise EPIA systems are ideal. A64 is definitely NOT essential for such an application (though it might help when building the system, if using Gentoo ... distcc is your friend).

Cheers, Daniel.

Reply to
Daniel James

I've been running a Shuttle with White Box Linux (free release of RHEL3.0) and have installed Fedora Core 3 and 4 on others. I am running some old slow Celeron, 2GHz as I recall, and it's fine for a DNS or web server unless you plan to run a lot of CGI. If you use FC4 and are on the open net, be sure to specify the best firewall when asked, and don't install anything you don't need. Use enough memory, and it should be fine.

As for Emule, you're on your own, rumor has it that's a CPU hog, if you must use it and want decent performance you may want to rethink the whole idea and go with a larger system.

--
bill davidsen
   SBC/Prodigy Yorktown Heights NY data center
   http://newsgroups.news.prodigy.com
Reply to
Bill Davidsen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.