I don't really know of any, so this is out of curiosity, too. But besides the finding of a webcam, is there a standard interface to get images/video from it, too?
RealClimate.org
The claim of 100% support, frequent reference to economic processes being the root cause and a hopelessly unconvincing attempt to appear impartial all say one thing - this is a SOCIALIST site and SOCIALISTS will jump on any bandwagon that appears to undermine the capitalist status quo (hence their support for the Islamic Jihad).
That's a nice attempt at marginalizing them with buzzwords and rhetoric. However, you obviously misread. 100% support referred to a limited sample of articles, not the whole.
Economic processes are the root cause - economic processes are what cause people to demand products which have environmental consequences. Is that bad? Not necessarily. Economic processes can also provide the solution. Since this is a tragedy of the commons scenario, it is appropriate for citizens to request that the government step in. However, radical and immediate action is a bad idea, versus a carefully prepared and executed plan to minimize our role in any global warming scenario. I don't see them advocating radical and immediate action, nor the overthrow of capitalism, do you?
Please restrain your jerking knee before you toss out a clear-headed reference in the sea of sensationalism.
Yeah, OK. Just semantics - like embedded, servers, datacenters, research, basically any application outside the end-user graphics/desktop OS, which coincidentally has become irrelevant for the typical consumer outside of the Internet and video games. Yeah, I'm really convinced. Keep trying.
I don't understand your dig about "ideological purity". Who are you addressing here? I fully support anyone's right to choose where and under what terms they use their software, in case that was unclear? You might find that people who protest others getting to enjoy open source software on operating systems they disapprove of are not actually useful contributors to any projects, but rather the type who like to go around stirring up controversy instead of improving the software.
If there were some way for the X11 server to send the application a hint that performance was low, the GUI could automatically scale-down to simpler graphics. (Of course, that approach violates network transparency, but it could be an easy path to higher performance)
It depends what school of thought you come from. Some people think that true transparency in a client/server abstraction means that the application should be completely ignorant of the implementation behind the abstraction. I can think of several instances where a client would benefit from being able to query for situational details and make local optimizations. You mentioned one. Another that immediately comes to mind is OpenGL - OpenGL attempts to completely hide the hardware. Unfortunately, this means that the programmer has no way to know whether he is hitting software fallbacks or whether the hardware implementation is faster than software on a given function.
I really like the idea of hiding implementation, but not to the extent that the application is made too dumb - having access to information about current state inside the implementation could allow the application to make better decisions regarding various aspects of its usability. This would include a X11 toolkit knowing whether it is running locally or remotely.
Hmm. Perhaps checking if DISPLAY has no hostname in it would suffice?
This is the same way Intel used the i740 as a tool to promote AGP. The i740 drivers (and perhaps the hardware) were incapable of mapping textures from local memory. Since all textures had to be stored in system memory, the marketing diagrams showed "OMG! AGP2x is 4 times faster than PCI!!!".
The i740 architecture eventually became integrated into the motherboard chipset as the i810. In-memory texturing makes a lot more sense there.
Voodoo Graphics was capable of SLI too. I have a workstation card with two Voodoo Graphics chipsets on it, made by Quantum 3D. I don't know of any consumer cards which were marketed as being SLI capable.
It will be a long time, because of the high cost of reconfigurable hardware with useful functional units. Eventually a standardized reconfigurable hardware platform complete with consumer electronics and I/O interconnects will become cheap enough for a variety of cool tasks, like the general purpose computer eventually became cheap enough for a variety of cool tasks.
Windows did not take over the world. If it did, we would have no choice but to use it. Clearly, that is false.
You can cram your self-centered ignorance up your ass. I did not mention your EDA or VPN software, nor did I tell you to replace your Windows installation with Linux. I said that by actively ignoring Linux, you might find that in the future you realize that you missed opportunities by being narrow minded. That statement is completely orthogonal to yours.
Nothing stops people from developing an open-sourced driver when a closed-source driver already exists.
You try developing a driver when the vendor makes every excuse in the world not to provide documentation for the hardware. The biggest excuse is a closed-source driver. When a closed-source driver is used as an excuse/apology for not providing documentation, your market theory unfortunately falls to pieces, because the closed source developers have a significant advantage right from the start.
Unsupported hardware is a reasonable argument for using Linux on that system, as opposed to buying a Windows license for that system or upgrading that system. You are living a fantasy if you do not believe Linux is useful for many people even in its current state.
There is no pretense that it will take over the world, just like Windows never took over the world. However, there is little doubt that Linux will be relevant over the next decade. Nobody is requiring that anybody else use an operating system that they dislike, but I think that you may be sad that you missed out on some very tangible benefits when you look back from some future point.
Defensive rage? It's simple. They give us the specs, we give them drivers. Or they can just give us drivers, if they want to be the source of support for those drivers. If they don't give us the specs, and don't write their own drivers, and users complain, how are we supposed to accomodate those users? Telling them their vendor sucks is a quite appropriate response. It has nothing to do with being defensive.
What fault of open source is it? Its very nature? Amazing that we have many vendors who do cooperate with us then.
A stable binary API has been discussed to death. It creates more work for kernel developers to maintain it, and by definition is lower performance than writing a native driver. There are people working on such a thing regardless of its potential shortcomings, but don't expect to see it in the mainline kernel unless it doesn't place an undue burden on mainline development.
First is a social goal: to give people (including the software's own developers!) a choice so that they can choose to use free software instead of proprietary software, when they cannot afford proprietary software or when the proprietary vendor exercises too much control over the user's rights.
Second is a practical goal: to convince enough people, through the merits of the software and the developers who work on it, that investing their time and money in the development of free software is worthwhile and will provide a greater return to them than paying for proprietary software.
Neither of these goals is about control, though some confused people attempt to use the foundations of free software to further their personal goals of coercion.
A further problem is that they actually take a perceptibly longer time to render each line of text.
My guess is that this is probably because of anti-aliased fonts. Are they still slow if you disable XFT through the toolkit environment variables? If so, perhaps further investigation is warranted. A terminal application with slow or erratic scrolling is extremely distracting to me.
And indeed, many aspects of the X11 protocol involve almost gratuitous round-trip queries that can make high latency a killer. Often it's aspects of the GUI toolkits that create this problem- a pretty effect that seems cool & fast on a localbox can be sluggish on the network.
The indiscretions of the GUI toolkits cannot be blamed on the X11 protocol or server design. They could create server extensions for commonly used eye-candy effects (as Xorg is doing) but instead they choose to do more work in the client, which turns network performance into sludgy crap.
Yes, they will face many of the same challenges the WINE project does, which is why WINE and ReactOS liberally share patches. Why does everyone think they are just some peripheral group reinventing the wheel for no particular reason? The ReactOS project enjoys a symbiotic reliationship with WINE in which both projects benefit from each other's advances.
You're absolutely wrong. First of all, a pure RISC processor needs a much larger instruction cache to avoid misses, because the instructions are usually fixed width to make the decoder simple, compared to variable width instructions which make the most common instructions very short. You also need more memory bandwidth to fetch the larger instructions in the first place.
Furthermore, the Pentium 4 has what they refer to as a "trace cache" which caches the already-decoded instructions - only if this cache is missed does the instruction decoder have to become involved.
You'd be hard pressed to say that instruction decoding has any significant overhead anymore in Intel processors.
Believe it or not, I know of a computer that was built in the late 70's that could multiply numbers faster than today's fastest Pentiums can.
Sure, sure, *you* know of this computer, but you'd never reveal your sources, or they have died, or whatever. A useless statement. You're also being disingenuous with your description of how fast it is. It would be impossible for a 4-bit computer to be faster than a 32-bit computer at multiplying 32-bit words. You're also ignoring the issue of clock speed. Yes, we have deep pipelines now, and your hypothetical simple machine might beat a deeply pipelined machine right as the race starts, but it'll eventually be left in the dust as the pipeline fills up.
Slashdot Mirror
Economic processes are the root cause - economic processes are what cause people to demand products which have environmental consequences. Is that bad? Not necessarily. Economic processes can also provide the solution. Since this is a tragedy of the commons scenario, it is appropriate for citizens to request that the government step in. However, radical and immediate action is a bad idea, versus a carefully prepared and executed plan to minimize our role in any global warming scenario. I don't see them advocating radical and immediate action, nor the overthrow of capitalism, do you?
Please restrain your jerking knee before you toss out a clear-headed reference in the sea of sensationalism.
He's not modded up. Registered users with good karma have a default score of 2.
I don't understand your dig about "ideological purity". Who are you addressing here? I fully support anyone's right to choose where and under what terms they use their software, in case that was unclear? You might find that people who protest others getting to enjoy open source software on operating systems they disapprove of are not actually useful contributors to any projects, but rather the type who like to go around stirring up controversy instead of improving the software.
I really like the idea of hiding implementation, but not to the extent that the application is made too dumb - having access to information about current state inside the implementation could allow the application to make better decisions regarding various aspects of its usability. This would include a X11 toolkit knowing whether it is running locally or remotely.
Hmm. Perhaps checking if DISPLAY has no hostname in it would suffice?
The i740 architecture eventually became integrated into the motherboard chipset as the i810. In-memory texturing makes a lot more sense there.
Voodoo Graphics was capable of SLI too. I have a workstation card with two Voodoo Graphics chipsets on it, made by Quantum 3D. I don't know of any consumer cards which were marketed as being SLI capable.
It will be a long time, because of the high cost of reconfigurable hardware with useful functional units. Eventually a standardized reconfigurable hardware platform complete with consumer electronics and I/O interconnects will become cheap enough for a variety of cool tasks, like the general purpose computer eventually became cheap enough for a variety of cool tasks.
You can cram your self-centered ignorance up your ass. I did not mention your EDA or VPN software, nor did I tell you to replace your Windows installation with Linux. I said that by actively ignoring Linux, you might find that in the future you realize that you missed opportunities by being narrow minded. That statement is completely orthogonal to yours.
It's sort of like using lpd to play mp3 files.
See this comment.
There is no pretense that it will take over the world, just like Windows never took over the world. However, there is little doubt that Linux will be relevant over the next decade. Nobody is requiring that anybody else use an operating system that they dislike, but I think that you may be sad that you missed out on some very tangible benefits when you look back from some future point.
What fault of open source is it? Its very nature? Amazing that we have many vendors who do cooperate with us then.
A stable binary API has been discussed to death. It creates more work for kernel developers to maintain it, and by definition is lower performance than writing a native driver. There are people working on such a thing regardless of its potential shortcomings, but don't expect to see it in the mainline kernel unless it doesn't place an undue burden on mainline development.
First is a social goal: to give people (including the software's own developers!) a choice so that they can choose to use free software instead of proprietary software, when they cannot afford proprietary software or when the proprietary vendor exercises too much control over the user's rights.
Second is a practical goal: to convince enough people, through the merits of the software and the developers who work on it, that investing their time and money in the development of free software is worthwhile and will provide a greater return to them than paying for proprietary software.
Neither of these goals is about control, though some confused people attempt to use the foundations of free software to further their personal goals of coercion.
I'm still waiting for it.
Yes, they will face many of the same challenges the WINE project does, which is why WINE and ReactOS liberally share patches. Why does everyone think they are just some peripheral group reinventing the wheel for no particular reason? The ReactOS project enjoys a symbiotic reliationship with WINE in which both projects benefit from each other's advances.
The Linux version of the Xilinx Web Pack will be available (finally) in the spring, said a Xilinx guy who I recently contacted.
Furthermore, the Pentium 4 has what they refer to as a "trace cache" which caches the already-decoded instructions - only if this cache is missed does the instruction decoder have to become involved.
You'd be hard pressed to say that instruction decoding has any significant overhead anymore in Intel processors.
...Suite!