This is interesting. In a rather recent verdict here in Sweden, links to mp3's were found to be
legal. Meanwhile, in the US, links are found to be illegal. If this holds up in higher court, this could lead to a lot of spinoff-lawsuits. Think
links to mp3-sites, links to sites with warez,
etc.
<irony mode=on>I wonder how long before
the US outlaws search-engines...<irony mode=off>
Advanced Interactive Executive for the
Personal System/2 (AIX PS/2) Version 1.1
complete with manuals et al.
It's cool to have, but it is totally worthless... more? No. pgview,
which wasn't (iirc) wasn't pipeable. Oh, and
no TCP/IP-stack and no X-Server included. Those
had to be bought separately.
But the latest versions of AIX (v4.x for RS/6k)
are very nice. Especially smitty, the
setup-handler.
If I'm not all wrong, DivX uses MPEG2 for the video-compression and MPEG1layer3 for the audio (please correct me if I'm wrong...)
Wouldn't it be interesting to try OGG-compression for the audio-stream instead? To my knowledge, mp3-_en_coders are non-free, so using OGG instead would at least make things a little better from this point of view (from my understanding, again feel free to correct me, OGG is an open spec which does not require licensing)
Most of MacOS (except for the pieces that needs most optimisation) is written in C; using Apple's MPW (Macintosh Programmer's Workshop), freely downloadable from Apple's website ftp://ftp.appl e.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_e tc./. I suspect most applications for MacOS are either developed using MPW or CodeWarrior.
The GUI-parts and the programmer-interface (Aqua and Cocoa) for MacOS X are written in Objective C, while the kernel and the BSD-layer (Darwin) is C.
Show me one category where Linux offers better apps than the Mac, and I'll eat my PowerBook.
Well, let's see:
Pretty much anything related to software development. I mean you get a free (high quality) optimizing compiler, debugger, a whole load of libraries, etc.
While gcc/gdm etc are great and for free (and, maybe more important, FREE), there was no comparision in price. And if you ignore the monetary bit, I'd say Codewarrior is probably the best IDE for code-developing there is. I know that there is a Linux-version there as well. I don't know if they compare, but I'm pretty sure it doesn't out-do the MacOS version...
Network servers. I hope I don't need to say any more about that.
Well, that depends on what kind of servers we're talking about. If it's mail-servers or news-servers, Linux wins hands down. No question about that. Web-servers too, I guess, apart from one VERY important detail: for E-commerce, nothing can out-trumph WebOjects. Neither of the OS's does NFS (ok, Linux claims to, but its NFS-support sucks elephants through a straw. I hope the v2.4 kernel will finally remedy this and fix all imcompabilties et al is suffers...), but you're right, when it comes to server-applications, Linux is superior. But I got the distinct feeling that the article wasn't about servers, but about home-computers.
Remote access. I can log into my computer at work from home, and do everything I could do if I was actually sitting in my office! (Well, I would be able to if I wasn't running off of a 28.8k modem. But I can still do nearly everything.)
There are perfectly good applications for MacOS to do this too, but alas!, I can not recall their names (it might be Apple Remote Access, ARA.) You can do anything you'd ever like, though.
Mathematical typesetting. Nothing beats TeX and LaTeX when it comes to this. Sure, there's TeX for Macs, but (AFAIK) you have to buy it.
No, you don't have to buy it. It's for free. You only have to pay for it if you want it delivered to you on CD's rather than downloading it, but that's kinda normal, huh? Trust me, I have OzTeX installed, and it works perfectly.
And when it comes to normal typesetting, Linux lacks my absolute favourite program; Quark XPress. And there's nothing remotely similar. Not too strange either, since those programs are quite complicated things. However, I do think that Adobe Indesign would be pretty easy to port because of its modularity. Quark, on the other hand, is a nightmare, both code-wise and format-wise. Those who ever considered Word-documents to be next-to-encrypted, have a look at a Quark XPress document...
I do really hope that a lot of Joe average users do switch over to Linux. But I hope they do it on a decent hardware-platform, be it PPC, Alpha or some redesigned ia64-platform. Because the "continue patching the cruft to keep it from falling apart"-philosophy of the current PC-architecture won't hold forever. This is one reason Apple has a good situation: they don't need to care for old hardware backwardscompability if they realise those solutions stink. I wish the PC-platform could evolve likewise, and dump ISA once and for all, standardise PCI further... But now I'm getting off-topic here, so I'll end now, I guess.
Now this would have been a great help indeed in the Microsoft-trials... Connect it to an electric chair, place Bill Gates on it, and interrogate him thoroughly. He'd probably die answering the very first question, though ("Do you swear to tell the whole truth, nothing but the truth..." (Well, I know that's not the exact wording, sorry!))
Sure it's now possible to release binary only drivers for the Linux Kernel.
Hmmm. Only partially true. Sure, it's possible to release binary-only drivers. But the companies that do also have to release a new such binary for almost every kernel-release. Linus himself said:
"Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules."
Why? The reasons are at least two: first of all, a binary driver can hide the reason of a problem. If the kernel crashes, it is harder to find the bug if you don't have the source-code for everything. This is vital in the kernel-development. Second of all, binary-compability between kernel-releases would need a tightly specified API, set in stone. Doing such things necessarily means being very generic. Linus opinion on generic code is quite well-known too:
"The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs."
So, yes, it IS possible to release binary only drivers for the kernel. But it is not very accepted, and we try to make the life for those who do harder instead of easier, to make sure that they think their decision to do so through once more every time they have to release a set of binaries (one SMP and one UP binary/platform, + some extra binaries for different memory-modes, etc.)
Now, I don't know how the X-Free developers think. I know that I wouldn't appreciate binary drivers, but if it's the only way to get those video-card makers to port their drivers, then maybe we'll have to accept that. Still, isn't it strange that hardware-vendors for bloody-damn every other kind of hardware are beginning to release their specs or open-sourced drivers now? Only the video-card drivers seem to be tight-assed. Letting them go with this might incite others to follow their example and stop releasing their specs. That would suck majorly.
I've heard rumours about Loki porting Alpha Centauri, but I didn't find anything on it on your homepage the last time I looked. Is there any substance in these (imho) very good tidings?
Linux are starting to get quite some nice games, but we're still missing my favourite game-type; Lucasarts' adventures, such as Loom (my alltime favourite), Zak McKracken, Full Throttle, Monkey Island and several others. I'd happily buy these games, were they to be ported to Linux, eventhough I have most of them already.
A few other games I really like to see for Linux are:
Seventh Guest, Eleventh Hour & co
Diablo I, Hellfire and Diablo II
Homeworld
Pandemonium
Backpacker I & II
A genre of games that would get a lot of gamers to consider the Linux platform is racing-games. However, I'm not into those myself, so I can't make any proper suggestions here.
Game-development (to tip those Windoze users over to our side, we MUST have games, because that's almost all they care about)
AbiWord/Gnumeric/DIA
A Project-planning program (a la MS Project; while there are some tries out there, non of them are good; a "Gnome Project" or similar would be very useful)
Convincing Apple to release specs for their older hardware (all the Nubus models, especially the PPC ones)
Getting hardware specs out of Yamaha and other soundcard vendors (good luck on that one!)
Sponsor Alan Cox with a real internet connection...
The feature-freeze effectively means that Linus won't accept anything completely new and unproven into the kernel (unless it's a new platform or just a driver for something; these do not harm the stability of the rest of the system in any major way), not that no new features will go in. And sometimes even new code HAS to go in; to solve unexpected problems and to add support that simply can't wait. The name is a bit deceiving, I must admit. But DevFS and the crypto-patches have both been tested extensively for a long time by others. The journaled file systems will probably not make their ways into the kernel; mainly because they don't work together with the RAID-system in a nice way. Fixing this is a question for the v2.5 development series.
Oh, this release introduced another platform, for those of you that are interested; Mips64. It's time to bring forth your long forgotten SGI Origin...
If you want a horizon to judge anything with, wait for the code-freeze. It should be a signal that a new kernel is upcoming within the month.
Oh, and those of you who wondered: the talk that v2.4 was supposed to be released at the same time as Win2K is simply bs; Linus hasn't said anything such at all. He's smarter than that. What Linus has said, is that he'll release v2.4 when he consider it to be finished and ready to be released, not a day sooner.
Well, it all depends on what you plan to do with USB. Keyboard/Mouse/Joystick/Serial ports should work fine, together with some less common stuff (some cameras, for instance.) All in all, the USB-support itself seems quite stable, but the problem is the lack of drivers for everything but the most common things (that is, those things that share a common standard or one of the USB-developers own...)
If you have some device that isn't supported, why not either write a driver for it (IF you know how to do so, of course), or contact the makers of the device and ask them for a Linux-driver (despite what many companies seem to believe, the consumer is always right. Well, apart from those that buy Micro$oft products, of course; they can't be right in their heads...)
Well, I don't know whether they can help us in the move towards v2.4 (it is after all supposed to be feature-frozen, eventhough this isn't perfectly true...), but for v2.6, it would be great to receive help with, for instance, porting Linux to older models of the RS/6000. Also, IBM has a quite nice filesystem, which would be a treat to support in Linux, at least for compability reasons.
When it comes to these latest v2.3.xx kernels (38 and on), I've not experienced ANY disk-corruption whatsoever. There are, however, lost of other bugs, both known and unknown. Why? Because us (relatively) few developers can't possibly try every hardware combination. We have a couple of new subsystems in v2.3 which needs a lot of testing (USB (even if it exists in v2.2, this one has been rewritten quite extensively), FireWire, PCMCIA, I2C, I2O), as well as a lot of new drivers for soundcards, videocards, TV/Radio-cards, disk-controllers etc. The list can be made much longer.
Oh, and if you have an SMP-machine, you should definitely try v2.3.xx; a lot of SMP-related changes has been made, to improve the performance.
So please, unless you have production-machines, give the v2.3.41 or upcoming developmental kernels a try. You will certainly help both yourself and the Linux-community out in the long run.
If (when) you find bugs, submit them to linux-kernel@vger.rutgers.edu.
I'd really like to see ports of all the wonderful Lucasart adventures, such as Zak McKracken, Maniac Mansion, Monkey Island et al.
Some of these are really old, but personally I wouldn't mind. The could at least port the more recent ones, such as Full Throttle, Monkey Island 3, and Grim Fandango.
It all depends on how you define pornography. At least here in Sweden, even the most militant Feminists agree on that there is a huge difference between Eroticism and Pornography. While the former focus on the mutual pleasure of the two persons involved, the beauty of a naked body or the sensualism of the moment, the latter merely objectifies the involved, usually mainly the female part. Pornography is simply the outlet for many person's desires or sexual frustrations.
Pornography is all about objectification and exploitation. Little if any pornography focuses in the pleasures -- the focus is all on the sexual act itself.
Quicktime is probably one of the last products Apple would ever opensource; not because they make much money of it (eventhough they earn quite a lot), but because a lot of stuff in Quicktime is licensed from other companies, most notably the Sorenson Codec. And I can't imagine that Codec ever to be opensourced, sadly enough. So while Apple could theoretically opensource the frameworks for Quicktime, it'd be basically useless without all the Codec's, probably just able to play a few audio formats and some basic movie formats.
Sad but true. So Apple is not to blame if Quicktime isn't opensourced. But of course I'd be really happy if Quicktime indeed became opensourced, and even happier if that included all the licensed stuff. While mtv plays mpeg-movies, it can't be accused of doing it with high-quality...
Well, if this bug repeats itself for v2.2.14, you should submit another report. However, even if you send a report, always carbon-copy to LKML (Linux-Kernel Mailing List); not every bug that seem to relate to one thing have to, and sometimes the maintainer is away, misses one or two messages in his (her?) inbox or whatever.
Remember that the stream of mail to most kernel- hackers is huge, so if you just send them personal mail, simply procmail it away. You never know for sure. Always send to linux-kernel@vger.rutgers.edu (My, this must be the 3rd or 4th time I write that eddy here on Slashdot today...) as well. Others may be experiencing the same problems.
Remember, without bug-reports we don't know about the bugs...
New platform introduced with v2.2.14 (S/390)
on
Linux Kernel 2.2.14
·
· Score: 4
Something that obviously passed many by is that v2.2.14 introduces a new platform; IBM's mainframe series of computers; S/370 and S/390. While it's hard improbably that more than maybe ten or fifteen readers of Slashdot even have seen one (I have; we got an offer to get one, but had no IPI-3 disks for it, and no OS; at that time the port didn't exist yet...), but they are basically very different and cool machines.
Have a look at IBM's homepage and search around for some information on them. They have BANDWIDTH.
This is at least cool, if nothing else. Now if just anyone could port Linux to VAX, things would be chilling.
Hmmm. That's bad. however, that description isn't a very good bug-report. I suggest you mail a careful description of what system you have and what your problems are. Compile-time related, missing/non-working drivers, file- corruption, hangs/oops:es/panic's, etc.
We do all we can to fix bugs, but we can't fix them unless people report them (ok, we do sometimes when we stumble over silly code by accident, when doing rehauling of code or when having little else to do, but those cases are not in majority.)
linux-kernel@vger.rutgers.edu is the place where you report your problems. Good luck!
There has been lots of fixing of wicked corruption going on for v2.2.14; most of it were very special-cases, but some might have affected larger user-masses. I suggest you upgrade to v2.2.14; it's been tested for a loooong time now, and it seems really stable.
What you should remember is, that if you suspect file-corruption, please send a bug-report and a careful description (hardware, kernel-version, etc.) to linux-kernel@vger.rutgers.edu. More often than not, such reports can be of great help to us when we try to find bugs. This of course applies to other kernel-related bugs too (hangs, etc.)
I'd wager that *IF* AGP gets into v2.2.xx, it'll be for a fairly late one. The code isn't fully finished in v2.3.xx if I'm not all wrong.
When it comes to the experimental patches, everything depend on the hardware you have. I've been running v2.3.xx kernels on my trustworthy IBM PS/2 9556slc2 (SCSI) without troubles (apart from having to patch the ibmmca.c scsi-driver in an ugly way) whatsoever, others report lots of trouble.
v2.3 is good, no doubt about that; lots of new interesting stuff, but it isn't feature-complete; lots of stuff that works in v2.2 is broken for v2.3, such as some of the filesystems, etc (but as long as ext2 and fat works, I'm all happy), and the pre-patches are sometimes hard to get to compile.
Finally, more often than not, at least some platform is broken. Sparc seem to have had most problems, but they were fixed up just a while ago, if I'm not all wrong.
If you have important data on your disk or need 24/7 uptime, use v2.2.14. If you don't fall into any of those categories, and have any hardware not supported in v2.2.xx, try out v2.3; it'll be a nice experience, and we need all the bug- testers we can find.
I find it rather strange that any Bacteria would affect the harmful effects of radioactive material. I don't see how biological processes can, in any way, affect the levels of radiation from a material, apart from possibly shielding it a trifle bit. The only way I know of to make radioactive material less dangerous (apart from just leaving it to its destiny for a couple of million years) is to bombard it with a particle cannon.
But what do I know? And even if (most probably) this only is for "normal" toxic waste, this will probably still be enormously useful, unless companies use this method of reducing their pollution instead of actually reducing the use of dangerous substances in the first place. Those who live (hopefully most of us) can tell.
Slashdot Mirror
This is interesting. In a rather recent verdict here in Sweden, links to mp3's were found to be legal. Meanwhile, in the US, links are found to be illegal. If this holds up in higher court, this could lead to a lot of spinoff-lawsuits. Think links to mp3-sites, links to sites with warez, etc.
<irony mode=on>I wonder how long before the US outlaws search-engines...<irony mode=off>
Sitting in my bookshelf right now is:
Advanced Interactive Executive for the Personal System/2 (AIX PS/2) Version 1.1 complete with manuals et al.
It's cool to have, but it is totally worthless... more? No. pgview, which wasn't (iirc) wasn't pipeable. Oh, and no TCP/IP-stack and no X-Server included. Those had to be bought separately.
But the latest versions of AIX (v4.x for RS/6k) are very nice. Especially smitty, the setup-handler.
If I'm not all wrong, DivX uses MPEG2 for the video-compression and MPEG1layer3 for the audio (please correct me if I'm wrong...)
Wouldn't it be interesting to try OGG-compression for the audio-stream instead? To my knowledge, mp3-_en_coders are non-free, so using OGG instead would at least make things a little better from this point of view (from my understanding, again feel free to correct me, OGG is an open spec which does not require licensing)
Most of MacOS (except for the pieces that needs most optimisation) is written in C; using Apple's MPW (Macintosh Programmer's Workshop), freely downloadable from Apple's websitee tc./. I suspect most applications for MacOS are either developed using MPW or CodeWarrior.
ftp://ftp.appl e.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_
The GUI-parts and the programmer-interface (Aqua and Cocoa) for MacOS X are written in Objective C, while the kernel and the BSD-layer (Darwin) is C.
Show me one category where Linux offers better apps than the Mac, and I'll eat my PowerBook.
Well, let's see:
Pretty much anything related to software development. I mean you get a free (high quality) optimizing compiler, debugger, a whole load of libraries, etc.
While gcc/gdm etc are great and for free (and, maybe more important, FREE), there was no comparision in price. And if you ignore the monetary bit, I'd say Codewarrior is probably the best IDE for code-developing there is. I know that there is a Linux-version there as well. I don't know if they compare, but I'm pretty sure it doesn't out-do the MacOS version...
Network servers. I hope I don't need to say any more about that.
Well, that depends on what kind of servers we're talking about. If it's mail-servers or news-servers, Linux wins hands down. No question about that. Web-servers too, I guess, apart from one VERY important detail: for E-commerce, nothing can out-trumph WebOjects. Neither of the OS's does NFS (ok, Linux claims to, but its NFS-support sucks elephants through a straw. I hope the v2.4 kernel will finally remedy this and fix all imcompabilties et al is suffers...), but you're right, when it comes to server-applications, Linux is superior. But I got the distinct feeling that the article wasn't about servers, but about home-computers.
Remote access. I can log into my computer at work from home, and do everything I could do if I was actually sitting in my office! (Well, I would be able to if I wasn't running off of a 28.8k modem. But I can still do nearly everything.)
There are perfectly good applications for MacOS to do this too, but alas!, I can not recall their names (it might be Apple Remote Access, ARA.) You can do anything you'd ever like, though.
Mathematical typesetting. Nothing beats TeX and LaTeX when it comes to this. Sure, there's TeX for Macs, but (AFAIK) you have to buy it.
No, you don't have to buy it. It's for free. You only have to pay for it if you want it delivered to you on CD's rather than downloading it, but that's kinda normal, huh? Trust me, I have OzTeX installed, and it works perfectly.
And when it comes to normal typesetting, Linux lacks my absolute favourite program; Quark XPress. And there's nothing remotely similar. Not too strange either, since those programs are quite complicated things. However, I do think that Adobe Indesign would be pretty easy to port because of its modularity. Quark, on the other hand, is a nightmare, both code-wise and format-wise. Those who ever considered Word-documents to be next-to-encrypted, have a look at a Quark XPress document...
I do really hope that a lot of Joe average users do switch over to Linux. But I hope they do it on a decent hardware-platform, be it PPC, Alpha or some redesigned ia64-platform. Because the "continue patching the cruft to keep it from falling apart"-philosophy of the current PC-architecture won't hold forever. This is one reason Apple has a good situation: they don't need to care for old hardware backwardscompability if they realise those solutions stink. I wish the PC-platform could evolve likewise, and dump ISA once and for all, standardise PCI further... But now I'm getting off-topic here, so I'll end now, I guess.
Now this would have been a great help indeed
in the Microsoft-trials... Connect it to an
electric chair, place Bill Gates on it, and interrogate him thoroughly. He'd probably die
answering the very first question, though
("Do you swear to tell the whole truth, nothing
but the truth..." (Well, I know that's not the
exact wording, sorry!))
Sure it's now possible to release binary only drivers for the Linux Kernel.
Hmmm. Only partially true. Sure, it's possible to release binary-only drivers. But the companies that do also have to release a new such binary for almost every kernel-release. Linus himself said:
"Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules."
Why? The reasons are at least two: first of all, a binary driver can hide the reason of a problem. If the kernel crashes, it is harder to find the bug if you don't have the source-code for everything. This is vital in the kernel-development. Second of all, binary-compability between kernel-releases would need a tightly specified API, set in stone. Doing such things necessarily means being very generic. Linus opinion on generic code is quite well-known too:
"The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs."
So, yes, it IS possible to release binary only drivers for the kernel. But it is not very accepted, and we try to make the life for those who do harder instead of easier, to make sure that they think their decision to do so through once more every time they have to release a set of binaries (one SMP and one UP binary/platform, + some extra binaries for different memory-modes, etc.)
Now, I don't know how the X-Free developers think. I know that I wouldn't appreciate binary drivers, but if it's the only way to get those video-card makers to port their drivers, then maybe we'll have to accept that. Still, isn't it strange that hardware-vendors for bloody-damn every other kind of hardware are beginning to release their specs or open-sourced drivers now? Only the video-card drivers seem to be tight-assed. Letting them go with this might incite others to follow their example and stop releasing their specs. That would suck majorly.
I've heard rumours about Loki porting Alpha Centauri, but I didn't find anything on it on your homepage the last time I looked. Is there any substance in these (imho) very good tidings?
Linux are starting to get quite some nice games, but we're still missing my favourite game-type; Lucasarts' adventures, such as Loom (my alltime favourite), Zak McKracken, Full Throttle, Monkey Island and several others. I'd happily buy these games, were they to be ported to Linux, eventhough I have most of them already.
A few other games I really like to see for Linux are:
A genre of games that would get a lot of gamers to consider the Linux platform is racing-games. However, I'm not into those myself, so I can't make any proper suggestions here.
The causes that I see need most work:
The feature-freeze effectively means that Linus won't accept anything completely new and unproven into the kernel (unless it's a new platform or just a driver for something; these do not harm the stability of the rest of the system in any major way), not that no new features will go in. And sometimes even new code HAS to go in; to solve unexpected problems and to add support that simply can't wait. The name is a bit deceiving, I must admit. But DevFS and the crypto-patches have both been tested extensively for a long time by others. The journaled file systems will probably not make their ways into the kernel; mainly because they don't work together with the RAID-system in a nice way. Fixing this is a question for the v2.5 development series.
Oh, this release introduced another platform, for those of you that are interested; Mips64. It's time to bring forth your long forgotten SGI Origin...
If you want a horizon to judge anything with, wait for the code-freeze. It should be a signal that a new kernel is upcoming within the month.
Oh, and those of you who wondered: the talk that v2.4 was supposed to be released at the same time as Win2K is simply bs; Linus hasn't said anything such at all. He's smarter than that. What Linus has said, is that he'll release v2.4 when he consider it to be finished and ready to be released, not a day sooner.
Uhm, yeah, my mistake. 132 was the last one
before the pre-patches.
Nope, it didn't. v2.1.126. Then came a series of
pre-patches for v2.2.0...
USB. Keyboard/Mouse/Joystick/Serial ports should work fine,
together with some less common stuff (some cameras,
for instance.) All in all, the USB-support itself
seems quite stable, but the problem is the lack
of drivers for everything but the most common things
(that is, those things that share a common standard or
one of the USB-developers own...)
If you have some device that isn't supported, why not either write a driver for it (IF you know how to do so, of course),
or contact the makers of the device and ask them for a Linux-driver (despite what many companies seem to believe, the consumer is always right. Well, apart from those that buy Micro$oft products, of course; they can't be right in their heads...)
Well, I don't know whether they can help us in the
move towards v2.4 (it is after all supposed to be feature-frozen, eventhough this isn't perfectly true...), but for v2.6, it would be great
to receive help with, for instance, porting Linux
to older models of the RS/6000. Also, IBM has a quite
nice filesystem, which would be a treat to support in
Linux, at least for compability reasons.
(38 and on), I've not experienced ANY disk-corruption
whatsoever. There are, however, lost of other bugs,
both known and unknown. Why? Because us (relatively)
few developers can't possibly try every hardware
combination. We have a couple of new subsystems
in v2.3 which needs a lot of testing (USB (even if
it exists in v2.2, this one has been rewritten
quite extensively), FireWire, PCMCIA, I2C, I2O), as well as a lot of new drivers for soundcards, videocards, TV/Radio-cards, disk-controllers etc. The list can be made much longer.
Oh, and if you have an SMP-machine, you should definitely try v2.3.xx; a lot of SMP-related changes has been made, to improve the performance.
So please, unless you have production-machines, give the v2.3.41 or upcoming developmental kernels a try. You will certainly help both yourself and the Linux-community out in the long run.
If (when) you find bugs, submit them to linux-kernel@vger.rutgers.edu.
Lucasart adventures, such as Zak McKracken,
Maniac Mansion, Monkey Island et al.
Some of these are really old, but personally
I wouldn't mind. The could at least port the more
recent ones, such as Full Throttle, Monkey Island 3,
and Grim Fandango.
Pornography is all about objectification and exploitation. Little if any pornography focuses in the pleasures -- the focus is all on the sexual act itself.
All in all, it seemed pretty neat. I just hope that it'll remain as consistent as MacOS is today.
Sad but true. So Apple is not to blame if Quicktime isn't opensourced. But of course I'd be really happy if Quicktime indeed became opensourced, and even happier if that included all the licensed stuff. While mtv plays mpeg-movies, it can't be accused of doing it with high-quality...
Remember that the stream of mail to most kernel- hackers is huge, so if you just send them personal mail, simply procmail it away. You never know for sure. Always send to linux-kernel@vger.rutgers.edu (My, this must be the 3rd or 4th time I write that eddy here on Slashdot today...) as well. Others may be experiencing the same problems.
Remember, without bug-reports we don't know about the bugs...
Have a look at IBM's homepage and search around for some information on them. They have BANDWIDTH.
This is at least cool, if nothing else. Now if just anyone could port Linux to VAX, things would be chilling.
We do all we can to fix bugs, but we can't fix them unless people report them (ok, we do sometimes when we stumble over silly code by accident, when doing rehauling of code or when having little else to do, but those cases are not in majority.)
linux-kernel@vger.rutgers.edu is the place where you report your problems. Good luck!
What you should remember is, that if you suspect file-corruption, please send a bug-report and a careful description (hardware, kernel-version, etc.) to linux-kernel@vger.rutgers.edu. More often than not, such reports can be of great help to us when we try to find bugs. This of course applies to other kernel-related bugs too (hangs, etc.)
When it comes to the experimental patches, everything depend on the hardware you have. I've been running v2.3.xx kernels on my trustworthy IBM PS/2 9556slc2 (SCSI) without troubles (apart from having to patch the ibmmca.c scsi-driver in an ugly way) whatsoever, others report lots of trouble.
v2.3 is good, no doubt about that; lots of new interesting stuff, but it isn't feature-complete; lots of stuff that works in v2.2 is broken for v2.3, such as some of the filesystems, etc (but as long as ext2 and fat works, I'm all happy), and the pre-patches are sometimes hard to get to compile.
Finally, more often than not, at least some platform is broken. Sparc seem to have had most problems, but they were fixed up just a while ago, if I'm not all wrong.
If you have important data on your disk or need 24/7 uptime, use v2.2.14. If you don't fall into any of those categories, and have any hardware not supported in v2.2.xx, try out v2.3; it'll be a nice experience, and we need all the bug- testers we can find.
Good luck!
affect the harmful effects of radioactive material.
I don't see how biological processes can, in any
way, affect the levels of radiation from a material,
apart from possibly shielding it a trifle bit. The
only way I know of to make radioactive material
less dangerous (apart from just leaving it to its
destiny for a couple of million years) is to bombard
it with a particle cannon.
But what do I know? And even if (most probably) this only is for "normal" toxic waste, this will probably still be enormously useful, unless companies use this method of reducing their pollution instead of actually reducing the use of dangerous substances in the first place. Those who live (hopefully most of us) can tell.