redhat is shipping stuff (samba,fat) which _do_ have patent issues, but not shipping ntfs, which doesnt have any patent issues (or at least, redhat won't say which patent numbers -- which is _very_ strange).
but they've changed their excuses several times to explain why they're not shipping it. first it was linux-ntfs isnt stable. now it's 'legal issues' but they wont elaborate.
actually I did ask them about stability problems and they (redhat) claimed you could corrupt unrelated non-ntfs filesystems/partitions by running the ntfs in read-only mode. when i asked them for examples i just got a "well thats what i heard" (third, fourth, fifth hand i guess).
as for due diligence, dont you think that would apply to say, SAMBA?
i'm not claiming it's a secret conspiracy, i'm saying that i've been given essentially BS excuses, waffling and dancing around and in general avoidance of the question altogether. far from conspiracy, i'd just write it off as incompetence/laziness.
and i _did_ ask the people who make it -- the linux-ntfs authors. i quoted redhat's responses to them and basically the reply was that they had no idea what redhat was talking about.
and what exactly is preventing redhat from distributing NTFS like everyone else, commercial or not?
i've asked redhat repeatedly to explain, and they have refused to give a straight answer. first they claimed it was "stability issues", claiming NTFS would "corrupt memory", but wouldnt give any examples and clammed up when i asked for clarifications. then they suddenly changed their story to "legal issues", but again clammed up when asked to explain. patents? copyrights? trade secrets? no answer.
it ain't legal issues -- unless you can point to NTFS patents. and it ain't copyright issues either -- because the code was written from scratch. the codebase for NTFS was developed much the same way as the codebase for SAMBA -- from publically available documentation and reverse engineering. if redhat has a legal problem with NTFS then they shouldnt be distributing SAMBA either.
it also strikes me very odd that they would include FAT filesystems which DO have patent issues, but exclude NTFS which does NOT.
as i stated, when changing from one language to another, you exchange one set of exploits for another. you get away from null pointers and stack overflows of C, and get into all new ones of your chosen language.
java isnt immune, nor is ada, or perl, or just about any other language thats a practical target for openssh.
are you willing to take the performance hit to convert it to another language though?
c is just one step away from being a macro assembler, so it's very fast. it's suitable for writing hardware device drivers, something most other languages are not. you won't be seeing any gigabit ethernet drivers written in java, for example. unless you want your gigabit ethernet driver to perform like 10mbit:-)
the reason there's pointers, etc. is because that's the way CPUs operate. C being such a lowlevel language inherits that functionality directly.
once you get into languages that do typechecking, reference tracking, etc. in order to "avoid evil pointers", you introduce a lot of overhead.
and you don't eliminate the exploits either, you just exchange the old ones for new ones.
don't depend on your programming language saving you from doing stupid things.
The key problem is mankind simple lacks the knowledge to fully understand or appreciate the potential unintended consequences of tampering with DNA.
We can't possibly know, therefore we shouldn't know?
mankind has been tampering with DNA for eons. the result is all the domesticated animals and major crops you enjoy today under the bogus "all natural" banner. the "all natural" "non-gm" "organic" corn grown today is vastly different from any wild corn.
of course, non-GM crops are completely immune to cross pollination with other crops of the same species... right.
hint: within a single species there can be nearly endless varieties, all with very distinct and unique genetic characteristics -- not all of them desirable.
the legal arguments regarding cross pollination are stronger.
fact of life: nearly everything on modern farms for the past several centuries is GM. all domesticated animals, for example, are vastly different from their wild ancestors. nearly all major crops were GM before DNA was ever discovered.
actually the best part is that instead of just calling them "ignorant", they went out and demonstrated it, interviewing the local head of the organization and having them indict themselves with their own words.
the best part of p&t bs was not that they simply stated how things or people were stupid, they proved it, using the stupid people and stupid things themselves.
Of course the issue is low latency. That is the whole point of moving support for the thing to kernel space, because having it entirely in userspace is wasteful and inefficient (additional memory copies, IPC overhead, context switches, scheduling issues).
remember apache vs tux? the big argument for tux was that being in kernelspace you saved copies, overhead, etc. but the apache group proved you could have a userspace solution that was faster than any kernelspace solution.
anyway, you don't have to use realtime priority in order to get low latency, as the lowlatency patches have shown. you can get reliable without realtime priority in userspace with lowlatency patches, which is far better than many "realtime" OS. there's a lot of work going on in this department at the moment.
kernelspace doesnt necessarily mean performance. if you've ever done kernel development you'd know that already.
and no, oss does NOT work "fine" with the Delta 1010. You have no control over channels or formats, you're stuck with running a $500 card as if it were a $5 soundblaster. And the RME cards? No ADAT. Sorry. These cards simply do not map well to the OSS api.
To get something approaching reliable performance, JACK and all its clients must be run as root with realtime priority.
you'll still need realtime priority even with a kernel mixer (you need it in many cases already, even without mixing at all). moving the mixing to kernel solves nothing (except perhaps making it much more difficult and dangerous to thread/smp-ize mixing). if you don't have the cpu, you don't have the cpu. period. moving it from userspace to kernelspace won't save you. it doesnt magically make spare cpu cycles appear out of thin air.
no, what you are asking for is not realtime priority. what you are asking for is low latency. you just don't know it.
Even then, performance is still very poor (my 8 year old 60MHz PowerMac does a better job than JACK).
i doubt your 8 year old 60mhz powermac will mix 64 channels of 48khz 16bit stereo audio, low latency suitable for professional studios. this is what jack was aimed at -- not games. the fact it works with games is because it will scale that low. but it scales really high, too.
not only that, jack is portable.
you seem to be revolving around build a kernel solution based on oss purely for games and nothing else. everyone else is aiming higher than that -- a generic solution which can handle both games and pro audio, both ends of the spectrum.
your oss aim would be an incredibly restrictive environment for mixing, and completely unsuitable for just about everything outside the lowest common denominator audio. oss is depreciated because its api is simply incapable of driving anything beyond very basic audio cards in any basic way. good luck doing serious multichannel work with eg ADAT card and oss.
anyway you just want games, thats fine. stick with 4front oss then.
there _is_ a natural law in linux kernel development, and has been since linux 0.1 -- it is to avoid doing something in the kernel unless there is a very compelling reason not to.
i have yet to hear a compelling reason why a software mixer in the kernel is a better solution than a software mixer in userspace.
this has already been argued to death on linux-kernel and other mailing lists, and the conclusions resulted in artsd and jack -- both userspace. apparently nobody else was able to come up with a compelling argument. i'm willing to hear yours though.
binary authentication of driver files wont save you either. there are other, more straightforward ways of cheating. the extreme effort required to implement binary authentication of video driver files isnt worth the 2 or 3 out of 1000's of cheats out there. hardly any cheats use hacked drivers.
the pb client could prove itself to the server if it used crypto exchanges -- something it doesn't do now.
you get more bang for your buck going after general cheat techniques, not checking for specific binary fingerprints.
and there are cheats which will be extremely difficult to detect, such as cheats which diddle the x86 hardware debug registers in order to stealth themselves.
hint: win32 uses a userspace software mixer. works well enough (although there are other software mixing libraries on win32 used by "pro" audio software when their requirements exceed that of the casual gamer)
there are other ways to exploit a mixer than number of channels to mix. just give it a relatively expensive job to do with just a few channels, like resampling and mixing wildly different input formats. a few channels is quite sufficient to peg cpu.
userspace is not incompatible with performance or ease of use, no matter how much you want it to be so. kernelspace is no guarantee of performance, nor any guarantee of ease of use either.
So you're saying that PB doesn't work, and that evenbalance is basically defrauding Activision et al?
No, I'm saying pb isn't perfect. Its beyond me how you can take my statement and conclude that i'm claiming PB is defrauding activision. Care to share what you're smoking?
Translated, that means "We will 0wn your box to watch everything you do". And that's incompatible with an Open Source Windows emulator.
your translation skills need work. everything pb does is done as a plain jane userspace program, it doesnt (yet) require anything unusual from the win32 api that can't be cleanly emulated.
the fact that bf1942 pb might break under winex doesnt mean winex can't be fixed, or that it's incompatible with pb's overall goal.
after all, pb does run on linux for those games (q3, rtcw, et, etc) which have a native client. sort of demolishes your theory of software publishers locking out linux in order to protect windows.
tony ray isnt stupid. pb has to be conservative lest it get bogged down with false positives and system crashes. this means that a kernelspace pb is rather unlikely. which means pb is likely to be emulateable for the forseeable future.
it sounds like you are extremely agitated by linux users trying to play bf1942 under winex. why does this bother you?
alsa _does_ support mixing on hardware that supports it... which is almost everything these days.
i have no problems using flash simultaneously with other programs (eg xmms, teamspeak, rtcw at the same times). on this cheapass cm8738 chipset integrated into a super cheap $20 motherboard.
what you're asking for software mixing for retarded hardware, which is what esd arts etc are for. (or for programs which are stupid and try to exclusively open/dev/dsp)
jack performs a different function entirely, and one which is completely unsuitable for kernelspace (about as unsuitable as putting mozilla in kernelspace)
those md5sum messages are not pb integrity checks. they are 'punkbuster guid' which are different from the engine guid which is generated from your cdkey.
go poke pb in-memory and watch it blissfully continue to run unaware you've haxed it. we were also able to poke the pb.so files on disk and it didnt detect it.
maybe this will eventually change, but pb does not currently internally integrity check.
anticheat software can't authenticate every gfx driver. do your realize how many are out there? win95/win98/w2k/xp/etc, not to mention all the different service packs. multiply that by the # of different chipsets, and the # of different vendors out there.
it's just not practical to authenticate every gfx driver. hell, it's not even practical to do it on linux where there are a tiny fraction of the # of binary drivers that are out there for windows.
Slashdot Mirror
"Americans in general are not good at taking personal responsibility.
I have yet to see a single nationality which is. It's a human failing in general, not a single specific nation's.
so true, and damned funny to boot.
given that redhat ships samba and fat, your statement makes no sense.
redhat is shipping stuff (samba,fat) which _do_ have patent issues, but not shipping ntfs, which doesnt have any patent issues (or at least, redhat won't say which patent numbers -- which is _very_ strange).
but they've changed their excuses several times to explain why they're not shipping it. first it was linux-ntfs isnt stable. now it's 'legal issues' but they wont elaborate.
actually I did ask them about stability problems and they (redhat) claimed you could corrupt unrelated non-ntfs filesystems/partitions by running the ntfs in read-only mode. when i asked them for examples i just got a "well thats what i heard" (third, fourth, fifth hand i guess).
as for due diligence, dont you think that would apply to say, SAMBA?
i'm not claiming it's a secret conspiracy, i'm saying that i've been given essentially BS excuses, waffling and dancing around and in general avoidance of the question altogether. far from conspiracy, i'd just write it off as incompetence/laziness.
and i _did_ ask the people who make it -- the linux-ntfs authors. i quoted redhat's responses to them and basically the reply was that they had no idea what redhat was talking about.
yes, and i've asked them point blank for patent numbers. they have yet to provide a single one.
and what exactly is preventing redhat from distributing NTFS like everyone else, commercial or not?
i've asked redhat repeatedly to explain, and they have refused to give a straight answer. first they claimed it was "stability issues", claiming NTFS would "corrupt memory", but wouldnt give any examples and clammed up when i asked for clarifications. then they suddenly changed their story to "legal issues", but again clammed up when asked to explain. patents? copyrights? trade secrets? no answer.
it ain't legal issues -- unless you can point to NTFS patents. and it ain't copyright issues either -- because the code was written from scratch. the codebase for NTFS was developed much the same way as the codebase for SAMBA -- from publically available documentation and reverse engineering. if redhat has a legal problem with NTFS then they shouldnt be distributing SAMBA either.
it also strikes me very odd that they would include FAT filesystems which DO have patent issues, but exclude NTFS which does NOT.
as i stated, when changing from one language to another, you exchange one set of exploits for another. you get away from null pointers and stack overflows of C, and get into all new ones of your chosen language.
java isnt immune, nor is ada, or perl, or just about any other language thats a practical target for openssh.
define "unsafe data".
are you willing to take the performance hit to convert it to another language though?
:-)
c is just one step away from being a macro assembler, so it's very fast. it's suitable for writing hardware device drivers, something most other languages are not. you won't be seeing any gigabit ethernet drivers written in java, for example. unless you want your gigabit ethernet driver to perform like 10mbit
the reason there's pointers, etc. is because that's the way CPUs operate. C being such a lowlevel language inherits that functionality directly.
once you get into languages that do typechecking, reference tracking, etc. in order to "avoid evil pointers", you introduce a lot of overhead.
and you don't eliminate the exploits either, you just exchange the old ones for new ones.
don't depend on your programming language saving you from doing stupid things.
The key problem is mankind simple lacks the knowledge to fully understand or appreciate the potential unintended consequences of tampering with DNA.
We can't possibly know, therefore we shouldn't know?
mankind has been tampering with DNA for eons. the result is all the domesticated animals and major crops you enjoy today under the bogus "all natural" banner. the "all natural" "non-gm" "organic" corn grown today is vastly different from any wild corn.
of course, non-GM crops are completely immune to cross pollination with other crops of the same species... right.
hint: within a single species there can be nearly endless varieties, all with very distinct and unique genetic characteristics -- not all of them desirable.
the legal arguments regarding cross pollination are stronger.
fact of life: nearly everything on modern farms for the past several centuries is GM. all domesticated animals, for example, are vastly different from their wild ancestors. nearly all major crops were GM before DNA was ever discovered.
actually, i suggest it is our responsibility to get ourselves the hell off this rock and leave the millions of other species the fuck alone.
actually the best part is that instead of just calling them "ignorant", they went out and demonstrated it, interviewing the local head of the organization and having them indict themselves with their own words.
the best part of p&t bs was not that they simply stated how things or people were stupid, they proved it, using the stupid people and stupid things themselves.
...so if they were true to their cause, they'd be out there campaigning to ban windows.
:-)
birds killed annually, nationwide by:
window panes (98 million)
vehicles (60 million)
communication towers (4 million)
wind turbines (10,000 to 40,000)
household cat (unknown, probably > 40,000
Of course the issue is low latency. That is the whole point of moving support for the thing to kernel space, because having it entirely in userspace is wasteful and inefficient (additional memory copies, IPC overhead, context switches, scheduling issues).
remember apache vs tux? the big argument for tux was that being in kernelspace you saved copies, overhead, etc. but the apache group proved you could have a userspace solution that was faster than any kernelspace solution.
anyway, you don't have to use realtime priority in order to get low latency, as the lowlatency patches have shown. you can get reliable without realtime priority in userspace with lowlatency patches, which is far better than many "realtime" OS. there's a lot of work going on in this department at the moment.
kernelspace doesnt necessarily mean performance. if you've ever done kernel development you'd know that already.
and no, oss does NOT work "fine" with the Delta 1010. You have no control over channels or formats, you're stuck with running a $500 card as if it were a $5 soundblaster. And the RME cards? No ADAT. Sorry. These cards simply do not map well to the OSS api.
To get something approaching reliable performance, JACK and all its clients must be run as root with realtime priority.
you'll still need realtime priority even with a kernel mixer (you need it in many cases already, even without mixing at all). moving the mixing to kernel solves nothing (except perhaps making it much more difficult and dangerous to thread/smp-ize mixing). if you don't have the cpu, you don't have the cpu. period. moving it from userspace to kernelspace won't save you. it doesnt magically make spare cpu cycles appear out of thin air.
no, what you are asking for is not realtime priority. what you are asking for is low latency. you just don't know it.
Even then, performance is still very poor (my 8 year old 60MHz PowerMac does a better job than JACK).
i doubt your 8 year old 60mhz powermac will mix 64 channels of 48khz 16bit stereo audio, low latency suitable for professional studios. this is what jack was aimed at -- not games. the fact it works with games is because it will scale that low. but it scales really high, too.
not only that, jack is portable.
you seem to be revolving around build a kernel solution based on oss purely for games and nothing else. everyone else is aiming higher than that -- a generic solution which can handle both games and pro audio, both ends of the spectrum.
your oss aim would be an incredibly restrictive environment for mixing, and completely unsuitable for just about everything outside the lowest common denominator audio. oss is depreciated because its api is simply incapable of driving anything beyond very basic audio cards in any basic way. good luck doing serious multichannel work with eg ADAT card and oss.
anyway you just want games, thats fine. stick with 4front oss then.
there _is_ a natural law in linux kernel development, and has been since linux 0.1 -- it is to avoid doing something in the kernel unless there is a very compelling reason not to.
i have yet to hear a compelling reason why a software mixer in the kernel is a better solution than a software mixer in userspace.
this has already been argued to death on linux-kernel and other mailing lists, and the conclusions resulted in artsd and jack -- both userspace. apparently nobody else was able to come up with a compelling argument. i'm willing to hear yours though.
memory allocation errors inside the kernel and memory allocation errors outside the kernel are two different things.
when mozilla runs the system out of ram, you can kill it without nuking the rest of the system.
what happens when a kernel driver runs the system out of ram? you deadlock, or worse.
stop treating kernelspace as if it were userspace. it isn't.
binary authentication of driver files wont save you either. there are other, more straightforward ways of cheating. the extreme effort required to implement binary authentication of video driver files isnt worth the 2 or 3 out of 1000's of cheats out there. hardly any cheats use hacked drivers.
the pb client could prove itself to the server if it used crypto exchanges -- something it doesn't do now.
you get more bang for your buck going after general cheat techniques, not checking for specific binary fingerprints.
and there are cheats which will be extremely difficult to detect, such as cheats which diddle the x86 hardware debug registers in order to stealth themselves.
resource starvation in userspace is generally non-fatal. not so in kernelspace.
hint: win32 uses a userspace software mixer. works well enough (although there are other software mixing libraries on win32 used by "pro" audio software when their requirements exceed that of the casual gamer)
there are other ways to exploit a mixer than number of channels to mix. just give it a relatively expensive job to do with just a few channels, like resampling and mixing wildly different input formats. a few channels is quite sufficient to peg cpu.
userspace is not incompatible with performance or ease of use, no matter how much you want it to be so. kernelspace is no guarantee of performance, nor any guarantee of ease of use either.
So you're saying that PB doesn't work, and that evenbalance is basically defrauding Activision et al?
No, I'm saying pb isn't perfect. Its beyond me how you can take my statement and conclude that i'm claiming PB is defrauding activision. Care to share what you're smoking?
Translated, that means "We will 0wn your box to watch everything you do". And that's incompatible with an Open Source Windows emulator.
your translation skills need work. everything pb does is done as a plain jane userspace program, it doesnt (yet) require anything unusual from the win32 api that can't be cleanly emulated.
the fact that bf1942 pb might break under winex doesnt mean winex can't be fixed, or that it's incompatible with pb's overall goal.
after all, pb does run on linux for those games (q3, rtcw, et, etc) which have a native client. sort of demolishes your theory of software publishers locking out linux in order to protect windows.
tony ray isnt stupid. pb has to be conservative lest it get bogged down with false positives and system crashes. this means that a kernelspace pb is rather unlikely. which means pb is likely to be emulateable for the forseeable future.
it sounds like you are extremely agitated by linux users trying to play bf1942 under winex. why does this bother you?
alsa _does_ support mixing on hardware that supports it... which is almost everything these days.
/dev/dsp)
i have no problems using flash simultaneously with other programs (eg xmms, teamspeak, rtcw at the same times). on this cheapass cm8738 chipset integrated into a super cheap $20 motherboard.
what you're asking for software mixing for retarded hardware, which is what esd arts etc are for. (or for programs which are stupid and try to exclusively open
jack performs a different function entirely, and one which is completely unsuitable for kernelspace (about as unsuitable as putting mozilla in kernelspace)
those md5sum messages are not pb integrity checks. they are 'punkbuster guid' which are different from the engine guid which is generated from your cdkey.
go poke pb in-memory and watch it blissfully continue to run unaware you've haxed it. we were also able to poke the pb.so files on disk and it didnt detect it.
maybe this will eventually change, but pb does not currently internally integrity check.
anticheat software can't authenticate every gfx driver. do your realize how many are out there? win95/win98/w2k/xp/etc, not to mention all the different service packs. multiply that by the # of different chipsets, and the # of different vendors out there.
it's just not practical to authenticate every gfx driver. hell, it's not even practical to do it on linux where there are a tiny fraction of the # of binary drivers that are out there for windows.