 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 09 Dec 2008 18:05:30 +0000, Orchid XP v8 wrote:
> Jim Henderson wrote:
>> On Tue, 09 Dec 2008 12:03:06 +0000, Invisible wrote:
>>
>>> Yeah, well... why bother supporting a platform that hardly anybody
>>> uses? *Clearly* it's more profitable to support only the most popular
>>> platforms. ;-)
>>>
>>> That's why no Linux drivers, no Linux games, no Linux apps...
>>>
>>> (Yes, I realise there are a few of these now, but still not that many.
>>> Yet.)
>>
>> This is not an accurate portrayal by any stretch.
>>
>> "no linux drivers" - as someone pointed out, especially as regards
>> legacy hardware support, Linux kicks Windows' ass. The time it becomes
>> a problem is when the manufacturer won't release specifications for the
>> hardware so drivers can be created.
>>
>> "a few" is a poor characterization at best.
>
> I meant there are no Linux drivers for high-end hardware like expensive
> graphics cards. Clearly there *are* Linux drivers for lots of other
> things.
No Linux drivers for what high-end expensive graphics cards, exactly?
Most of those are now Nvidia or ATI IIRC, and there are Linux drivers
that support the majority of those cards, even with 3D (though you often
have to go to a proprietary kernel module for it). I use both the ATI
and Nvidia drivers, so it's not exactly accurate to say that those cards
don't work well with Linux.
> And by "a few" I meant more games and applications rather than drivers.
There's quite a large selection of software. It may not be WoW, but it's
out there.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Tue, 09 Dec 2008 14:54:46 -0500, Tom Austin wrote:
>
>> You can say that again - I'm working on some embedded junk and the
>> amount of stuff that's there is incredible.
>>
>> After fiddling around a bit I found initrd - something that a lot of
>> linux systems use. Pretty cool, especially if you are trying to set up
>> an embedded system.
>
> Yeah, it's quite handy. I always thought it was kinda ironic, though,
> that you could load initrd in order to load a required disk driver.
> Kinda like on NetWare being able to start the system up but then needing
> to load a disk driver to read the disk once the NW kernel is up and
> running (but not exactly the same).
>
> Jim
It came in handy when I was still trying to figure out how to make it
boot. I could boot into a full environment without having to worry
about how to access the CF card and mount it. I could actually get it
up and running, then play with things until I figured it out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 10 Dec 2008 15:29:48 -0500, Tom Austin wrote:
> It came in handy when I was still trying to figure out how to make it
> boot. I could boot into a full environment without having to worry
> about how to access the CF card and mount it. I could actually get it
> up and running, then play with things until I figured it out.
Oh yeah, very much so. The thing to remember is if you rebuild your
kernel, you also need to rebuild your initrd with 'mkinitrd' or you'll
find the system won't boot.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 10 Dec 2008 15:29:48 -0500, Tom Austin wrote:
>
>> It came in handy when I was still trying to figure out how to make it
>> boot. I could boot into a full environment without having to worry
>> about how to access the CF card and mount it. I could actually get it
>> up and running, then play with things until I figured it out.
>
> Oh yeah, very much so. The thing to remember is if you rebuild your
> kernel, you also need to rebuild your initrd with 'mkinitrd' or you'll
> find the system won't boot.
>
> Jim
actually now that I've had more time to think about it, I was actually
using initramfs which has settings to build and pack with the kernel
image. Made it very simple indeed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 10 Dec 2008 16:27:30 -0500, Tom Austin wrote:
> actually now that I've had more time to think about it, I was actually
> using initramfs which has settings to build and pack with the kernel
> image. Made it very simple indeed.
Oh, yeah, that definitely would make it simple. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> No Linux drivers for what high-end expensive graphics cards, exactly?
No accelerated Linux drivers for almost any graphics card.
...I mean for DirectFB, not X :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Do you have *any idea* how long it takes to compile the Linux kernel? I
> mean, damn, how *big* is it?? I thought the final binary was only a few
> KB in size...
My kernel size is about 1,4MB and compiling it takes a few minutes on
Core2Duo system. So it does not take long at all. If you forgot one
driver, the recompile takes even less as not everything has to be
recompiled again.
Why?
Because troubleshooting is easier as I know what is in the kernel and
what is not. Loading it is marginally faster because I only use what I
need. Booting is faster for the same reasons.
For the record: it takes only 11 seconds for my system to go from Grub
menu to login (no X at that point). I use Gentoo.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> My kernel size is about 1,4MB and compiling it takes a few minutes on
> Core2Duo system. So it does not take long at all. If you forgot one
> driver, the recompile takes even less as not everything has to be
> recompiled again.
I still remember compiling Gtk2hs on my laptop. Man, that took a long
time! Mind you, we're talking about a machine with a 32bit processor...
Plus, GTK+ is *huge*!
Still, I guess once you take the "kernel" and add 50,000 device drivers,
it's going to end up rather large. (And presumably even if you disable
something, it still has to do some minimal processing to see that it's
disabled.)
> Why?
>
> Because troubleshooting is easier as I know what is in the kernel and
> what is not. Loading it is marginally faster because I only use what I
> need. Booting is faster for the same reasons.
I would have thought changing the runlevel scripts would have a far
bigger impact...
> For the record: it takes only 11 seconds for my system to go from Grub
> menu to login (no X at that point). I use Gentoo.
For the record: my PC takes about 30 seconds just for the BIOS to finish
doing it's thing. I don't really know why... (Might have something to do
with the RAID functionallity I'm not using.)
I use Windows XP.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's the classical monolithic kernel vs. microkernel war. There are
> advantages and disadvantages in both methods.
Ah ok, so on Windows the kernel includes code to call/use any generic driver
(that is not part of the kernel itself), but on Linux the kernel actually
includes the drivers. And that means if you want to add/remove drivers from
your system completely, you need to recompile the kernel under Linux. Is
that right?
> For example, one disadvantage of Windows is that each new version of
> Windows always breaks a bunch of old drivers, so when you upgrade Windows
> you may find out that your old peripheral just doesn't work anymore.
Yep, am aware of that, usually with non-so-popular hardware you have to wait
an age for the developer to release new drivers.
> When the driver is integrated into the kernel, like in linux, it will
> obviously always work even if the kernel is seriously updated (because
> all the embedded drivers will be updated for the new kernel design as
> well).
When they release a new Linux kernel, how can they be sure that they haven't
broken some other driver out there that someone wants to compile in with
this new kernel? Or is it impossible to develop a driver by yourself
separate to the Linux kernel?
> OTOH linux does support kernel modules. For example, if you want to
> install, let's say, the ATI binary driver, you don't need to recompile
> the kernel.
Hmm ok, so under Linux you have the choice of either running a driver as a
separate module, or compiled in with the kernel?
So what are the benefits of compiling in the driver with the kernel as
opposed to running it as a module then?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > It's the classical monolithic kernel vs. microkernel war. There are
> > advantages and disadvantages in both methods.
> Ah ok, so on Windows the kernel includes code to call/use any generic driver
> (that is not part of the kernel itself), but on Linux the kernel actually
> includes the drivers. And that means if you want to add/remove drivers from
> your system completely, you need to recompile the kernel under Linux. Is
> that right?
Not really, because the linux kernel supports loadable modules. However,
it does support drivers embedded in the kernel as well.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
