While an antitrust suit against intel is rather interesting, I'm more interested in seeing what cool new chips AMD comes up with next. It has since been AMD's style to come up with next big thing a whole quarter or more before intel brings it to the market. They aren't going to win market share with an antitrust suit, but they may (keyword: may) level the playing field with software and hardware manufacturers a bit. Linux users seem to be AMD's most avid fans; are we not always rooting for the underdog? AMD may not be the underdog for long as they continue to gain market share with their main feature: superior power and engineering at a lower pricepoint than their primary competitor.
There has been a question about Lindows that has been nagging me for quite some time (other than: how did you get microsoft to piss off about the obvious Windows rip):
In your own opinion, what makes Lindows a superior linux distribution for the desktop over, say, RedHat, Debian, or SuSE?
-Kp2Sushi
Ok, I'll be the first to say that "glowing balls" sounds really funny.
There are two ways to do this. One is easy and the other requires some hardware skills.
Ok, I'll give some hardware background. The parallel port is really the way to go because you have 8 (count 'em) data pins. From each of the data pins you connect a little device called an opto-isolator. I've seen octal opto-isolators in a DIP package. If that went over your head, it basically means that there are 8 individual opto-isolators in a single package. The opto-isoloator will have the dual function of protecting your parallel port from dangerous currents and it will behave as a relay. The major advantage to this method is that you can build this arangement in a very small package.
The second method gives you more control over the brightness of the bulbs. Microchip Inc. makes these nifty microcontrollers called PIC chips. You can buy one with DAC (Digital to Analog Converter) outputs. You wire the DAC outputs to a FET (field effect transistor, I'd recommend a small MOSFET) and then wire the FET to the leads of the LEDs. The second connection you will make is from the parallel port to the PIC chip. I've never done this arrangement before, but I'm guessing you can connect the CLOCK input of the PIC chip to the parallel port's STROBE output. Then you connect the PIC chip to the parallel port. The final step is burning (actually, this would be the first step) a small program to the PIC chip that accepts data from the parallel port and converts the 8but value into an analog voltage. With this method you can control the brightness of each color
I hope this helps some people at least get out the door on, what seems to me, is a very nifty hardware hack.
I know that hydrazine is used. It has been used,at least, since the apollo program.
Hydrazine is a very insidious compound that can suffocate you days after exposure. There were some problems with it in the apollo program. On one ocassion the astronauts openned up the vents to find out that a retro rocket was jammed from reentry. Thankfully they did not suffer any consequences because of their exposure -Kp2
There is a fundamental difference between the AT&T days and now. AT&T was concerned over the use of of AT&T code, not AT&T features. The issue back then was copyright, now it is software patents. BSD was able to give AT&T the finger by rewriting the entire code base. Linux may be in trouble because it may violate an SCO patent. Where the kernel does this is anybody's guess; I've never heard of anyone patenting system calls, the TCP/IP stack, the VFS layer, etc.
A quick search of the US patent office does not return any SCO patents. If they have a leg to stand on, I do not know. I'd like to see these patents before I believe that SCO can do anything.
Oh, and I'd pass the word on never using an SCO (Caldera) product again. They just dug a very deep hole.
-Kp2
The point of the whole matter is whether or not we want our libraries to be used as a standard or not. The more open the source is, the better we are all off in the end.
I can agree that, ideally, applications that use open libraries should be open themselves, but the LGPL would not have been made if there wasn't some good in allowing for proprietary code.
-Kp2
Slashdot Mirror
Linux has maintained it's high quality because it doesn't cater to consumers.
While an antitrust suit against intel is rather interesting, I'm more interested in seeing what cool new chips AMD comes up with next. It has since been AMD's style to come up with next big thing a whole quarter or more before intel brings it to the market. They aren't going to win market share with an antitrust suit, but they may (keyword: may) level the playing field with software and hardware manufacturers a bit. Linux users seem to be AMD's most avid fans; are we not always rooting for the underdog? AMD may not be the underdog for long as they continue to gain market share with their main feature: superior power and engineering at a lower pricepoint than their primary competitor.
There has been a question about Lindows that has been nagging me for quite some time (other than: how did you get microsoft to piss off about the obvious Windows rip):
In your own opinion, what makes Lindows a superior linux distribution for the desktop over, say, RedHat, Debian, or SuSE?
-Kp2Sushi
Ok, I'll be the first to say that "glowing balls" sounds really funny.
There are two ways to do this. One is easy and the other requires some hardware skills.
Ok, I'll give some hardware background. The parallel port is really the way to go because you have 8 (count 'em) data pins. From each of the data pins you connect a little device called an opto-isolator. I've seen octal opto-isolators in a DIP package. If that went over your head, it basically means that there are 8 individual opto-isolators in a single package. The opto-isoloator will have the dual function of protecting your parallel port from dangerous currents and it will behave as a relay. The major advantage to this method is that you can build this arangement in a very small package.
The second method gives you more control over the brightness of the bulbs. Microchip Inc. makes these nifty microcontrollers called PIC chips. You can buy one with DAC (Digital to Analog Converter) outputs. You wire the DAC outputs to a FET (field effect transistor, I'd recommend a small MOSFET) and then wire the FET to the leads of the LEDs. The second connection you will make is from the parallel port to the PIC chip. I've never done this arrangement before, but I'm guessing you can connect the CLOCK input of the PIC chip to the parallel port's STROBE output. Then you connect the PIC chip to the parallel port. The final step is burning (actually, this would be the first step) a small program to the PIC chip that accepts data from the parallel port and converts the 8but value into an analog voltage. With this method you can control the brightness of each color
I hope this helps some people at least get out the door on, what seems to me, is a very nifty hardware hack.
-Kp2Sushi
Hydrazine is a very insidious compound that can suffocate you days after exposure. There were some problems with it in the apollo program. On one ocassion the astronauts openned up the vents to find out that a retro rocket was jammed from reentry. Thankfully they did not suffer any consequences because of their exposure
-Kp2
There is a fundamental difference between the AT&T days and now. AT&T was concerned over the use of of AT&T code, not AT&T features. The issue back then was copyright, now it is software patents. BSD was able to give AT&T the finger by rewriting the entire code base. Linux may be in trouble because it may violate an SCO patent. Where the kernel does this is anybody's guess; I've never heard of anyone patenting system calls, the TCP/IP stack, the VFS layer, etc. A quick search of the US patent office does not return any SCO patents. If they have a leg to stand on, I do not know. I'd like to see these patents before I believe that SCO can do anything. Oh, and I'd pass the word on never using an SCO (Caldera) product again. They just dug a very deep hole. -Kp2
The point of the whole matter is whether or not we want our libraries to be used as a standard or not. The more open the source is, the better we are all off in the end. I can agree that, ideally, applications that use open libraries should be open themselves, but the LGPL would not have been made if there wasn't some good in allowing for proprietary code. -Kp2