Bigger and bigger with runtime loadable modules, yes. A bigger source tree to build when you first build a kernel, yes. After that, you're done.
Bigger source to download for users on slow connections, bigger kernels to *maintain.* Bigger kernels for distros to wade through to decide what they want and don't want in the shipping kernel. In general, more things people don't need.
Bigger kernels to load in increasingly convoluted ways. We had zImage. then bzImage. Now initrd is all the rage...if the kernel was smaller, these measures would nto be so very necessary.
Some of this is inherent with a monolithic kernel like Linux, but that's all the more reason to try to keep it in check before it gets even worse.
I don't particularly want to know what type of asphalt is used either - but that should still be kept on record. The same applies to buildings - the architectural diagrams should be kept on record. That way the public can make the best use of a building at a later date. Open records are good - and so is open code. Still, the choice to keep source code openly available is a personal choice for the person funding it. There's the catch - It's my money paying for it, I should be able to see the resultant code.
Should Linux really support a card that's that old? I really wonder now about backward compatibility with hardware. There has to be a time you stop supportign it in a mainstream kernel - or else the kernel will just get bigger and bigger.
Perhaps a second mainstream branch should be started, linux-deprecated or something. Once hardware has been out of production for five years, move it out of the main kernel. The person that wants to set up a P120 gateway can, while allowing the newer kernels to stay fully up-to-date with much less legacy code in them.
(Why bother about being down-moderated, some people you manage to tick off with your replies wait until they have moderator status and then find you 5 last posts and give them -1 overrated to "get back".. how lame.. my karma is always around 50 anyway)
Why mention that? I never considered that, let alone did it. Bragging about karma - now that is lame.
Now, on to the meat of this. Care to become something besides a troll? The whole point of your post appears to be "guns are stupid and so are you so there."
yeah, the "edge enhancement" in the Simpsons DVDs made the image too sharp and destroyes the subtle color gradations in some places. the black lines were too black, etc.
For minijacks, you might look toward the Griffin iMic. It's a USB-attached sound input preipheral, with support for regular and PlainTalk mics. I really have no idea how they cooperate with more than one on the same system, though.
You can also get similar hardware for Midi connectors.
For a PCI-based solution, I know the SBLive! is supported on Macs by Creative. I don't know about the Audigy.
In the U.S. in 1998, there were 30,708 deaths from firearms: Suicide 17,424; Homicide 12,102; Accident 866; Undetermined 316. And no rational person could possibly claim that self-defense uses of firearms saved anywhere near that many lives.
Any person so determined could commit suicide without a gun. The same goes for homicide. The only deaths clearly attributable to guns here are accidental deaths. You could also include some of the indeterminate deaths and homicides, as some no doubt would not have happened without the immediacy and "convenience" of a gun.
Still, that it no argument that none of those 30,708 deaths would not have happened witout firearems. In fact, I'd venture a guess most of those would still have happened - with a different weapon.
basically, every piece of hardware that is used frequently is directly on the hardware, except for mouse/keyboard. That includes video, network, filesystem, drive access, all the fun stuff.
With clever packaging and moving the compile stage into a two-step process, the same result could be rather duplicated, I imagine. The Win32 api has been shown on all the mentioned architectures, with the only real difference being a crappy monolithic executable format.
The recompile approach was also similar to the way the transitional MacOS versions where when Apple started migrating from 68K series chips to PPC.
...Except Macs support(ed) fat binaries. That tradition is carried on with OS X's application packages. The main difference is platform support during the compile stage instead of during the run stage, but with appropriate compilers a Mac app can be rather universal.
Bus isn't that about what the WinNT HAL was supposed to do? It *did* facilitate porting to Alpha, MIPS, and PowerPC as well as the expected x86 architectures. (That is, until MS decided they didn't want to support more than one architecture.)
I assume a lof of that capability is still around under the hood. The old NT way of porting required a recompile, with an intermediary code step (like java's JVM language) it shouldn't really be too hard for MS to implement.
No, wrong. 6.02 x 10^23 is the number of molecules in one mole.
Anyhow, my comment was a jab about the incorrect usage of SI. You only you use a number between 1 and 10, then your exponent.
So, in trying to correct me, you were wrong in your formatting, and you were wrong mathematically by an order of magnitude. I'm sure you are glad you posted AC so you look less stupid...
That's why I said there isn't *much* money to be made. Maybe more people are intersted in information from the 80s, but I would venture a guess most corporations might.
Even then, such a group would have to need the information wholesale...the search tech isn't quite as interesting as the fact they have all that archive in one place.
...how Google will make money off of this. They supposedly make money off licensing their technology (and presumable their collected data, as well.) No ads whatsoever. I applaud their dedication to that goal so far.
Groups.google.com seems like the kind of thing they're doing just becuase they can, though. I can't imagine there is much money to be made off the technology, because it's all text - the same search tech applies. So, as far as I can tell, there is no business reason to be doing this. it's a drain on resources with little to no return, except for (geek) community goodwill.
The conclusion I draw, then, is Google is in this just for the fun, challenge, or doing something for the community - maybe all three. Philantropy at its best. =)
If I'm understanding this correctly, there is a plug-in arbitecture for the IDE to allow it to be customized to anyone's needs.
Guess what? Metrowerks has been doing this for years. CodeWarrior was modular and allowed the user/developer to extend the IDE in pretty much unlimited ways.
Slashdot Mirror
Who the hell told you that? Your crack dealer?
Bigger and bigger with runtime loadable modules, yes. A bigger source tree to build when you first build a kernel, yes. After that, you're done.
Bigger source to download for users on slow connections, bigger kernels to *maintain.* Bigger kernels for distros to wade through to decide what they want and don't want in the shipping kernel. In general, more things people don't need.
Bigger kernels to load in increasingly convoluted ways. We had zImage. then bzImage. Now initrd is all the rage...if the kernel was smaller, these measures would nto be so very necessary.
Some of this is inherent with a monolithic kernel like Linux, but that's all the more reason to try to keep it in check before it gets even worse.
I don't particularly want to know what type of asphalt is used either - but that should still be kept on record. The same applies to buildings - the architectural diagrams should be kept on record. That way the public can make the best use of a building at a later date. Open records are good - and so is open code. Still, the choice to keep source code openly available is a personal choice for the person funding it. There's the catch - It's my money paying for it, I should be able to see the resultant code.
Whoops, my fault. I was going from memory, as I'm sure you have figured out by now.
All I remembered off hand was the basic rule "if it starts with 5 it's 10 MBit, if it starts with 9 it's 10/100."
It's called "Linux-2.2" or "Linux-2.0". Both are still being maintained, by Alan Cox and David Weinehall respectively.
...but 2.4 still includes support for all that legacy stuff.
Should Linux really support a card that's that old? I really wonder now about backward compatibility with hardware. There has to be a time you stop supportign it in a mainstream kernel - or else the kernel will just get bigger and bigger.
Perhaps a second mainstream branch should be started, linux-deprecated or something. Once hardware has been out of production for five years, move it out of the main kernel. The person that wants to set up a P120 gateway can, while allowing the newer kernels to stay fully up-to-date with much less legacy code in them.
Similar numbers, totally different card.
The 905 is a PCI 10/100 card, the 590 is an ISA 10 MBit card.
(Why bother about being down-moderated, some people you manage to tick off with your replies wait until they have moderator status and then find you 5 last posts and give them -1 overrated to "get back" .. how lame .. my karma is always around 50 anyway)
Why mention that? I never considered that, let alone did it. Bragging about karma - now that is lame.
Now, on to the meat of this. Care to become something besides a troll? The whole point of your post appears to be "guns are stupid and so are you so there."
yeah, the "edge enhancement" in the Simpsons DVDs made the image too sharp and destroyes the subtle color gradations in some places. the black lines were too black, etc.
For minijacks, you might look toward the Griffin iMic. It's a USB-attached sound input preipheral, with support for regular and PlainTalk mics. I really have no idea how they cooperate with more than one on the same system, though.
You can also get similar hardware for Midi connectors.
For a PCI-based solution, I know the SBLive! is supported on Macs by Creative. I don't know about the Audigy.
In the U.S. in 1998, there were 30,708 deaths from firearms: Suicide 17,424; Homicide 12,102; Accident 866; Undetermined 316. And no rational person could possibly claim that self-defense uses of firearms saved anywhere near that many lives.
Any person so determined could commit suicide without a gun. The same goes for homicide. The only deaths clearly attributable to guns here are accidental deaths. You could also include some of the indeterminate deaths and homicides, as some no doubt would not have happened without the immediacy and "convenience" of a gun.
Still, that it no argument that none of those 30,708 deaths would not have happened witout firearems. In fact, I'd venture a guess most of those would still have happened - with a different weapon.
I love this, too.
basically, every piece of hardware that is used frequently is directly on the hardware, except for mouse/keyboard. That includes video, network, filesystem, drive access, all the fun stuff.
With clever packaging and moving the compile stage into a two-step process, the same result could be rather duplicated, I imagine. The Win32 api has been shown on all the mentioned architectures, with the only real difference being a crappy monolithic executable format.
The recompile approach was also similar to the way the transitional MacOS versions where when Apple started migrating from 68K series chips to PPC.
...Except Macs support(ed) fat binaries. That tradition is carried on with OS X's application packages. The main difference is platform support during the compile stage instead of during the run stage, but with appropriate compilers a Mac app can be rather universal.
Bus isn't that about what the WinNT HAL was supposed to do? It *did* facilitate porting to Alpha, MIPS, and PowerPC as well as the expected x86 architectures. (That is, until MS decided they didn't want to support more than one architecture.)
I assume a lof of that capability is still around under the hood. The old NT way of porting required a recompile, with an intermediary code step (like java's JVM language) it shouldn't really be too hard for MS to implement.
iDisk/iTools use WebDAV now (Only on OS X, not OS 9). The iPod is a special-case FireWire drive that's formated with HFS+.
No, wrong. 6.02 x 10^23 is the number of molecules in one mole.
Anyhow, my comment was a jab about the incorrect usage of SI. You only you use a number between 1 and 10, then your exponent.
So, in trying to correct me, you were wrong in your formatting, and you were wrong mathematically by an order of magnitude. I'm sure you are glad you posted AC so you look less stupid...
Or 6.02 x 10^23, if you want to be proper about it...
Not really, but that +1 you keep abusing is going to draw unwanted mod attention to our obvious OT-ness ;)
Um...wrong story. This was the one about stopping light, not Flash virii ;)
Anything that brings us closer to proving Dark Sucker Theory is okay in my book.
That's why I said there isn't *much* money to be made. Maybe more people are intersted in information from the 80s, but I would venture a guess most corporations might.
Even then, such a group would have to need the information wholesale...the search tech isn't quite as interesting as the fact they have all that archive in one place.
...how Google will make money off of this. They supposedly make money off licensing their technology (and presumable their collected data, as well.) No ads whatsoever. I applaud their dedication to that goal so far.
Groups.google.com seems like the kind of thing they're doing just becuase they can, though. I can't imagine there is much money to be made off the technology, because it's all text - the same search tech applies. So, as far as I can tell, there is no business reason to be doing this. it's a drain on resources with little to no return, except for (geek) community goodwill.
The conclusion I draw, then, is Google is in this just for the fun, challenge, or doing something for the community - maybe all three. Philantropy at its best. =)
If I'm understanding this correctly, there is a plug-in arbitecture for the IDE to allow it to be customized to anyone's needs.
Guess what? Metrowerks has been doing this for years. CodeWarrior was modular and allowed the user/developer to extend the IDE in pretty much unlimited ways.
What was that? PHP intoxication? Yeah, pickin' on a typo.
;)
We use a huge amount of JSP, but no PHP, so I haven't noticed that particular issue