My understanding was that USB3.0 was supported by Linux before any
other OS, and it is meant to be backwards compatible with USB1.1 and
USB2.0 anyhow, so I don't think you'll hit problems there.
Besides USB3.0 is still fairly new, so it will take time for there to
be devices on the market etc, by which time drivers for the
controllers will be pretty stable I'd imagine. Of course take this
with a pinch of salt perhaps
I think you are correct, with at least one implementation. I seem to
remember reading that. There are at least two chips. I don't remember
if both implementations are covered.
SATA3 shouldn't really be a major issue as the chipsets are meant to
be compatiblew th SATA1 and SATA2, but it is a case with a lot of
these things of YMMV.
I don't trust new chips with critical data. It's always something.
It's true that old 3.0Gb/s drive should work, electrically. Is the
firmware solid? 6.0Gb/s drives should work on old chips, electrically.
How flaky is the firmware here? Combine new chip with new drive. Are
we on solid ground now? I shall maintain good backups, at least.
You're correct in both particulars. Thanks for the corrections.
Mark Allums
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Peter Tenenbaum put forth on 2/21/2010 10:01 PM:
> Stan --
>
> It sounds like, if the Realtek drivers are not present on the Debian
> distribution, I have at least two options: going to the Realtek site and
> downloading their linux 64 bit drivers, or compiling my own kernel from
> source on kernel.org. Does that sound about right?
Hay Peter. It's not quite that simple, I'm sorry to say. The drivers are there
in the Debian kernels, and load properly. The problem is that nearly every
intelligent ASIC in a system has firmware that executes on the chip--its own
local OS if you will. With many networking chips, instead of including this
firmware on the card or mobo burned into an eeprom or flash memory chip, some
vendors ship the firmware binary with the driver. It is then up to the host
operating system to upload the firmware binary to the peripheral chip upon each
boot cycle, when it executes the driver code. There are a couple of advantages
to this:
1. Eliminates the cost and complexity of an additional chip (eeprom/flash)
2. Distribution of firmware updates is almost seamless, users oblivious
The problem with the Realtek 8168/9 is that apparently the Realtek folks have
made no firm declarations about the trademark/copyright/patent status of the
firmware code, or if they have, the statements are confusing to the Debian
kernel team. The Debian project is (forcefully) guided by Richard Stallman's
FSF ideals, and thus, any software that doesn't meet the "Free" criteria isn't
included by default. For kernel drivers, this creates a huge problem. There is
no way to include "non-free" in your Debian kernel like you do in
/apt/sources.list. The Debian kernel team makes that choice for your.
The really odd thing is that this firmware blob is included (was?) with the
standard Lenny kernel, 2.6.26. During development of the Squeeze and SID
kernels, the Debian kernel team decided this firmware blob was no longer
considered "free", so they removed it.
> As far as video cards are concerned, I have a (probably) ignorant question:
> how do I put the integrated northbridge video support to use on these
> motherboards, since they do not appear to have any video output spigots on
> them?
Don't get one of those boards. If you're dead set on getting an i5 CPU, the
board linked below is the best bang for the buck by leaps and bounds. And it's
a true blue Intel board. It has an Intel GigE chip, so you'll avoid any of the
Realtek 8168/9 firmware issues discussed above. It has DB-15 VGA, DVI, and HDMI
video connectors on the back panel, so you can connect to pretty much any
computer monitor or HD TV display manufactured in the past 20 years. It uses
the H55 north bridge, so as Mark said, you may/might have to wait a while for
full xorg and 3d support. $99 USD
If you haven't picked out a case yet, I recommend this Apevia:
http://www.newegg.com/Product/Product.aspx?Item=N82E16811144140
I just built a dual core AMD system for my Dad a few months ago with this case.
It's geared toward LAN gamers, but I find it a perfect average user desktop
case, that's just a little bit different enough to be cool yet not tacky. It's
so quiet you must strain to hear it. It has excellent front-back airflow. The
PSU has more connectors than you need, _but_ it includes two SATA drive power
connectors so you don't need to buy adapters. All PSU wires are sheathed in
black braided plastic tubes, which is a really nice touch. It's all aluminum
except for the plastic front face, and the cover which is really lightweight
stamped steel, and can bend somewhat easily if you're not careful with it. The
cover attaches via 3 thumb screws, no screwdriver required. Just a great little
case in my opinion.
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4B821E8A.4040606@hardwarefreak.com">http://lists.debian.org/4B821E8A.4040606@hardwarefreak.com
02-22-2010, 03:05 PM
"Boyd Stephen Smith Jr."
Correct binary for Intel Core i5
In <4B821E8A.4040606@hardwarefreak.com>, Stan Hoeppner wrote:
>Peter Tenenbaum put forth on 2/21/2010 10:01 PM:
>> Stan --
>>
>> It sounds like, if the Realtek drivers are not present on the Debian
>> distribution.
>
> [...] any software that doesn't meet the "Free"
> criteria isn't included by default. For kernel drivers, this creates a
> huge problem. There is no way to include "non-free" in your Debian kernel
> like you do in
>/apt/sources.list. The Debian kernel team makes that choice for your.
That's not true. Whenever a firmware is removed from the upstream kernel
source, as long as it meets the requirements for non-free, it is put into a
firmware package in non-free. In addition, there's a linux-firmware meta-
package in non-free that installs all the firmware that comes with the
upstream kernel.
>The really odd thing is that this firmware blob is included (was?) with the
>standard Lenny kernel, 2.6.26. During development of the Squeeze and SID
>kernels, the Debian kernel team decided this firmware blob was no longer
>considered "free", so they removed it.
The Debian kernel team generally depends on bug reports to let them know that
some new part of the upstream kernel is not free. They remove it once the bug
report is filed.
Since DDs are human, it is entirely possible for non-free parts of packages to
slip through the cracks and get included in a release. The kernel is not the
first package to have this happen.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
02-22-2010, 05:25 PM
Stan Hoeppner
Correct binary for Intel Core i5
Boyd Stephen Smith Jr. put forth on 2/22/2010 10:05 AM:
>> [...] any software that doesn't meet the "Free"
>> criteria isn't included by default. For kernel drivers, this creates a
>> huge problem. There is no way to include "non-free" in your Debian kernel
>> like you do in
>> /apt/sources.list. The Debian kernel team makes that choice for your.
>
> That's not true. Whenever a firmware is removed from the upstream kernel
> source, as long as it meets the requirements for non-free, it is put into a
> firmware package in non-free. In addition, there's a linux-firmware meta-
> package in non-free that installs all the firmware that comes with the
> upstream kernel.
request_firmware() hotplug interface:
------------------------------------
Copyright (C) 2003 Manuel Estrada Sainz
Why:
---
Today, the most extended way to use firmware in the Linux kernel is linking
it statically in a header file. Which has political and technical issues:
1) Some firmware is not legal to redistribute.
2) The firmware occupies memory permanently, even though it often is just
used once.
3) Some people, like the Debian crowd, don't consider some firmware free
enough and remove entire drivers (e.g.: keyspan).
Apparently there are multiple degrees or definitions of "Free", and Debian
doesn't use the same one as other folks. I'm not slinging mud here. I'm
not calling out Debian devs. I'm not saying they're doing anything wrong.
I'm merely stating the fact that they do things a bit differently when it
comes to the definition of "Free". And, this wreaks havoc on Debian users
on occasion, as they're usually totally unaware of the issue until they see
a device break that was working fine before an upgrade.
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4B82CC22.4030304@hardwarefreak.com">http://lists.debian.org/4B82CC22.4030304@hardwarefreak.com
02-22-2010, 06:01 PM
"Boyd Stephen Smith Jr."
Correct binary for Intel Core i5
On Monday 22 February 2010 12:25:38 Stan Hoeppner wrote:
> Boyd Stephen Smith Jr. put forth on 2/22/2010 10:05 AM:
> >> [...] any software that doesn't meet the "Free"
> >> criteria isn't included by default. For kernel drivers, this creates a
> >> huge problem. There is no way to include "non-free" in your Debian
> >> kernel like you do in
> >> /apt/sources.list. The Debian kernel team makes that choice for your.
> >
> > That's not true.
>
> According to this, it is true. Note [3] below:
>
> [01:07:16][root@greer]/usr/src/linux-2.6.31.1/Documentation/firmware_class$
> cat README
>
> request_firmware() hotplug interface:
> ------------------------------------
> Copyright (C) 2003 Manuel Estrada Sainz
[...]
> 3) Some people, like the Debian crowd, don't consider some firmware free
> enough and remove entire drivers (e.g.: keyspan).
This doesn't happen regularly, especially since the request_firmware()
interface was mainlined.
In the bad old days before request_firmware(), non-free firmware basically
required removing whole drivers because the driver was non-functional without
the data in the header file, the header file was non-free, and the Debian
kernel needed to be in main. There were some other ways around this, but
normally dropping the module was the most expedient solution.
Now that we have request_firmware(), even if the original driver uses static
data in a header, the Debian kernel developers take that data and dump it to a
file and put that in non-free. At the same time, the modify the driver to use
request_firmware() instead of expecting the static data in the header. This
is relatively easy to do, so it is the normal way of handling modules that
include non-free firmware. It is rare, but possible, that it is difficult to
modify a module to use request_firmware() instead of static data; dropping the
module might still be more expedient in that case.
So, non-free firmware is normally moved to non-free instead of being dropped
from Debian entirely for many years now. Drivers that were previously dropped
because of non-free firmware might be added back in, if they can be modified
to use request_firmware(). Filing a bug might be appropriate here.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
02-22-2010, 11:19 PM
Johan Kullstam
Correct binary for Intel Core i5
Mark Allums <mark@allums.com> writes:
> On 2/20/2010 5:18 PM, Stan Hoeppner wrote:
>> Peter Tenenbaum put forth on 2/20/2010 4:51 PM:
>>> Hello there --
>>>
>>> I am planning to assemble a new computer for my home, and to run debian
>>> linux on it. I'm planning to use an Intel Core i5-660 CPU in this
>>> computer. From the documentation, it looks like the correct binary to use
>>> is the AMD64. Is this right? Does anyone know of any problems running
>>> debian AMD64 on Intel core-i5 processors?
>>
>> This is the proper binary for the core i5, but that's the least of your worries.
>> Your real concern should focus on whether Debian/Linux has all the drivers for
>> the various hardware devices on the motherboard and in the expansion slots,
>> including, but not limited to:
>>
>> 1. GPU
>> 2. Network interface
>> 3. SATA controller
>> 4. Sound chip
>>
>
> If the MB uses the Intel ICH10 Southbridge, the SATA, at least, will
> work. If the Northbridge is Intel, as it virtually *must* be with the
> Core i5, the GPU will be okay. If the GPU is external, then buying an
> AMD/ATI or NVIDIA card will be safe. Most boards have Marvell NIC
> chips, that's covered.
Really? All I seem to be able to find is Realtek. It is easy to get an
actual card.
> And sound will almost certainly be Intel
> Azalia HD; that's covered. I think you'll be fine.
>
> AMD64 is the designation for the 64-bit chip architecture, not the
> actual chip manufacturer. AMD devised it, and Intel did the sensible
> thing and copied it when they expanded their x86 architecture to
> 64-bit; it was a very good design.
The 32 bit i386 is also viable. There are a few things which are not
yet available for amd64. These are all non-free, but some people want
acrobat reader. And hulu won't work with the 64 bit flash.
> Stay away from the IA64 port. That's for the Itanium.
I did that. It took me like an hour to figure out why my machine
wouldn't boot off the disk. D'OH!
> Mark Allums
--
Johan KULLSTAM
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocjgst1h.fsf@emmy.axel.nom">http://lists.debian.org/87ocjgst1h.fsf@emmy.axel.nom
02-23-2010, 12:22 AM
Mark Allums
Correct binary for Intel Core i5
On 2/22/2010 6:19 PM, Johan Kullstam wrote:
Mark Allums<mark@allums.com> writes:
If the MB uses the Intel ICH10 Southbridge, the SATA, at least, will
work. If the Northbridge is Intel, as it virtually *must* be with the
Core i5, the GPU will be okay. If the GPU is external, then buying an
AMD/ATI or NVIDIA card will be safe. Most boards have Marvell NIC
chips, that's covered.
Really? All I seem to be able to find is Realtek. It is easy to get an
actual card.
ASUS uses Marvell for Gigabit, and Giga-Byte also on some boards. Other
GB boards apparently have other things. Marvell was a popular choice a
few years ago. It may be that now, they aren't the only game in town.
I may be out of touch.
And sound will almost certainly be Intel
Azalia HD; that's covered. I think you'll be fine.
I made that assumption based on the fact that it's an Intel-based board,
but Realtek is still very common for Audio. But Realtek is okay. There
are drivers for it.
AMD64 is the designation for the 64-bit chip architecture, not the
actual chip manufacturer. AMD devised it, and Intel did the sensible
thing and copied it when they expanded their x86 architecture to
64-bit; it was a very good design.
The 32 bit i386 is also viable.
That's true (but it's losing ground fast). Most people install 4 MB or
more these days, and want it all.
There are a few things which are not
yet available for amd64. These are all non-free, but some people want
acrobat reader. And hulu won't work with the 64 bit flash.
Flash is obsolete, and good riddance. HTML 5, FTW! Use
Iceweasel/Firefox, or Google Chrome, and you will find that some YouTube
videos work anyway, and you have flash blocked, or not even installed.
Stay away from the IA64 port. That's for the Itanium.
I did that. It took me like an hour to figure out why my machine
wouldn't boot off the disk. D'OH!
LOL! An hour gone from your life you'll never get back.
Mark Allums
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
In <4B832DBB.5050403@allums.com>, Mark Allums wrote:
>On 2/22/2010 6:19 PM, Johan Kullstam wrote:
>> Mark Allums<mark@allums.com> writes:
>>> AMD64 is the designation for the 64-bit chip architecture, not the
>>> actual chip manufacturer. AMD devised it, and Intel did the sensible
>>> thing and copied it when they expanded their x86 architecture to
>>> 64-bit; it was a very good design.
>>
>> The 32 bit i386 is also viable.
>
>That's true (but it's losing ground fast). Most people install 4 MB or
>more these days, and want it all.
They can still use it all, just not all in a single process by using the i386
userland with the (Debian-provided) amd64 kernel.
Unless you are doing A/V work (Rendering, large image editing, large sound
file editing, or video editing), a single process taking 2+ GiB of memory is
probably indicative of a problem.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
02-23-2010, 03:32 AM
Mark Allums
Correct binary for Intel Core i5
On 2/22/2010 7:44 PM, Boyd Stephen Smith Jr. wrote:
In<4B832DBB.5050403@allums.com>, Mark Allums wrote:
On 2/22/2010 6:19 PM, Johan Kullstam wrote:
Mark Allums<mark@allums.com> writes:
AMD64 is the designation for the 64-bit chip architecture, not the
actual chip manufacturer. AMD devised it, and Intel did the sensible
thing and copied it when they expanded their x86 architecture to
64-bit; it was a very good design.
The 32 bit i386 is also viable.
That's true (but it's losing ground fast). Most people install 4 MB or
more these days, and want it all.
They can still use it all, just not all in a single process by using the i386
userland with the (Debian-provided) amd64 kernel.
Unless you are doing A/V work (Rendering, large image editing, large sound
file editing, or video editing), a single process taking 2+ GiB of memory is
probably indicative of a problem.
Anyway, 32-bit will soon be relegated to smartphones and iPads.
Desktops and serious laptops will need 64-bit in both kernel and
userland. Netbooks? I don't know, but I don't really care, especially.
It's true, you can have large memory with i386, but why?
Mark Allums
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Mon, Feb 22, 2010 at 10:32:55PM -0600, Mark Allums wrote:
>It's true, you can have large memory with i386, but why?
To have still the most compatible system?
Some legacy apps may still be available only as 32-bit.
Theoretically most of the 32-bit software should run fine on 64-bit
kernel with 32-bit userland, but it's not true for all of it -
take Virtualbox as an example. Virtualbox is the reason why I haven't
switched to amd64 kernel, I'm waiting for multiarch support in Debian
(which of course will not help for apps available only as 32-bit and
not compatible with 64-bit kernel, but I don't think I use any of
them).
Yes, I know I could switch to a fully amd64 desktop, yet it's a
not-as-easy-as-it-looks and time-consuming process.
--
Jacek Politowski
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100223064337.GA3994@trek.localdomain">http://lists.debian.org/20100223064337.GA3994@trek.localdomain
Correct binary for Intel Core i5
