So, would anyone out there who is currently using more then even 256 Megs of RAM tell me?
We have a machine with 128GB of RAM here. For many scientific apps you really do need that sort of capacity to deal with the size of the data sets used. If you're working with large databases in business or financial situations, I'd expect that much the same is true - you really want to be able to keep as much of your data in RAM as possible, and you really want to be able to perform complex manipulations.
And no, it's not just an NT thing. One of the more useful features of 2.4 is support for up to 64GB of RAM on IA32 systems. This is something that people want. There's more to life than the desktop, and there's more to servers than just throwing out static web content and processing mail.
Have you tried Debian? Of all Linux distributions it's the most consistant, and it's the only one I know of where failing to follow existing convention is considered a serious bug unless there's a damn good reason for it. See the Debian policy manual for more information.
Re:The problem is in the dependency database
on
An RPM Port Of APT
·
· Score: 3
It's possible to create a deb package for most apps with about 30 seconds of extra effort (dump standard files into top of source tree, edit to change version name and add any vital dependencies, type fakeroot dpkg-buildpackage and wait). You'll end up with a package that can be dumped into a local apt archive and distributed site wide. I prefer this to compiling stuff by hand and installing because it becomes a real pain to keep track of which versions are installed on which systems I look after. Adding local patches is even easier - apt-get source packagename, apply patches, add an extra entry to the changelog and change the version number so that mine won't be overwritten. Rebuild and I now have a package that's identical to the one produced for my distribution except with the changes that I desire.
Sure, this isn't exactly what you want. A system that could do this sort of thing automatically (maybe some sort of wrapper around install(1)) would make life easier still, but with the current situation the time a decent packaging system saves me easily outweighs the extra time taken to play by the packaging system's rules when installing stuff.
Example #2: Linux/mips does not support SGI's O2 or Sony Network Stations, NetBSD does.
On the other hand, NetBSD/pmac does not support 601 processor based systems whereas Linux/pmac does. NetBSD and Linux are fairly similar in terms of platforms supported now - each one supports a few that the other doesn't, but both run on the majority of common and vaguely useful platforms.
You use "an" whenever there's a vowel sound. This includes words beginning with vowels, words beginning with silent hs that have vowel sounds ("hour" takes an, whereas "historic" should take a) and things like "spell it with an s". Many grammar rules are far simpler than is usually made out - if it sounds like it should be an, use an. Otherwise, use a.
When you hover the mouse over an MP3, it'll start playing it without opening an external player. It's probably starting to play just as it gets the file to xmms, then stopping when you move the mouse away.
The primary advantage to consoles is that they allow you to play games without having to worry about whether your graphics card is good enough, whether your drivers are up to date, whether it'll randomly crash for other reasons entirely and all the rest of the hassle you have to go through to get games working on PCs. Put game in. Switch on. Play. That's the advantage of consoles.
Not necessarily. The bounces will end up with the postmaster of the domain that's been forged, who is often nothing whatsoever to do with the open relay.
I use a great little Windows utility called Bounce Spam which sends an email to the spammer looking very much like a message from the server indicating that the message couldn't be delivered.
Spammers don't generally get the bounce messages. Most of them are relay raping some misconfigured mailserver using nothing more than a 33.6 modem with forged envelope from, forged from headers, forged receive lines and more. The bounces will usually end up sitting in the lap of an entirely innocent postmaster. It would take more time for the spammer to process bounces than it would save them when sending the spam in the first place.
However, this does stand a fairly good chance of working with "legitimate" spam (ie, that sent by companies on behalf of themselves) since they're actually paying for their bandwidth.
I ordered some books from Amazon.co.uk last Christmas, making sure at the time that I didn't miss any checkboxes asking them to send me junk relentlessly. As a result, I was somewhat surprised when I started getting adverts from them via email. Apart from the sheer terribleness of the removal instructions (that really didn't cope well with the concept of me replying from a different address to the one they were sending mail to. Why should I have to reconfigure my mail client to deal with their poor quality system?), I was sufficiently annoyed to reply asking why they felt that it was acceptable to email me without asking first. In return I received a form letter telling me that I'd been unsubscribed. I replied saying that this didn't actually answer my question and received another copy of the same email. This happened three more times before I gave up headbutting the sheer wall of cluelessness and simply vowed never to go near them again.
Microsoft were similarly bad. Even after following their unsubscribe instructions, I was still getting mail. I rang up the agency doing the mailing, was politely annoyed at them for 20 minutes and eventually received a full apology and an explanation that Microsoft departments can obtain email addresses up to 3 months in advance of mailings, meaning that even once you're unsubscribed you'll get junk for up to 3 more months. Still, this time they promised that I'd been taken off their lists fully.
Right.
Another ad arrived a week later. A decidedly pissed off email to Microsoft later, I received a copy of my complaint that had been forwarded through 4 levels of customer service drones each adding something like "This customer appears annoyed. Can something be done?" culminating in webmaster@microsoft.com telling me that I'd been removed from all their lists. This time it seemed to work.
Moral of the story? Companies seem significantly more worried about having lots of customers on their email lists than they do about the small number of people who get annoyed at them as a result and probably will carry on doing so until enough people realise that they're not obliged to put up with it.
Yes you can. As pointed out, you can boot ReiserFS as long as your kernel containing partition is mounted with notails, and you can boot off a kernel floppy or with loadlin in any case. EXT3 will work fine - see the documentation. LILO pretty much works by reading a bunch of blocks off the drive and assembling them into a kernel, so is pretty filesystem agnostic providing the filesystem doesn't do strange things like tie together the tails of multiple files into a single block in order to save space (such as ReiserFS, hence the notails option for/boot). I don't know enough about the on-disk layout of JFS or XFS, but personally I'm not inclined to use either of them for my root filesystem yet:)
XFS is optimised for dealing with streaming media, and so deals well with high IO and large files.
JFS has been around for years under AIX. It's a well proven general purpose journalling filesystem.
ReiserFS is the best established of the Linux journalling filesystems. It has several fairly innovative features and is more efficient than ext2 in terms of space utilisation. People are using it as their primary filesystem now, although it's still in development.
EXT3 is (unsurprisingly) a development of EXT2. It lacks most of the pretty features of the other journalled filesystems, but has the significant advantage that you can turn EXT2 partitions into EXT3 (and vice versa) without any trouble at all.
It is not real easy to use kernel drivers between different versions.
If you mean binary drivers, then yes.
Okay, that means that there is a very close relation between the kernel and the driver
Again, yes.
That means that the kernel is monolithic
No. What makes the kernel monolithic is that the drivers are not separate userspace processes.
For example, my NVIDIA drivers required me to downgrade a kernel version and recompile in order to work properly
Your NVIDIA drivers are broken. Go bitch at the provider of your closed, propriatory hardware.
Who said anything about ALSA? I was talking about OSS.
Actually you said that a kernel recompile was necessary in order to change sound hardware. ALSA trivially demonstrates that that isn't true. Even if you are talking about OSS, you still don't need to change your kernel. You made an incorrect claim.
For example, iptables often requires patches to the kernel.
That's because iptables is part of the development kernel. It's a beta. It's not guaranteed to work. If you don't want to have to apply patches, then use a stable kernel.
My aformentioned NVIDIA drivers are terribly closely tied to the kernel version.
From the above, I assume you're using a 2.4 kernel. This is still in development, and as a result the API will change without warning. If the NVIDIA driver was part of the kernel then it would be fixed as the API changes were made and there wouldn't be a problem. If you don't want to deal with that sort of thing yourself, stop using development kernels.
I can't take my sidwinder driver from one kernel and stick it into another.
Which sidewinder driver? If you're talking about the binary module produced from the kernel joystick drivers, then I've already explained that there has never been any guarantee that the binary API of the kernel would remain consistant.
You got to the heart of the problem. There is no stable driver API. That encourages a close connection between driver and kernel. That means it is a monolithic kernel. I don't care if I'm using the term wrong from a technical point of view (though I'm not, Linux IS monolithic technically) but I'm using from a "English" point of view.
(Warning - analogy ahead)
BeOS is a Microsoft operating system. I don't care if I'm using the term wrong from the technical point of view, but BeOS's closed model and pretty graphics demonstrate that I'm right when using it from an "English" point of view.
You can't redefine technical terms in a technical discussion. Yes, Linux is monolithic. No, this is not the reason that it has no consistant binary driver API. Would you call a microkernel that had the same "feature" monolithic? If so, you're an idiot. If not, your argument falls down.
This doesn't seem to bear much resemblance to what you originally wrote. If your complaint is that Linux doesn't have a consistant binary interface between the kernel and modules, then fine - it has absolutely nothing to do with the kernel being monolithic, though. Using technical terms in a non-technical sense during a technical discussion is a somewhat stupid thing to do, if you want people to take you seriously.
The vast-majority of the cases may be true for trival hardware, but is decidely not true for major items like video-cards and sound cards.
The ALSA project consists of sound drivers for a large number of sound cards. It is currently not a part of the Linux kernel (it's supposed to be integrated in 2.5), but is distributed separately. The code is self-contained. It is not a set of patches to the kernel. It in no way changes the kernel code. Could you please explain how compiling ALSA in order to support different sound cards would require me to recompile my kernel? (Note: it doesn't.) As for graphics cards, I've never found that I've had to recompile my kernel in order to reconfigure XFree to use a different card. Even in the case of DRI support (which requires some level of kernel support), the code can be compiled separately from the kernel and certainly doesn't require a kernel recompile in order to use it.
If the fact that a kernel upgrade requires you to recompile the kernel surprises you, I'm somewhat concerned. As a side point, in the vast majority of cases you can compile a module for a specific piece of hardware without having to recompile the kernel or reboot in order to insert it.
Your point about the drivers not being usable between different kernel versions is not directly related to Linux being monolithic. The problem in this case is that Linus has repeatedly stated that he sees no reason to even attempt to maintain a consistant binary interface even between releases of the stable tree given that it would add complexity without benefitting anyone other than people who only distribute binary modules. This is a design choice that could just as well apply to a microkernel.
Your first point has nothing to do with your initial claim. Your second point is something of a truism. Your third point is demonstrably false in most cases.
a lot of people still find it necessary to use BZ2 to compress their kernel because it's still too big.
Sigh. The "b" in "bzImage" stands for "big". On x86, the Linux kernel is generally stored as a gzipped file (note that this isn't true of most other architectures that Linux runs on. PPC, for instance, doesn't use a compressed kernel). The only difference between zImage and bzImage is that the code used to start the kernel is capable of dealing with bigger files in the second case. zImage only exists now because a tiny amount of hardware didn't like the newer code, a situation which has now been fixed.
Sure, you can switch *some* hardware without recompiling, but only that which is already a module...
Almost all hardware can be compiled as a module from an existing source tree and inserted into a running kernel. If it worries you, compiling the kernel with everything as a module is a perfectly valid thing to do. No reboots for changed hardware then.
Rebooting to install hardware is dumb and shouldn't be necessary.
Given that most hardware requires you to switch off the power to install it, I suggest you take this up with the hardware manufacturers as well.
Part of the allure of watching entertainment is to *not* know what's going on in the background.
Do most people who download Apache examine it in detail so they know how it works? Do you know precisely how the Linux VM system is working? Why would playing an open source flight sim mean that you'd know what was going on in the background?
If you want to make a buck off your time, I say go
Of course. How about if I want to contribute for free?
Open source flight sims already exist (Flightgear and Sabre, for example) and work. Most people who use them use them in the same way as they would a commercial flight sim, not worrying about precisely what the code is doing. However, you're given the extra choice of being able to look at the code if you want to. What's the problem here?
Slashdot Mirror
So, would anyone out there who is currently using more then even 256 Megs of RAM tell me?
We have a machine with 128GB of RAM here. For many scientific apps you really do need that sort of capacity to deal with the size of the data sets used. If you're working with large databases in business or financial situations, I'd expect that much the same is true - you really want to be able to keep as much of your data in RAM as possible, and you really want to be able to perform complex manipulations.
And no, it's not just an NT thing. One of the more useful features of 2.4 is support for up to 64GB of RAM on IA32 systems. This is something that people want. There's more to life than the desktop, and there's more to servers than just throwing out static web content and processing mail.
Have you tried Debian? Of all Linux distributions it's the most consistant, and it's the only one I know of where failing to follow existing convention is considered a serious bug unless there's a damn good reason for it. See the Debian policy manual for more information.
It's possible to create a deb package for most apps with about 30 seconds of extra effort (dump standard files into top of source tree, edit to change version name and add any vital dependencies, type fakeroot dpkg-buildpackage and wait). You'll end up with a package that can be dumped into a local apt archive and distributed site wide. I prefer this to compiling stuff by hand and installing because it becomes a real pain to keep track of which versions are installed on which systems I look after. Adding local patches is even easier - apt-get source packagename, apply patches, add an extra entry to the changelog and change the version number so that mine won't be overwritten. Rebuild and I now have a package that's identical to the one produced for my distribution except with the changes that I desire.
Sure, this isn't exactly what you want. A system that could do this sort of thing automatically (maybe some sort of wrapper around install(1)) would make life easier still, but with the current situation the time a decent packaging system saves me easily outweighs the extra time taken to play by the packaging system's rules when installing stuff.
Example #2: Linux/mips does not support SGI's O2 or Sony Network Stations, NetBSD does.
On the other hand, NetBSD/pmac does not support 601 processor based systems whereas Linux/pmac does. NetBSD and Linux are fairly similar in terms of platforms supported now - each one supports a few that the other doesn't, but both run on the majority of common and vaguely useful platforms.
(btw intel is un able to do SMP yet, because of a low level "oops")
Intel have been doing SMP for years.
You use "an" whenever there's a vowel sound. This includes words beginning with vowels, words beginning with silent hs that have vowel sounds ("hour" takes an, whereas "historic" should take a) and things like "spell it with an s". Many grammar rules are far simpler than is usually made out - if it sounds like it should be an, use an. Otherwise, use a.
When you hover the mouse over an MP3, it'll start playing it without opening an external player. It's probably starting to play just as it gets the file to xmms, then stopping when you move the mouse away.
The Debian packages are X from CVS.
The primary advantage to consoles is that they allow you to play games without having to worry about whether your graphics card is good enough, whether your drivers are up to date, whether it'll randomly crash for other reasons entirely and all the rest of the hassle you have to go through to get games working on PCs. Put game in. Switch on. Play. That's the advantage of consoles.
Not necessarily. The bounces will end up with the postmaster of the domain that's been forged, who is often nothing whatsoever to do with the open relay.
I use a great little Windows utility called Bounce Spam which sends an email to the spammer looking very much like a message from the server indicating that the message couldn't be delivered.
Spammers don't generally get the bounce messages. Most of them are relay raping some misconfigured mailserver using nothing more than a 33.6 modem with forged envelope from, forged from headers, forged receive lines and more. The bounces will usually end up sitting in the lap of an entirely innocent postmaster. It would take more time for the spammer to process bounces than it would save them when sending the spam in the first place.
However, this does stand a fairly good chance of working with "legitimate" spam (ie, that sent by companies on behalf of themselves) since they're actually paying for their bandwidth.
I ordered some books from Amazon.co.uk last Christmas, making sure at the time that I didn't miss any checkboxes asking them to send me junk relentlessly. As a result, I was somewhat surprised when I started getting adverts from them via email. Apart from the sheer terribleness of the removal instructions (that really didn't cope well with the concept of me replying from a different address to the one they were sending mail to. Why should I have to reconfigure my mail client to deal with their poor quality system?), I was sufficiently annoyed to reply asking why they felt that it was acceptable to email me without asking first. In return I received a form letter telling me that I'd been unsubscribed. I replied saying that this didn't actually answer my question and received another copy of the same email. This happened three more times before I gave up headbutting the sheer wall of cluelessness and simply vowed never to go near them again.
Microsoft were similarly bad. Even after following their unsubscribe instructions, I was still getting mail. I rang up the agency doing the mailing, was politely annoyed at them for 20 minutes and eventually received a full apology and an explanation that Microsoft departments can obtain email addresses up to 3 months in advance of mailings, meaning that even once you're unsubscribed you'll get junk for up to 3 more months. Still, this time they promised that I'd been taken off their lists fully.
Right.
Another ad arrived a week later. A decidedly pissed off email to Microsoft later, I received a copy of my complaint that had been forwarded through 4 levels of customer service drones each adding something like "This customer appears annoyed. Can something be done?" culminating in webmaster@microsoft.com telling me that I'd been removed from all their lists. This time it seemed to work.
Moral of the story? Companies seem significantly more worried about having lots of customers on their email lists than they do about the small number of people who get annoyed at them as a result and probably will carry on doing so until enough people realise that they're not obliged to put up with it.
Yes you can. As pointed out, you can boot ReiserFS as long as your kernel containing partition is mounted with notails, and you can boot off a kernel floppy or with loadlin in any case. EXT3 will work fine - see the documentation. LILO pretty much works by reading a bunch of blocks off the drive and assembling them into a kernel, so is pretty filesystem agnostic providing the filesystem doesn't do strange things like tie together the tails of multiple files into a single block in order to save space (such as ReiserFS, hence the notails option for /boot). I don't know enough about the on-disk layout of JFS or XFS, but personally I'm not inclined to use either of them for my root filesystem yet :)
Certainly for ReiserFS or EXT3, but I'm not sure about the others.
Will 2.4 ship with one of these?
No.
Do any or all of them break the 2GB filesize limit?
2.4 does this as long as you have a glibc with support for LFS. 2.1 can do this with patches - 2.2 will have it as standard.
DevFS is maintained by Richard Gooch, and is most certainly not part of ReiserFS. Its website is here.
XFS is optimised for dealing with streaming media, and so deals well with high IO and large files.
JFS has been around for years under AIX. It's a well proven general purpose journalling filesystem.
ReiserFS is the best established of the Linux journalling filesystems. It has several fairly innovative features and is more efficient than ext2 in terms of space utilisation. People are using it as their primary filesystem now, although it's still in development.
EXT3 is (unsurprisingly) a development of EXT2. It lacks most of the pretty features of the other journalled filesystems, but has the significant advantage that you can turn EXT2 partitions into EXT3 (and vice versa) without any trouble at all.
Debian. Maybe not for 5 years, but certainly 3.
2.95 is certainly supported for 2.4. As far as I know, 2.96 is not as yet.
It is not real easy to use kernel drivers between different versions.
If you mean binary drivers, then yes.
Okay, that means that there is a very close relation between the kernel and the driver
Again, yes.
That means that the kernel is monolithic
No. What makes the kernel monolithic is that the drivers are not separate userspace processes.
For example, my NVIDIA drivers required me to downgrade a kernel version and recompile in order to work properly
Your NVIDIA drivers are broken. Go bitch at the provider of your closed, propriatory hardware.
Who said anything about ALSA? I was talking about OSS.
Actually you said that a kernel recompile was necessary in order to change sound hardware. ALSA trivially demonstrates that that isn't true. Even if you are talking about OSS, you still don't need to change your kernel. You made an incorrect claim.
For example, iptables often requires patches to the kernel.
That's because iptables is part of the development kernel. It's a beta. It's not guaranteed to work. If you don't want to have to apply patches, then use a stable kernel.
My aformentioned NVIDIA drivers are terribly closely tied to the kernel version.
From the above, I assume you're using a 2.4 kernel. This is still in development, and as a result the API will change without warning. If the NVIDIA driver was part of the kernel then it would be fixed as the API changes were made and there wouldn't be a problem. If you don't want to deal with that sort of thing yourself, stop using development kernels.
I can't take my sidwinder driver from one kernel and stick it into another.
Which sidewinder driver? If you're talking about the binary module produced from the kernel joystick drivers, then I've already explained that there has never been any guarantee that the binary API of the kernel would remain consistant.
You got to the heart of the problem. There is no stable driver API. That encourages a close connection between driver and kernel. That means it is a monolithic kernel. I don't care if I'm using the term wrong from a technical point of view (though I'm not, Linux IS monolithic technically) but I'm using from a "English" point of view.
(Warning - analogy ahead)
BeOS is a Microsoft operating system. I don't care if I'm using the term wrong from the technical point of view, but BeOS's closed model and pretty graphics demonstrate that I'm right when using it from an "English" point of view.
You can't redefine technical terms in a technical discussion. Yes, Linux is monolithic. No, this is not the reason that it has no consistant binary driver API. Would you call a microkernel that had the same "feature" monolithic? If so, you're an idiot. If not, your argument falls down.
This doesn't seem to bear much resemblance to what you originally wrote. If your complaint is that Linux doesn't have a consistant binary interface between the kernel and modules, then fine - it has absolutely nothing to do with the kernel being monolithic, though. Using technical terms in a non-technical sense during a technical discussion is a somewhat stupid thing to do, if you want people to take you seriously.
The vast-majority of the cases may be true for trival hardware, but is decidely not true for major items like video-cards and sound cards.
The ALSA project consists of sound drivers for a large number of sound cards. It is currently not a part of the Linux kernel (it's supposed to be integrated in 2.5), but is distributed separately. The code is self-contained. It is not a set of patches to the kernel. It in no way changes the kernel code. Could you please explain how compiling ALSA in order to support different sound cards would require me to recompile my kernel? (Note: it doesn't.) As for graphics cards, I've never found that I've had to recompile my kernel in order to reconfigure XFree to use a different card. Even in the case of DRI support (which requires some level of kernel support), the code can be compiled separately from the kernel and certainly doesn't require a kernel recompile in order to use it.
You're plainly wrong here.
If the fact that a kernel upgrade requires you to recompile the kernel surprises you, I'm somewhat concerned. As a side point, in the vast majority of cases you can compile a module for a specific piece of hardware without having to recompile the kernel or reboot in order to insert it.
Your point about the drivers not being usable between different kernel versions is not directly related to Linux being monolithic. The problem in this case is that Linus has repeatedly stated that he sees no reason to even attempt to maintain a consistant binary interface even between releases of the stable tree given that it would add complexity without benefitting anyone other than people who only distribute binary modules. This is a design choice that could just as well apply to a microkernel.
Your first point has nothing to do with your initial claim. Your second point is something of a truism. Your third point is demonstrably false in most cases.
a lot of people still find it necessary to use BZ2 to compress their kernel because it's still too big.
Sigh. The "b" in "bzImage" stands for "big". On x86, the Linux kernel is generally stored as a gzipped file (note that this isn't true of most other architectures that Linux runs on. PPC, for instance, doesn't use a compressed kernel). The only difference between zImage and bzImage is that the code used to start the kernel is capable of dealing with bigger files in the second case. zImage only exists now because a tiny amount of hardware didn't like the newer code, a situation which has now been fixed.
Sure, you can switch *some* hardware without recompiling, but only that which is already a module...
Almost all hardware can be compiled as a module from an existing source tree and inserted into a running kernel. If it worries you, compiling the kernel with everything as a module is a perfectly valid thing to do. No reboots for changed hardware then.
Rebooting to install hardware is dumb and shouldn't be necessary.
Given that most hardware requires you to switch off the power to install it, I suggest you take this up with the hardware manufacturers as well.
Sabre is an open source combat flight sim. Going from memory it's based on the Korean era rather than modern day, though.
Part of the allure of watching entertainment is to *not* know what's going on in the background.
Do most people who download Apache examine it in detail so they know how it works? Do you know precisely how the Linux VM system is working? Why would playing an open source flight sim mean that you'd know what was going on in the background?
If you want to make a buck off your time, I say go
Of course. How about if I want to contribute for free?
Open source flight sims already exist (Flightgear and Sabre, for example) and work. Most people who use them use them in the same way as they would a commercial flight sim, not worrying about precisely what the code is doing. However, you're given the extra choice of being able to look at the code if you want to. What's the problem here?