I was astounded by the organic synaptic link technology the Navi had. The Navi were possibly more advanced than we were. Their organic synaptic link tech was more advanced than anything we have. The thing is, they didn't develop weapons. Their entire planet was a linked up hive mind.
What new possibilities could this technology have had? could they start growing Organic ships like the Vorlons from Babylon 5? I'd imagine the Navi probably had better math and science than us.
You are using Samba in a Client Capacity, not a Domain Control Capacity. Apples and Oranges.
What I was refering to is when Samba 3.x Domain Controllers are all that is present. i.e. no Windows Servers. Windows Clients will not negotiate Kerberos with Samba. They treat Samba like NT4. And if you try to switch on Kerberos Realm mode using k5setup, it disables NT Domain support. The only thing you can do is install MIT KfW.
Were you just not paying attention? I just said Samba had a whole slew of LDAP and Kerberos functionality that Windows won't work with. Most of what I talked about only takes place when two Linux boxen are together.
The fact is as long as Samba 3.x exists we will have NetBios. There are alot of Samba 3.x Domain Controllers that manage "Mutant" NT Domains. What I mean is this. The optimal situation for Linux Samba Domain Controllers is this:
You have an OpenLDAP, Kerberos, and Samba. OpenLDAP is the directory service, Heimdal Kerberos is Single Sign on, and Samba is Legacy NT Domain Compatibility and CIFS File sharing. Between two Linux machines, Samba can DNS to look up shares, and use Kerberos to authenticate to shares. This is all well and good. It is very secure, it doesn't use NTLM or NetBios. In the event of a Windows machine accessing a Share, The Windows machine can use DNS to lookup a share, but can't use Kerberos. It has to use NTLM, because in "NT Domain Mode" everything from 2000 on disables Kerberos and you can't turn it back on without the third party MIT Kerberos for Windows Client. (which most people won't do.)
Now, the problem comes when Windows machines try and log in to a Samba Domain. This is where things get a little weird.
Samba backended with LDAP can have multiple PDCs because OpenLDAP has multi-master support. Samba is not limited to PDCs and BDCs the way NT4 is. You can have multiple layers of Trusting Domains, and all of your Domain Controllers being writable PDCs. in fact, the only real difference between Active Directory and "Open Directory" is: Windows Won't negotiate with it.
(this also applies to Kerberos. Multimaster Kerberos KDC is possible only with OpenLDAP support but thats outside the scope of this discussion.)
Because of this, you can haave multiple PDCs, and multiple NetBios scopes. This is important, because Windows clients always broadcast for their Domain Controller. Unlike with Active Directory, (and other Linux Clients) which uses SRV records to find the Directory services using DNS, Windows clients always broadcast and have a "Browser Election" to find out who the PDC is.
This means that Windows' Boneheadedness about not wanting to talk to anything that is not a "Pure AD" is the problem here.
The proper solution would have been for Windows to go back to the while idea of there being a "Windows Explorer" and an "Internet Explorer". Like 95 had. Windows explorer (explorer.exe) just ran the GUI Shell. The Ballot screen would be a small program that downloads the programs and installs them.
But that really wouldn't have dented MS's near-monopoly.
If governments really wanted to give MS a run for its money, the following stigma would have had to be made:
Makers of x86 applications should have been mandated to produce a (Generic) Linux, Windows, and OSX port of all their software. That means Quicken, that means Adobe, that means, everyone else. Makers of hardware needed to be mandated to make a Windows, Linux, and OSX driver for their device. Before the fanboys who talk about how the Linux Kernel changes so much, Nvidia does this very well with the Dynamic Kernel Management (DKMS) Shim. And the rest of their driver stays closed source. So we know this works annd can be done.
I'm not trying to say that user choice and the variance of Linux distributions are bad, but I see some problems that make my life a headache. Especially on the RPM side of things.
For example.
The Four major Desktop distributions out there are:
Fedora OpenSUSE Mandriva Ubuntu.
Ubuntu is Debian based, and not like the other three. So, I will set it aside just momentarily. I'd like to focus on the RPM based systems for the moment because that is what I have the most experience with.
The three RPM based systems have a whole lot of needless Dissimilarities. Even in the RPM system itself. has strange separations in the way it handle packaging. There really is no reason for these differences to exist. Other than making it more difficult to install and manage software, there is no reason for these differences to exist. They just confuse people.
Another thing that drives me berserk is how the RPM distributors tend to "tinker" with the default KDE and Gnome Installs configuration. For example, replacing the Kicker logo with their own Mandriva/Suse/Fedora logo. This really confuses people. It doesn't add to the user experience at all to change how applications are ordered at random, or change the Icon for the K and Gnome Menus. It just confuses people more.
You don't see this in the Debian world. They leave should leave the default configurations of KDE, Gnome, and the other Window managers. Also, a memorandum of understanding or treaty should be formed that says that they will have uniform RPM Macros, and Uniform Application categories.
Mandriva had a function like this called rurpmi. (r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages. I'm not sure if this is exactly the same thing.
Why are these Russian computer programmers not making applications to fill the gaps. If there is a bug, why not just fix it? Its Russia, they have tremendous talent for coders. Just commit some coders to fixing bugs, then submit them back upstream to the application distributor. If I can file bug reports, so can they, but I never see them actually do it.
When ext3 came out, I had reservations about it, and I stuck to ext2 until I was reasonably sure ext3 was totally safe. I've heard bad things about Ext4 corrupting data. While not as overtly malicious as Pulse Audio, (Which is an insidious parasite. Difficult to remove.) ext4 scares the Hell out of me at this state.
I urge Linux users to stick to ext3 for the protection of your data. At least for another year, give ext4 the chance to mature, then, when we are certain ext4 is safe, start using it.
That is a tragic experience. The thing is, MythTV is in shambles and I know it. Its not easy to configure or use. I still support MythTV. But there is room for improvement. There are other Linux competitors to Myth out there. Support them if need be. But the truth is the Linux movement needs every warm body it can to fight Microsoft.
FatELF was the wrong solution to the problem. In the Linux community, we do have a cross distribution application issue. But its one of pure stubbornness.
What do I mean? Suse has its way of setting up RPMs, Mandriva has its, RedHat (Fedora) has its. The three big names in RPM all fight each other over stupid things like RPM Macros, when RPMs are all 95% the same. We can't decide what to classify anything, so we fight over stuff like Amusements/Arcade vs. Games/Arcade. To some degree the same issue exists between mainline Ubuntu and Debian. Then we have the wonderful: I refuse to use DEB or RPM. e.g. Gentoo, Slackware.
We have propaganda circulating that RPM is proprietary. We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"
It should be policy that application makers UPSTREAM should provide an Source RPM AND a Source DEB.
It should be the case that I should be able to install any RedHat Fedora package, or any Suse Package on my Mandriva box. The people who make these decisions should be locked in a room together until they can come to a consensus how to solve this dispute. The same should be done on the DEB Side. I'm tired of having to take Suse or Fedora Packages and "converting" them by hand to make them acceptable and vice versa. This headache can be resolved if we all sit down and play nice together.
Mandriva makes their own setting up Samba application. But you have to realize that Samba is a VERY sophisticated peice of software. But you are right.
Is it possible that Wine could grow more powerful by running viruses on it, learning about how the virus interacts with Windows, and then figuring something "undocumented" about Windows from the virus? I could see Wine gaining alot of new and better functionality by learning from Windows Viruses that malware writers write. Turning every malware writer an unwitting Wine contributor.
Pulse Audio is killing Audio on Linux. It breaks everything. Its compatible with almost nothing. Even if you disable it, its not really gone, because everything processed through ALSA gets processed through PA using extra CPU cycles. Its horrible, and my distributor won't get rid of it in spite of repeated calls for Pulse Audio's death.
As for the mixer issue. If a given sound card does not support hardware mixing, it should be up to the ALSA Driver to handle that. If a given sound card does not support hardware midi, it should be up to ALSA to see to it Timidity handles that. I'd give anything to be able to remove Pulse from the big name Linux distros. We need one Audio driver frame work: ALSA. We need one game abstraction layer. SDL.
No more Pulse Audio, no more JACK, no more Port Audio. None of that bullshit.
I wondered why when Sharepoint was released, in the same manner as Geeklog developed XML-RPC Plugins for Gallery, why they didn't develop XML-RPC Plugins for eGroupware as well. The idea being that eGroupware could integrate with Geeklog the same way it did with Gallery.
Sharepoint and Google Docs are different Animals and people tend not to understand that. Microsoft does not run Sharepoint, they sell you Sharepoint and you install it on Windows Servers internally. You can't install Google Docs on your own servers.
there are a few applications that come close to Sharepoint in the Linux world, like GeekLog and Knowlege tree, but in the Linux world, there is the parasite of unnecessary duplication. Everyone wants to store authentication on MySQL servers. (I'm not knocking MySQL, its excellent for so many beloved tasks, just not authentication.) But thats a square peg for a round hole.
Back in the day before Sharepoint, as a school assignment for one of my higher level CIS Classes I was tasked with making a CMS where as people could upload (Word) documents to the CMS in the form of Articles.
The closest I was ever able to get is with an an application called GeekLog. But there was absolutely no automation. I tinkered with the HTML export aspect of Word, it was an absolute abortion. Useless with Geeklog.
Now that we have linkable libraries for everything under the sun in Linux, I always wondered the following: Why could it not be setup such that so long as an Acceptable format was uploaded (DOC, ODT, WPD, etc) could be parsed into an XHTML 1.0 Compliant article.
I never could lick that problem.
Then another problem came up. I needed a way to Authenticate Geeklog against LDAP, and later single sign on with Kerberos.
I was thinking this all the way back in 2003 and 2004.
Then, low and behold, I start hearing about the abomination that is: Sharepoint.
After I heard about I was like "oh damn it. They got write what all these LAMP Stack PHP applications couldn't think of: LDAP, Kerberos, and the ability to turn binary documents into readable searchable articles."
It was like my worst nightmare come true. GeekLog was a prime example of how Linux developers could have stopped the sharepoint nightmare before it started.
Does this mean that we will be able to colorize Non-Super Gameboy Game Boy Games?
When a Gameboy Color starts up with a Super Gameboy boy game is put into a Super Game Boy, it uses the Super Gameboy Palette with the border that would normally be used on a TV omitted.
Examples of this:
Pokemon Red/Blue/Yellow Donkey Kong
Alot of people thought that Pokemon games were Gameboy Color games, and some are, like Pokemon Crystal, but alot of the games are actually Super Gameboy Games.
Classic Gameboy games such as Tetris, Super Mario Land, and Metroid II had no colorization, so the Gameboy color and Super Gameboy would color them based on an alogorithm. No emulators exist that can colorize a non-Super Gameboy game. They are displayed in Gray Scale.
My question is, will the dumping of this Bios lead to a better understanding of how Non-Super Gameboy Games are colorized on the Game Boy Color?
One of the problems with Star Raiders on the 2600 is that it required a keypad to play, and if you didn't have a "Video touch pad" you were screwed. I nearly screwed over my chances to get a NES when I asked for the video touch pad as an alternative. (My parents never could find the device. It was extremely rare, even in 1989.
Star Master on the other hand had no such requirement. The game required two Atari controllers and the switches to play. It had superior game play. (It had a rank called Wing Commander. a Foreshadowing of the Wing Commander series?)
Years later I played star Raiders on an emulator, and based on what I had seen, if I had gotten that video touch pad instead of the NES, I would have been furious. Star Raiders for the 2600 was horrible.
Slashdot Mirror
I was astounded by the organic synaptic link technology the Navi had. The Navi were possibly more advanced than we were. Their organic synaptic link tech was more advanced than anything we have. The thing is, they didn't develop weapons. Their entire planet was a linked up hive mind.
What new possibilities could this technology have had? could they start growing Organic ships like the Vorlons from Babylon 5? I'd imagine the Navi probably had better math and science than us.
You are using Samba in a Client Capacity, not a Domain Control Capacity. Apples and Oranges.
What I was refering to is when Samba 3.x Domain Controllers are all that is present. i.e. no Windows Servers. Windows Clients will not negotiate Kerberos with Samba. They treat Samba like NT4. And if you try to switch on Kerberos Realm mode using k5setup, it disables NT Domain support. The only thing you can do is install MIT KfW.
Were you just not paying attention? I just said Samba had a whole slew of LDAP and Kerberos functionality that Windows won't work with. Most of what I talked about only takes place when two Linux boxen are together.
The fact is as long as Samba 3.x exists we will have NetBios. There are alot of Samba 3.x Domain Controllers that manage "Mutant" NT Domains. What I mean is this. The optimal situation for Linux Samba Domain Controllers is this:
You have an OpenLDAP, Kerberos, and Samba. OpenLDAP is the directory service, Heimdal Kerberos is Single Sign on, and Samba is Legacy NT Domain Compatibility and CIFS File sharing. Between two Linux machines, Samba can DNS to look up shares, and use Kerberos to authenticate to shares. This is all well and good. It is very secure, it doesn't use NTLM or NetBios. In the event of a Windows machine accessing a Share, The Windows machine can use DNS to lookup a share, but can't use Kerberos. It has to use NTLM, because in "NT Domain Mode" everything from 2000 on disables Kerberos and you can't turn it back on without the third party MIT Kerberos for Windows Client. (which most people won't do.)
Now, the problem comes when Windows machines try and log in to a Samba Domain. This is where things get a little weird.
Samba backended with LDAP can have multiple PDCs because OpenLDAP has multi-master support. Samba is not limited to PDCs and BDCs the way NT4 is. You can have multiple layers of Trusting Domains, and all of your Domain Controllers being writable PDCs. in fact, the only real difference between Active Directory and "Open Directory" is: Windows Won't negotiate with it.
(this also applies to Kerberos. Multimaster Kerberos KDC is possible only with OpenLDAP support but thats outside the scope of this discussion.)
Because of this, you can haave multiple PDCs, and multiple NetBios scopes. This is important, because Windows clients always broadcast for their Domain Controller. Unlike with Active Directory, (and other Linux Clients) which uses SRV records to find the Directory services using DNS, Windows clients always broadcast and have a "Browser Election" to find out who the PDC is.
This means that Windows' Boneheadedness about not wanting to talk to anything that is not a "Pure AD" is the problem here.
Apple is engaging in anti-competitive behavior by tying its OS to its hardware. This behavior should be illegal for any OS, Windows, or OSX.
The proper solution would have been for Windows to go back to the while idea of there being a "Windows Explorer" and an "Internet Explorer". Like 95 had. Windows explorer (explorer.exe) just ran the GUI Shell. The Ballot screen would be a small program that downloads the programs and installs them.
But that really wouldn't have dented MS's near-monopoly.
If governments really wanted to give MS a run for its money, the following stigma would have had to be made:
Makers of x86 applications should have been mandated to produce a (Generic) Linux, Windows, and OSX port of all their software. That means Quicken, that means Adobe, that means, everyone else. Makers of hardware needed to be mandated to make a Windows, Linux, and OSX driver for their device. Before the fanboys who talk about how the Linux Kernel changes so much, Nvidia does this very well with the Dynamic Kernel Management (DKMS) Shim. And the rest of their driver stays closed source. So we know this works annd can be done.
I'm not trying to say that user choice and the variance of Linux distributions are bad, but I see some problems that make my life a headache. Especially on the RPM side of things.
For example.
The Four major Desktop distributions out there are:
Fedora
OpenSUSE
Mandriva
Ubuntu.
Ubuntu is Debian based, and not like the other three. So, I will set it aside just momentarily. I'd like to focus on the RPM based systems for the moment because that is what I have the most experience with.
The three RPM based systems have a whole lot of needless Dissimilarities. Even in the RPM system itself. has strange separations in the way it handle packaging. There really is no reason for these differences to exist. Other than making it more difficult to install and manage software, there is no reason for these differences to exist. They just confuse people.
Another thing that drives me berserk is how the RPM distributors tend to "tinker" with the default KDE and Gnome Installs configuration. For example, replacing the Kicker logo with their own Mandriva/Suse/Fedora logo. This really confuses people. It doesn't add to the user experience at all to change how applications are ordered at random, or change the Icon for the K and Gnome Menus. It just confuses people more.
You don't see this in the Debian world. They leave should leave the default configurations of KDE, Gnome, and the other Window managers. Also, a memorandum of understanding or treaty should be formed that says that they will have uniform RPM Macros, and Uniform Application categories.
I do alot of packaging for Mandriva.
Do not allow Linux users to be silenced
Mandriva had a function like this called rurpmi. (r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages. I'm not sure if this is exactly the same thing.
Why are these Russian computer programmers not making applications to fill the gaps. If there is a bug, why not just fix it? Its Russia, they have tremendous talent for coders. Just commit some coders to fixing bugs, then submit them back upstream to the application distributor. If I can file bug reports, so can they, but I never see them actually do it.
I don't know what hole you crawled out of, but I suggest you stay there until you have legitimate concerns.
when I have a problem, I report it, and I actively do everything I can to fix it, I don't actively attack others sensibilities.
When ext3 came out, I had reservations about it, and I stuck to ext2 until I was reasonably sure ext3 was totally safe. I've heard bad things about Ext4 corrupting data. While not as overtly malicious as Pulse Audio, (Which is an insidious parasite. Difficult to remove.) ext4 scares the Hell out of me at this state.
I urge Linux users to stick to ext3 for the protection of your data. At least for another year, give ext4 the chance to mature, then, when we are certain ext4 is safe, start using it.
That is a tragic experience. The thing is, MythTV is in shambles and I know it. Its not easy to configure or use. I still support MythTV. But there is room for improvement. There are other Linux competitors to Myth out there. Support them if need be. But the truth is the Linux movement needs every warm body it can to fight Microsoft.
FatELF was the wrong solution to the problem. In the Linux community, we do have a cross distribution application issue. But its one of pure stubbornness.
What do I mean? Suse has its way of setting up RPMs, Mandriva has its, RedHat (Fedora) has its. The three big names in RPM all fight each other over stupid things like RPM Macros, when RPMs are all 95% the same. We can't decide what to classify anything, so we fight over stuff like Amusements/Arcade vs. Games/Arcade. To some degree the same issue exists between mainline Ubuntu and Debian. Then we have the wonderful: I refuse to use DEB or RPM. e.g. Gentoo, Slackware.
We have propaganda circulating that RPM is proprietary. We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"
It should be policy that application makers UPSTREAM should provide an Source RPM AND a Source DEB.
It should be the case that I should be able to install any RedHat Fedora package, or any Suse Package on my Mandriva box. The people who make these decisions should be locked in a room together until they can come to a consensus how to solve this dispute. The same should be done on the DEB Side. I'm tired of having to take Suse or Fedora Packages and "converting" them by hand to make them acceptable and vice versa. This headache can be resolved if we all sit down and play nice together.
Mandriva makes their own setting up Samba application. But you have to realize that Samba is a VERY sophisticated peice of software. But you are right.
Is it possible that Wine could grow more powerful by running viruses on it, learning about how the virus interacts with Windows, and then figuring something "undocumented" about Windows from the virus? I could see Wine gaining alot of new and better functionality by learning from Windows Viruses that malware writers write. Turning every malware writer an unwitting Wine contributor.
Pulse Audio is killing Audio on Linux. It breaks everything. Its compatible with almost nothing. Even if you disable it, its not really gone, because everything processed through ALSA gets processed through PA using extra CPU cycles. Its horrible, and my distributor won't get rid of it in spite of repeated calls for Pulse Audio's death.
As for the mixer issue. If a given sound card does not support hardware mixing, it should be up to the ALSA Driver to handle that. If a given sound card does not support hardware midi, it should be up to ALSA to see to it Timidity handles that. I'd give anything to be able to remove Pulse from the big name Linux distros. We need one Audio driver frame work: ALSA. We need one game abstraction layer. SDL.
No more Pulse Audio, no more JACK, no more Port Audio. None of that bullshit.
I wondered why when Sharepoint was released, in the same manner as Geeklog developed XML-RPC Plugins for Gallery, why they didn't develop XML-RPC Plugins for eGroupware as well. The idea being that eGroupware could integrate with Geeklog the same way it did with Gallery.
Sharepoint and Google Docs are different Animals and people tend not to understand that. Microsoft does not run Sharepoint, they sell you Sharepoint and you install it on Windows Servers internally. You can't install Google Docs on your own servers.
there are a few applications that come close to Sharepoint in the Linux world, like GeekLog and Knowlege tree, but in the Linux world, there is the parasite of unnecessary duplication. Everyone wants to store authentication on MySQL servers. (I'm not knocking MySQL, its excellent for so many beloved tasks, just not authentication.) But thats a square peg for a round hole.
Back in the day before Sharepoint, as a school assignment for one of my higher level CIS Classes I was tasked with making a CMS where as people could upload (Word) documents to the CMS in the form of Articles.
The closest I was ever able to get is with an an application called GeekLog. But there was absolutely no automation. I tinkered with the HTML export aspect of Word, it was an absolute abortion. Useless with Geeklog.
Now that we have linkable libraries for everything under the sun in Linux, I always wondered the following: Why could it not be setup such that so long as an Acceptable format was uploaded (DOC, ODT, WPD, etc) could be parsed into an XHTML 1.0 Compliant article.
I never could lick that problem.
Then another problem came up. I needed a way to Authenticate Geeklog against LDAP, and later single sign on with Kerberos.
I was thinking this all the way back in 2003 and 2004.
Then, low and behold, I start hearing about the abomination that is: Sharepoint.
After I heard about I was like "oh damn it. They got write what all these LAMP Stack PHP applications couldn't think of: LDAP, Kerberos, and the ability to turn binary documents into readable searchable articles."
It was like my worst nightmare come true. GeekLog was a prime example of how Linux developers could have stopped the sharepoint nightmare before it started.
Neither Mednafen, nor sdlmess will colorize a non-Super Gameboy Game.
Mednafen fails to activate the Super Game Boy Feature set of Super Game Boy Game.
You are referring to Game Boy Color's Super Game Boy Support. Someone may have to dump the rom of the Super Game Boy to do that.
Does this mean that we will be able to colorize Non-Super Gameboy Game Boy Games?
When a Gameboy Color starts up with a Super Gameboy boy game is put into a Super Game Boy, it uses the Super Gameboy Palette with the border that would normally be used on a TV omitted.
Examples of this:
Pokemon Red/Blue/Yellow
Donkey Kong
Alot of people thought that Pokemon games were Gameboy Color games, and some are, like Pokemon Crystal, but alot of the games are actually Super Gameboy Games.
Classic Gameboy games such as Tetris, Super Mario Land, and Metroid II had no colorization, so the Gameboy color and Super Gameboy would color them based on an alogorithm. No emulators exist that can colorize a non-Super Gameboy game. They are displayed in Gray Scale.
My question is, will the dumping of this Bios lead to a better understanding of how Non-Super Gameboy Games are colorized on the Game Boy Color?
Thats exactly right. It came in a shoebox with 10 other games. I had no idea what a "Video touch pad" even was.
One of the problems with Star Raiders on the 2600 is that it required a keypad to play, and if you didn't have a "Video touch pad" you were screwed. I nearly screwed over my chances to get a NES when I asked for the video touch pad as an alternative. (My parents never could find the device. It was extremely rare, even in 1989.
Star Master on the other hand had no such requirement. The game required two Atari controllers and the switches to play. It had superior game play. (It had a rank called Wing Commander. a Foreshadowing of the Wing Commander series?)
Years later I played star Raiders on an emulator, and based on what I had seen, if I had gotten that video touch pad instead of the NES, I would have been furious. Star Raiders for the 2600 was horrible.
God I feel old.