I'm planning to purchase a new box. This will be modern hardware. For example, an AM2 BE-2400 CPU, etc. The motherboard will provide on-board video (nVidia chip set) and LAN.

I've used old hardware for a long time. In other words, configuring Slackware with new hardware will be a new venture for me. I started a punch list that will help me methodically migrate from my old box, but I would appreciate comments regarding various issues I should consider.

Part of my reason for obtaining newer hardware is that I plan to install some virtual environments to run Windows. (I need Windows for my vocation and WINE is not an option.) I have toyed with qemu, but want to consider other options, such as VirtualBox. Regardless, I need to learn to network my virtual systems with my host Slackware system.

I suspect there are many topics I need to consider to fully appreciate and understand this project. I'm not looking for specific configuration details within this thread but links to and comments about various topics I should consider while migrating to modern hardware in order to improve my punch list.

Thanks.

There are some things for which I hate linux. One of them is the newest hardware support. You need to wait for particular kernel, but ... windows xp installs without problems. Why? Mystery. Some low capabilities standard used. Probably. It's better than not installing at all.

Second thing would be to check if your network card has support in linux. And I would recommend native one. When I started using linux, my network card wasn't supported in the kernel. I needed to get the driver from the web. How to do it when you don't have net?

Third thing would be to check alsa and kernel for broken hardware (semaphores, etc). I suspect video cards are broken as well, but I can't check it cause drivers are closed source. Bloody manufacturers (all of them) never release the details of their products, yet they require that if anyone wishes to poke their nose, they should pay 100$ or more for some standard spec. Wtf? I bought my hardware so I should know if it adheres to some even obscure standard. Not in these days.

I second that. Only way to know that your hardware will work with Linux is if you buy parts that WILL work with Linux. Sorry.

The only suggestion I can give is to do a lot of research, specifically if the following parts (chipset) of your computer work with linux:

• Processor
• Network Card
• Video Card
• Sound Card
• Keyboard/Mouse (Grrrr Logitech)

Thank TFSM for Google.

There shouldn't be any problems with the hard drive controller, unless it's non-standard. (Why did I even say that, that sounds so superfluous).

You mention virtualization.
Since you are buying a AM2 board the processor will support hardware virtualization.
The question remains will the BIOS/Mother board support it.
Dell in particular comes to mind some of thier BIOSs block hardware virtualization.
Don't get bit by the same bug I did
John

There are BIOS patches. Still those **** BIOSes are protected, so you need to crack their protection if you wish to modify/apply/unlock smth. I hate branded pcs a lot. What the right do they have to prohibit rebranding? If you're like me, I suggest you build it yourself and do not buy prebuilt one. If you are going to buy a laptop and wish to build it yourself, take a look if graphics card is soldered to the mb. Nvidia releases unsoldered graphic chips and according to one standard (don't remember it's name right now), they could be replaced. This do not fit some VARs, so they ask OEMs or solder those chips themselves. They would lose profit if people could upgrade lappies instead of buying new ones.


There aren't lots of Video cards to choose from. Most of them use ATI or NVIDIA gpus. No difference here.
I doubt you need external sound card unless you have perfect pitch or work as sound designer. Most integrated sound chips have 7.1 support.

If you care about open source, so take a look at open source hardware, linux/open bios. IMO, this is more important than open software so I don't know why GNU movement didn't have a brother or sister. Why? Because there wouldn't be open software if only windows programmers could access hardware specs/schemes.


For all the newbies who will read this post: no, neither of those companies which advertise some new cool computer, built it themselves. All these are manufactured in Taiwan, China, Malaysia by the local companies (e.g. Quanta, Compal).



PS I would give anything if I could build my computer from scratch, not just plug in some cards into PCI slots and connect the cables.

I agree with other posts here...I believe you can better customize the machine if you build it yourself. You will have to carefully check various motherboards for chipset support. I know that's what I did when I built a machine year and half back (with newest hardware then).

I actually selected a few motherboards and then did a detailed comparison so I don't have to end up struggling with obscure drivers.

Best bet is to go with NVIDIA/Intel on-board video and NVIDIA (nforce)/Realtek onboard lan chipset. On-board sound should be fine but look into it as well when you decide. I have no experience with ATI so can't say much about it.

I recently built a new gaming rig (very powerful and very new) and it works nearly perfectly with Linux. Only problem was I needed a newer kernel for better support of the network card, the older kernel (the one that comes with Slack 12.0) had experimental version of the same driver, which stopped working for no reason at times. With the newer kernel it works great. I think new kernels are released quickly enough that you don't need to worry too much about hardware support (with a few exceptions). Search the net for your hardware and you may find more answers as to whether it will work well or not.

Thanks much for the initial feedback.

Some additional details:

The motherboard I selected is the Asus M2NPV-VM. One of my criteria for a motherboard was something modern but was not bleeding or cutting edge in order to ensure GNU/Linux support. More importantly, I have yet to read about GNU/Linux incompatibility issues with this board (ignoring initial reports during the period when the board first was introduced and the kernel and BIOS had not yet been updated). The board uses the nVidia GeForce 6150 and nForce 430 chips, ADI AD1986A audio chip, and Marvell PHY network chip. There is sufficient USB, SATA, IDE, and Firewire support. I'm not into games, high-end graphics, MP3s, overclocking, or bleeding edge, so this board is more than satisfactory.

The box will be custom built, not pre-ordered through any computer house.

I added ALSA testing to my punch list, as well as learning about udev. I never used udev because my old boxes were static and I did not use USB or SATA. I also need to learn how to test ACPI because with my old boxes I always used APM.

I routinely recompile the kernel for my old boxes, so that will not be completely new territory to me, although I will have to learn the tweaks for the new hardware. I suppose I'll start from scratch with the huge kernel and tweak from there. That includes configuring lmsensors too.

I also need to learn how to install the nVidia binary drivers. Although I'm not into high-end graphics or games, I would like basic 3D support. I don't think the generic nv or vesa drivers provide that, although those drivers would suffice during the initial break-in period.

Yes, I too have wondered about this. Also, how do various distro developers compile their kernels such that they install on most motherboards? Do they run a hardware detection script during setup to create a subsequent modules list?

I do not know whether the latest Asus BIOS version for this board disables virtualization support, but I never have read anything along that line.

Any additional thoughts are appreciated!

If you buy directly from OEM or through its representative, then it wouldn't be disabled (most often). AFAIK, nv & ati acceleration works for basic stuff. Depending on ACPI version, it can be almost working or partially broken. Udev is smth similar to previously used devfs, except that in devfs all possible device nodes are created at start, while udev created those nodes only when it finds the device (might be wrong though). Overclocking is not something mysterious. Either bios lets you change timings and voltages, or not.

I have a board with that exact graphics chipset and I use to for my mythtv box. I've had no problems using the nvidia binary drivers directly from Nvidia. nForce and Marvell PHY will work as well since there are drivers for this in kernel. Google for sound chip...I believe it is supported by alsa.

For udev, visit http://reactivated.net/writing_udev_rules.html
For ACPI, first google hit was http://www.columbia.edu/~ariel/acpi/acpi_howto.txt


configuring lmsensors is pretty easy. Here's how I approach it, I check in all sensors drivers in the kernel as modules then run sensors-detect (included in lmsensors package) and it will probe any sensors you have on board and will give you the modules you need to load. You can then include those in rc.modules. You also need i2c inbuilt or as modules in the kernel.

installing nVidia binary drivers is also very easy...
1. compile a new kernel and boot into it.
2. get the newest driver and read the docs to configure...the newest one is at http://www.nvidia.com/object/linux_d...32_169.07.html
3. install the driver and kernel module...the installer also does xorg.conf update if you allow it. You can try that or update it by hand.

Hi,

M$ has a lock with most manufactures. Sure that has loosened up but a lot of the manufactures have contracts with companies that must bow to M$. The equipment compatibilities and specifications are freely exchanged between each when speaking with M$. In fact if you look into some of the specifications for any PC or computer subsystem the specs are generally made to meet M$ requirements. Just look at this M$ link for 'Windows Hardware Developer Central'.

You can go further into the M$ Developers mindset if you desire but I've done my share and don't want to work that hard any more.

If you have a good library set then that will generally assist you when you need one. The other point would be to select hardware that is not bastard or orphaned. Since the kernel is now modular we really don't get into that situation any longer.

You could also use ndiswrapper along with the M$ drivers until you get the 'native' or module for the device. Most modern distributions do include ndiswrapper. And if the user is moving from M$ on their machine then they should have the network device driver.

I assume your speaking in the terms with new hardware that may cause a problem with a current kernel with backwards compatibility in the same family. If your uncertain about a particular processor family, if that family is able to run i86 code then it will most likely run the current kernel(s). The AM2 will run the i86 code. You won't be using all the cores but it would run.

I disagree with your blanket statement about manufactures not releasing details of their products. The Linux community has gotten a lot of information from a lot of manufactures. Mostly because of the way things were getting reversed engineered anyway. I've been able to get information about most of the hardware that I would have questions about. A little digging but most times I would find the desired information when the proper contacts are approached.

As for someone in the consumer market to request information from a manufacture that may present some problems. The industry is very competitive and a lot of engineers won't release their secrets. Non-disclosure agreements are a must now by most companies. That includes circuit information, BIOS, software or whatever. Most companies don't wish to share the information because it will violate agreements unknown to the requester.

Just because you purchased the hardware doesn't mean you should have information for that device. Have ever read the 'EULA' for a M$ product? Or the purchase agreement of the hardware you purchased? I believe in a open society but there are things that will not be shared.

I was talking not about x86 compatibility but about broken firmware -> consequently broken hardware (e.g. buggy BIOS) Some drivers in Windows fix (go around) the flaws, which can be seen when you need that driver in Linux. Then you need kernel patches, different modprobe options for the same model chipset (I noticed this in Alsa), maybe some other tricks.


Not all proprietary interfaces of photo cameras , mobile phones, printers, scanners (!!!) were reversed and even less released by the manufacturer. Another point is that a lot of interfaces are unavailable for independent developer for free. Example: http://www.pcisig.com/specifications/order_form If I'm not wrong even VESA is not free.


There is a difference between a patent and a trade secret. If companies used patents, there would be no problems. You could read the patent any time but you couldn't use it for 20 years (if I'm not mistaken) or you could buy a license. But now there is this... a trade secret. Not only it tries to prohibit RE with EULA crap, which can legally be circumvented with purpose of Interoperability (maybe the USA laws have already prohibited this, I don't know).

And Microsoft was punished in both the USA and the EU (and will be punished again - at least I hope so unless it manages to lobby greedy politicians again).

From http://www.kernel.org/pub/linux/docs/lkml/#s2-5:
and
With everything you told before, don't you think that we would be going in a closed circle. No documentatiom = no new product = no new product documentation. And this is what hampers the development.

Mmmm - I don't run AMD hardware, so take this for what it's worth.
I recently built a Q6600, and the only problem I had was jmicron. Ubuntu and Arch fired up fine - presumably Slack would have been a problem as I needed a recent kernel. No big deal for me as I tend to run -RC kernels for testing.
Got a Dell m1330 laptop a week ago - everything just worked.

The (Linux) devs do a truckload of work to get the latest-and-greatest hardware support available. Unless you buy it "day-one" you're probably not going to have a problem finding something that will support it. Might not be Slack, but you can get the box flying.

Hi,

That's part of the inter-operational agreement with M$ that most manufactures have with M$. The available information to M$ allows a certain edge for them with known BISO, Firmware or hardware for that matter.

That's the word 'proprietary' to be aware of. You can always get hardware of equivalent or better specs if you just dig a little. As for the manufacture release of information, they are getting a lot better since some larger companies are supporting or using GNU/Linux; IBM comes to mind. If IBM had not been open with the original IBM/PC we wouldn't have half the problems we have today. Don't get me wrong here but the buss and interface standards were specified by the engineers at IBM for the original PC to the IEEE.

As for your pointing out the difference in patent and trade secrets. I wouldn't want my interfaces in the patent office for just anyone to see. I won't pay the fees to allow that. Just a ego trip for a lot of people. Protection? Not really, by the time you spend the money and effort to recover from the harm of the infringement you will be broke or dead. Possibly both. Don't forget to include the original cost of the patent itself.

I won't fault M$ for being the conglomerate that it is. Rarely will you see a company of that size have the head wagged by the tail. Sure, it would be nice to have access to the code for M$ freely but we do have tools to get that. Just not the documentation to support that code.

How do you think that things are reverse engineered? Be it software or hardware you use the tools available to you to take the thing apart. Sure at times it can be difficult but it is done. Look at what China is doing today with our hardware and software. Sure some of it is just out right theft but other things are just good engineering.

This is not Rome we are speaking about but a world problem. Too share everything openly would present major problems to all. Trade secrets, atom bombs or whatever information can present a whole different set of problems that could trigger bigger ones. Pun intended!

I've said it before. If there's a piece of hardware that doesn't have a driver for your Linux then find a piece that does. If the manufacture won't support Linux, no one can force them. If GNU/Linux was on everyone's desktop then there wouldn't be a problem.

Why and how? What problems? If they hadn't been open, we would be using thousands of incompatible with each other PCs.
I don't need M$ products source code. You could fix yourself (like winmodems), if the specifications would be known. Reversing hardware is nearly impossible for casual person (yeah, yeah, there are mod chips, but they only circumvent protection).

You've missed that 30 years ago everything was open. IBM didn't went bankrupt, neither AT&T, nor HP. Only nowadays some obscure interfaces are becoming are a huge problem.

This misconception is coming from Windows and is wrong. Software should be developed to suit available hardware and not vice versa.