Some time back, some studies were done to determine the ACTUAL improvement of the Dvorak keyboard over QWERTY. Although Dvorak proponents often proclaim the massive benefits of their favorite keyboard, one should take their biased statements with a grain of salt. More recent studies have shown that Dvorak is indeed more efficient (for proficient typists) than QWERTY, but not significantly so. IIRC, they compared alphabetic arrangements, Dvorak, QWERTY and perhaps a few others. Alphabetic arrangments were decidedly bad. Dvorak was very efficient. But QWERTY wasn't much less efficient than Dvorak. The reason? The primary advantage of Dvorak is that it is optimized to cause one to alternate hands for each letter typed. QWERTY is closer to random, but due to that randomness, QWERTY requires nearly as much alternation as Dvorak. Other Dvorak optimizations seem to have almost negligible effect on efficiency.
I do believe that some of the 200WPM+ claims from Dvorak proponents are true. But Dvorak proponents tend to be keyboard enthusiasts that put well above average time and effort (and probably a fair amount of natural coordination) into becoming very good typists. I believe that that same effort expended on QWERTY would yield nearly as amazing results. This reminds me of proponents of esoteric programming languages who claim that their favorite language is a major part of their ability to produce amazing code; while I'm sure that their choice of language has SOME effect, I believe it's primarily their innate intelligence that makes them amazing coders, and they would be just as amazing with mundane languages like C.
So, no. Dvorak isn't an amazing keyboard. It's just that many Dvorak users are amazing typists. How's that for a back-handed compliment?:) Either way, there doesn't seem to be much incentive to switch from QWERTY.
Anyhow, I think he's right. I haven't used the CAPS key since I programmed in FORTRAN. It's called Fortran now and accepts lower case like everything else. In fact, I didn't even use the caps key to type FORTRAN. I just held down the shift key with my little finger. So, what use is this CAPS key?
If you're not a scientist and you watch enough discovery channel, you'll quickly get the impression that scientists are never talking about theory or anything the least bit uncertain or falsifiable. Everything is presented as fact. If you believe what they say, then you'll believe that Evolutionary Theory is actually proven fact.
Let's not confuse this with another thing called Evolutionary Fact, which are the aspects of evolution that we know are true, because we have observed them directly. Rather, I'm talking about things for which we have a preponderance of evidence, but for which we cannot directly observe, because they happened too far in the past.
I believe scientists are frequently careless with their words.
Consider, for instance, some recent discoveries about therapods. A number of recent discoveries shed light on the development of feathers in relatives of the T-rex and ancestors to modern birds. The scientists on the TV weave a fanciful tail about how things "were", drawing huge numbers of new conclusions from small shreds of evidence presented. I'm sure there's more to their research than what was crammed into an hour-long show. The funny part is that the things they're presenting as FACT now directly contradict the FACTS presented only a year earlier on the same channel. To the scientist, obviously what we mean is that these are the facts as we know them based on the evidence. But that's not what they're TELLING people. They're just saying what they know and presenting it as incontrovertable fact.
(1) I don't want to buy a 32-bit processor. Yes, I know that 32-bit is good enough for a long time now. But 64-bit is just what I want. It'll make me feel better.
(2) First-release Mac products are often rife with problems. The first-release aren't out yet. So I'm going to end up waiting at least 6 months for Apple to get most of the bugs worked out of the hardware.
Once that's all taken care of, I'll be getting a light Mac notebook.
As you know, automatic multi-threading is an unsolved problem. Your multi-stack VLIW idea is very interesting, but even that would be damn difficult for a compiler to take advantage of.
I'm a chip designer, and I am working on my Ph.D. in CS. The idea of stack machines is something I have researched a bit, and I have drawn some of my own conclusions.
The main advantage of stack machines is that all or most parameters for each instruction are implicit. Aside from stack shuffle/rotate instructions, the operands are always the top few on the stack. This makes instructions very small. The logic is also exceedingly simple (for fixed-stack designs). If you want a simple, low-power CPU, a stack machine is what you want.
Where I explored this issue, however, is in the realm of high-performance computing. The key advantage of a stack architecture is that smaller instructions take less time to fetch from memory. If your RISC instructions are 32 bits, but your stack machine instructions are 8 bits, then your instruction caches are effectively 4x larger, and your over-all cache miss penalty is greatly reduced.
The problem with stack machines is that they're damn near impossible to add instruction-level parallelism to. With a RISC machine, near-by instructions that deal with different registers (i.e. no dependencies) can be executed in parallel (whether that's multi-issue or just pipelining). With a stack machine, everything wants to read/write the top of the stack.
I came up with two things to deal with this problem, that are very much like the CISC-to-RISC translation done by modern x86 processors, so it's more of a stack ISA on a RISC architecture. One is that the stack is virtual. When you want to pop from the stack, what's happening in the front-end of the CPU is that you're just popping register numbers corresponding to a flat register file. When you want to push, you're allocating an assigned register number from the flat register file. Now, if you can get two instructions going that read different parts of the stack and write (naturally) to different locations, you can parallelize them. The second part is a healthy set of register shuffling instructions. Since you're doing all of this allocation up front, shuffling registers is as simple as renumbering things in your virtual stack. So a swap operation swaps two register numbers (rather than their contents), and a rotate operation renumbers a bunch of them, but the pending instructions being executed still dump their results in the same physical registers.
This all sounds great, but there are some problems with this:
(1) The shuffling instructions are separate instructions. With a RISC processor, you have more information all in one unit. Although you could try to fetch and execute multiple stack instructions at once, it's much more complicated to execute four stack instructions in parallel than to execute a single RISC instruction, even though they require the same amount of memory. (2) You need a lot of shuffling instructions. Say your stack contains values A, B, C, and D, and you want to sum them. Without shuffling, you'd add A and B, yielding E, then add E and C, yielding F, then add F and D. Three add instructions. If your adder(s) is/are pipelined, you'd like to add A+B and C+D in parallel or overlapping, THEN wait around for their results and do the third add. The problem is that to do that, you'd need to add A+B, then rotate C to the top then D to the top, then add, then add again. The first case was 3 instructions; the second case is 5 instructions. Depending on your architecture, the extra shuffle instructions may take so long to process that you might as well just have waited. No speed gain at all. (3) The extra shuffing instructions take up space. Optimizers are hard to write. Although it's conceivable that one could optimize for this architecture so as to avoid as many shuffling instructions as possible, you still end up taking up quite a lot of space with them, potentially offsetting much of the space savings that you got from switching from RISC to stack.
So, there you have it. Somewhat OT, because surely NASA's primary goal has got to be low-power, but also somewhat on-topic because stack architectures aren't the holy grail. Just ideal for some limited applications.
Let's just say, for sake of argument, that the children were being as destructive as the police suggest. (I mean, parents have a tendency so spin the actions of their kids in too rosy of a light.) Let's even go so far as to entertain the idea that they were intentionally destroying the tree with no good purpose.
The only possible situation where the police actions would be warranted is if those kids KNEW that this tree was protected public property (like destroying cypress trees in Florida AFTER being told that it's illegal to damage them) and were intentionally vandalizing it just to be assholes to everyone else.
The problem is that that would be impossible for the police to prove. Nevertheless, the police acted as though the intentions of these kids were the worst possible. The police don't have that right, and they should be brought up on civil charges.
I imagine that IMing with an alternative grammar is no worse than dealing with more than one language on a daily basis. There are many places in the world where people grow up with fluency in more than one language, and they handle each one expertly. In fact, it's been suggested that knowing multiple languages may enhance one's other cognitive abilities. That fact that IM language is a derivative of their native language is probably not hurting the people using it. It may be helping them.
Basically, you're asking for the software interface of the hardware to be standardized and abstracted. In a nut shell, hardware is expensive and software is cheap. Anything you can do in software with little or no impact on your performance requirements is something you should not do in hardware. ATI and nVidia have radically different approaches to GPU design. With differing internal structures, the interfaces exposed to drivers is also going to be radically different, but there's no reason not to use cheap CPU cycles to create the abstraction rather than expensive logic gates in hardware.
Hardware is expensive because the cost of a chip goes up roughtly with the fourth power of the logic area.
IMHO, the best solution to the problem of drivers for Linux is simply to not buy hardware that doesn't have open source drivers. Do you think that makes life difficult? The Open Graphics Project has opinions about that.
As the article CLEARLY states, the development board is at least $1000, and the graphics card will be at most $200. (Actually it just said $1000 and $200, but I have inside information.)
The OGP's goal is to release USABLE 3D for 3D desktop support. It won't be YEARS for that. Most Linux users just want the 3D features supported for relatively basic stuff, like 3D desktops with transparent windows and the like. Not games. This sort of thing is WELL within the capacity of the OGP in the short term.
Besides, the long term goal of the OGP is to have open hardware. Wouldn't you like that? Don't kill them based on their short-term goals. Think about the future, lest you never end up with open hardware.
Well, unfortunately, ATI doesn't see it that way. Their profit margins are razor thin. They're not about to sink more than token effort into supporting a minority user base. They would make negative profit. To them, if you want to use their products, you can use them the way they're intended. Otherwise, buy something else. The fact that something else doesn't exist is not their probem. This is a business we're talking about, and in business, profit is the top concern. If you want to do humanitarian work, you start a non-profit. If you want to make profit, you start a business. That's why we have terms like "business" and "non-profit" to describe these kinds of entities. For the most part, don't expect non-business things to come out of businesses. (There are exceptions, but ATI isn't one of them.)
One thing that pisses me off is that so many people keep bitching about lack of proper open source drivers, but they don't actually try to DO anything about it. If you don't have the technical expertise, then how about financial support or donating resources for the various efforts trying to correct the problem? Either you work to reverse-engineer current products (or support the reverse engineers financially), or you get hooked up with the Open Graphics Project and help fix the problem once and for all.
The Open Graphics Project comes up pretty high in google searches. When someone writes an article like this, it tells me that they didn't even TRY to do their homework. From reading the article (yeah, I read it!), it would appear that the author isn't seriously looking for alternatives. It's reasonable enough to evaluate ATI and nVidia drivers. What's unreasonable is to make everything totally one-sided by not mentioning the alternatives.
This is why I couldn't stomach web programming!
on
Dvorak Rants on CSS
·
· Score: 5, Interesting
I've been writing code since I was 5 when my dad taught me Fortran. As a pre-teen, I learned BASIC. In high school, I learned C and Pascal. In college, I learned LISP, Ada, and C++. My "favorite" language right now, simply because I am having more fun with chip design, is Verilog. Suffice it to say that I have a lot of experience with programming and programming languages and quite radically different ways of thinking about encoding algorithms (software and hardware design are very different from each other).
Coding web pages makes me violently ill.
Back in 2003, I decided to learn web programming. In the process, I learned to hand-code HTML, CSS, Javascript, Java, SQL, and PHP. PHP, I can handle, because it's simple and straight-forward and designed to make back-end writing easy (although I understand that there have been some developments with Ruby since then). SQL makes sense, since it's specialized for database manipulation.
But when it comes to developing front-end web content, I just cannot justify using three different languages for one thing. I mean, I do understand the idea behind specializing languages (PHP vs. SQL), so in the abstract, I see a reason for making a separation between structure/content (HTML) and formatting (CSS). I just have a visceral reaction to having to use two different languages with two different syntaxes at once in this context. Embedding SQL in PHP doesn't bother me. For some reason, CSS and HTML bother me. I think it's because I feel like they're haphazzardly slapped together and FORCED to get along. PHP and SQL have no relation. Each is designed for its function. HTML evolved from a structural markup language into a total mess, and then CSS was invented as a bandaid. Along the way, no one ever thought to actually unify them. And then there's Javascript.
CSS, HTML, Javascript, and Java each has its own different name for each kind of DOM object. WTF!
If you want to do the full gamut of web front-end programming, you have to learn four names for every object or attribute!
What were these people thinking?
They weren't.
And it's never going to get better. 100 years from now, web programming will be tainted by the legacy evolutionary path everything went through.
Just wait for the Semantic Web. Yet another syntax to learn. No unification AT ALL.
They say that the number two job in the US is Software Engineer, but I was already that. The number one job is College Professor, so the only way to move up was to get a Ph.D.:)
An implosion in one tab should only take out that tab (or worst-case that window).
If you use threads, an implosion in one tab (thread) will still crash the whole process. Worse yet, runaway pointers will corrupt the address space of other threads, corrupting them and making them crash in places unrelated to the bug. As I said, the solution is to run each document in a separate PROCESS. The context switch overhead in Linux is the same, but now every document is protected, and one crash will not take down the whole browser.
Actually, I'm not opposed to all these nice new features they've added, although it might be nice to have some optional for smaller systems. Also, I am aware that Firefox developers fix bugs all the time. They're just not going after the REALLY BIG ones.
My biggest beef with Firefox is that it still crashes frequently and has massive memory leaks that require me to quit and restart the browser on a daily basis. It doesn't take much to get Firefox to grow to 1GB in memory footprint and start causing my system to thrash. A fundamental flaw is that it does not release memory back to the OS, so when you close tabs and windows, the process doesn't shrink. While this isn't directly Firefox's fault, there are lots of ways around this that they refuse to implement. On the other hand, the true memory leaks ARE their fault.
I once suggested a solution to their problems. The basic philosophy is that they want to fix the crashes. But at this rate, they never will, so it's better to find ways to limit the damage done by crashes. The best solution, IMHO, is to stop using threads. Instead, fork a separate process for each document and one more for the UI, and use IPC for them to communicate. This way, when a web page or plugin inevitably causes the browser to crash or even just grow too big, killing that one window or tab won't bring down the whole browser, and the memory it used will be returned to the OS. This will have the side-effect of making the browser much more responsive, because you're not kept from switching tabs while a DNS lookup hangs the browser for one document. Naturally, they didn't like my solution.
I think stability isn't really all that important to them, at least not proactively; if you're just reactive to bugs, you're never going to get a solid product.
Is it just me, or does it seem rather unkind to go about declaring, "Look at me! I just conducted a cyber-attack against China!" Hey, I'm no fan of China's government or censorship, and I am aware that China have tried to attack other countries' computers, but two wrongs don't make a right. Unless we're doing something defensive to ward off an attack from China, I see little point in taunting them and giving them reason to tighten security even further. It just doesn't seem right.
The biggest problem for the FOSS community is not that we haven't spread OOo enough. The biggest problem is hardware vendors that won't release documentation we need to develop open source drivers! If you're going to donate money, why not donate to the people who are working on developing hardware specifically for the FOSS community? (You know who they are.)
The OGP is being lead by three hardware designers who anticipate doing most of the hardware design themselves, although they are teaching Verilog on the OGP mailing list.
No, I don't mean merely fully-documented hardware. I mean hardware whose wiring diagrams and/or hardware description language is available under a Free Software license. There's a group doing this. They're called the Open Graphics Project, and they've got real hardware that's going to go on sale at the end of the summer. Most hardware vendors are very resistant to publishing documentation, and they only grudgingly release it after much begging. The OGP is dedicated to designing hardware with Free Software in mind. No more begging, because now you have more documentation than you need!
If you're interested in having open hardware or even just hardware that's designed for FOSS users, with drivers that will be Free Software, stable, and fixable, then you should support the OGP. See them at http://www.opengraphics.com!
This article is all fluff. They don't say anything really interesting. Ok, they can communicate. If that's so, then engineers can record it and perform analysis on the lexicon and gramatical structure. I want to know something about that! I'm sure it won't match up well to human language, but that's okay, because human languages are themselves very diverse in the way things are represented. Would it kill them to give a few examples of 'words' (even if they're described in terms of musical notes or whatever), what they mean, and how they go together to form sentences?
Slashdot Mirror
Some time back, some studies were done to determine the ACTUAL improvement of the Dvorak keyboard over QWERTY. Although Dvorak proponents often proclaim the massive benefits of their favorite keyboard, one should take their biased statements with a grain of salt. More recent studies have shown that Dvorak is indeed more efficient (for proficient typists) than QWERTY, but not significantly so. IIRC, they compared alphabetic arrangements, Dvorak, QWERTY and perhaps a few others. Alphabetic arrangments were decidedly bad. Dvorak was very efficient. But QWERTY wasn't much less efficient than Dvorak. The reason? The primary advantage of Dvorak is that it is optimized to cause one to alternate hands for each letter typed. QWERTY is closer to random, but due to that randomness, QWERTY requires nearly as much alternation as Dvorak. Other Dvorak optimizations seem to have almost negligible effect on efficiency.
:) Either way, there doesn't seem to be much incentive to switch from QWERTY.
I do believe that some of the 200WPM+ claims from Dvorak proponents are true. But Dvorak proponents tend to be keyboard enthusiasts that put well above average time and effort (and probably a fair amount of natural coordination) into becoming very good typists. I believe that that same effort expended on QWERTY would yield nearly as amazing results. This reminds me of proponents of esoteric programming languages who claim that their favorite language is a major part of their ability to produce amazing code; while I'm sure that their choice of language has SOME effect, I believe it's primarily their innate intelligence that makes them amazing coders, and they would be just as amazing with mundane languages like C.
So, no. Dvorak isn't an amazing keyboard. It's just that many Dvorak users are amazing typists. How's that for a back-handed compliment?
I can't believe it.
Anyhow, I think he's right. I haven't used the CAPS key since I programmed in FORTRAN. It's called Fortran now and accepts lower case like everything else. In fact, I didn't even use the caps key to type FORTRAN. I just held down the shift key with my little finger. So, what use is this CAPS key?
If you're not a scientist and you watch enough discovery channel, you'll quickly get the impression that scientists are never talking about theory or anything the least bit uncertain or falsifiable. Everything is presented as fact. If you believe what they say, then you'll believe that Evolutionary Theory is actually proven fact.
Let's not confuse this with another thing called Evolutionary Fact, which are the aspects of evolution that we know are true, because we have observed them directly. Rather, I'm talking about things for which we have a preponderance of evidence, but for which we cannot directly observe, because they happened too far in the past.
I believe scientists are frequently careless with their words.
Consider, for instance, some recent discoveries about therapods. A number of recent discoveries shed light on the development of feathers in relatives of the T-rex and ancestors to modern birds. The scientists on the TV weave a fanciful tail about how things "were", drawing huge numbers of new conclusions from small shreds of evidence presented. I'm sure there's more to their research than what was crammed into an hour-long show. The funny part is that the things they're presenting as FACT now directly contradict the FACTS presented only a year earlier on the same channel. To the scientist, obviously what we mean is that these are the facts as we know them based on the evidence. But that's not what they're TELLING people. They're just saying what they know and presenting it as incontrovertable fact.
Two problems:
(1) I don't want to buy a 32-bit processor. Yes, I know that 32-bit is good enough for a long time now. But 64-bit is just what I want. It'll make me feel better.
(2) First-release Mac products are often rife with problems. The first-release aren't out yet. So I'm going to end up waiting at least 6 months for Apple to get most of the bugs worked out of the hardware.
Once that's all taken care of, I'll be getting a light Mac notebook.
As you know, automatic multi-threading is an unsolved problem. Your multi-stack VLIW idea is very interesting, but even that would be damn difficult for a compiler to take advantage of.
I'm a chip designer, and I am working on my Ph.D. in CS. The idea of stack machines is something I have researched a bit, and I have drawn some of my own conclusions.
The main advantage of stack machines is that all or most parameters for each instruction are implicit. Aside from stack shuffle/rotate instructions, the operands are always the top few on the stack. This makes instructions very small. The logic is also exceedingly simple (for fixed-stack designs). If you want a simple, low-power CPU, a stack machine is what you want.
Where I explored this issue, however, is in the realm of high-performance computing. The key advantage of a stack architecture is that smaller instructions take less time to fetch from memory. If your RISC instructions are 32 bits, but your stack machine instructions are 8 bits, then your instruction caches are effectively 4x larger, and your over-all cache miss penalty is greatly reduced.
The problem with stack machines is that they're damn near impossible to add instruction-level parallelism to. With a RISC machine, near-by instructions that deal with different registers (i.e. no dependencies) can be executed in parallel (whether that's multi-issue or just pipelining). With a stack machine, everything wants to read/write the top of the stack.
I came up with two things to deal with this problem, that are very much like the CISC-to-RISC translation done by modern x86 processors, so it's more of a stack ISA on a RISC architecture. One is that the stack is virtual. When you want to pop from the stack, what's happening in the front-end of the CPU is that you're just popping register numbers corresponding to a flat register file. When you want to push, you're allocating an assigned register number from the flat register file. Now, if you can get two instructions going that read different parts of the stack and write (naturally) to different locations, you can parallelize them. The second part is a healthy set of register shuffling instructions. Since you're doing all of this allocation up front, shuffling registers is as simple as renumbering things in your virtual stack. So a swap operation swaps two register numbers (rather than their contents), and a rotate operation renumbers a bunch of them, but the pending instructions being executed still dump their results in the same physical registers.
This all sounds great, but there are some problems with this:
(1) The shuffling instructions are separate instructions. With a RISC processor, you have more information all in one unit. Although you could try to fetch and execute multiple stack instructions at once, it's much more complicated to execute four stack instructions in parallel than to execute a single RISC instruction, even though they require the same amount of memory.
(2) You need a lot of shuffling instructions. Say your stack contains values A, B, C, and D, and you want to sum them. Without shuffling, you'd add A and B, yielding E, then add E and C, yielding F, then add F and D. Three add instructions. If your adder(s) is/are pipelined, you'd like to add A+B and C+D in parallel or overlapping, THEN wait around for their results and do the third add. The problem is that to do that, you'd need to add A+B, then rotate C to the top then D to the top, then add, then add again. The first case was 3 instructions; the second case is 5 instructions. Depending on your architecture, the extra shuffle instructions may take so long to process that you might as well just have waited. No speed gain at all.
(3) The extra shuffing instructions take up space. Optimizers are hard to write. Although it's conceivable that one could optimize for this architecture so as to avoid as many shuffling instructions as possible, you still end up taking up quite a lot of space with them, potentially offsetting much of the space savings that you got from switching from RISC to stack.
So, there you have it. Somewhat OT, because surely NASA's primary goal has got to be low-power, but also somewhat on-topic because stack architectures aren't the holy grail. Just ideal for some limited applications.
Let's just say, for sake of argument, that the children were being as destructive as the police suggest. (I mean, parents have a tendency so spin the actions of their kids in too rosy of a light.) Let's even go so far as to entertain the idea that they were intentionally destroying the tree with no good purpose.
The only possible situation where the police actions would be warranted is if those kids KNEW that this tree was protected public property (like destroying cypress trees in Florida AFTER being told that it's illegal to damage them) and were intentionally vandalizing it just to be assholes to everyone else.
The problem is that that would be impossible for the police to prove. Nevertheless, the police acted as though the intentions of these kids were the worst possible. The police don't have that right, and they should be brought up on civil charges.
I imagine that IMing with an alternative grammar is no worse than dealing with more than one language on a daily basis. There are many places in the world where people grow up with fluency in more than one language, and they handle each one expertly. In fact, it's been suggested that knowing multiple languages may enhance one's other cognitive abilities. That fact that IM language is a derivative of their native language is probably not hurting the people using it. It may be helping them.
Basically, you're asking for the software interface of the hardware to be standardized and abstracted. In a nut shell, hardware is expensive and software is cheap. Anything you can do in software with little or no impact on your performance requirements is something you should not do in hardware. ATI and nVidia have radically different approaches to GPU design. With differing internal structures, the interfaces exposed to drivers is also going to be radically different, but there's no reason not to use cheap CPU cycles to create the abstraction rather than expensive logic gates in hardware.
Hardware is expensive because the cost of a chip goes up roughtly with the fourth power of the logic area.
IMHO, the best solution to the problem of drivers for Linux is simply to not buy hardware that doesn't have open source drivers. Do you think that makes life difficult? The Open Graphics Project has opinions about that.
As the article CLEARLY states, the development board is at least $1000, and the graphics card will be at most $200. (Actually it just said $1000 and $200, but I have inside information.)
I'm perfectly well aware of Matrox's support for open source, which is incomplete.
You didn't do much looking into this if you think they're trying to sell a $1000 graphics card.
The OGP's goal is to release USABLE 3D for 3D desktop support. It won't be YEARS for that. Most Linux users just want the 3D features supported for relatively basic stuff, like 3D desktops with transparent windows and the like. Not games. This sort of thing is WELL within the capacity of the OGP in the short term.
Besides, the long term goal of the OGP is to have open hardware. Wouldn't you like that? Don't kill them based on their short-term goals. Think about the future, lest you never end up with open hardware.
Well, unfortunately, ATI doesn't see it that way. Their profit margins are razor thin. They're not about to sink more than token effort into supporting a minority user base. They would make negative profit. To them, if you want to use their products, you can use them the way they're intended. Otherwise, buy something else. The fact that something else doesn't exist is not their probem. This is a business we're talking about, and in business, profit is the top concern. If you want to do humanitarian work, you start a non-profit. If you want to make profit, you start a business. That's why we have terms like "business" and "non-profit" to describe these kinds of entities. For the most part, don't expect non-business things to come out of businesses. (There are exceptions, but ATI isn't one of them.)
The Open Graphics Project comes up pretty high in google searches. When someone writes an article like this, it tells me that they didn't even TRY to do their homework. From reading the article (yeah, I read it!), it would appear that the author isn't seriously looking for alternatives. It's reasonable enough to evaluate ATI and nVidia drivers. What's unreasonable is to make everything totally one-sided by not mentioning the alternatives.
I've been writing code since I was 5 when my dad taught me Fortran. As a pre-teen, I learned BASIC. In high school, I learned C and Pascal. In college, I learned LISP, Ada, and C++. My "favorite" language right now, simply because I am having more fun with chip design, is Verilog. Suffice it to say that I have a lot of experience with programming and programming languages and quite radically different ways of thinking about encoding algorithms (software and hardware design are very different from each other).
Coding web pages makes me violently ill.
Back in 2003, I decided to learn web programming. In the process, I learned to hand-code HTML, CSS, Javascript, Java, SQL, and PHP. PHP, I can handle, because it's simple and straight-forward and designed to make back-end writing easy (although I understand that there have been some developments with Ruby since then). SQL makes sense, since it's specialized for database manipulation.
But when it comes to developing front-end web content, I just cannot justify using three different languages for one thing. I mean, I do understand the idea behind specializing languages (PHP vs. SQL), so in the abstract, I see a reason for making a separation between structure/content (HTML) and formatting (CSS). I just have a visceral reaction to having to use two different languages with two different syntaxes at once in this context. Embedding SQL in PHP doesn't bother me. For some reason, CSS and HTML bother me. I think it's because I feel like they're haphazzardly slapped together and FORCED to get along. PHP and SQL have no relation. Each is designed for its function. HTML evolved from a structural markup language into a total mess, and then CSS was invented as a bandaid. Along the way, no one ever thought to actually unify them. And then there's Javascript.
CSS, HTML, Javascript, and Java each has its own different name for each kind of DOM object. WTF!
If you want to do the full gamut of web front-end programming, you have to learn four names for every object or attribute!
What were these people thinking?
They weren't.
And it's never going to get better. 100 years from now, web programming will be tainted by the legacy evolutionary path everything went through.
Just wait for the Semantic Web. Yet another syntax to learn. No unification AT ALL.
They say that the number two job in the US is Software Engineer, but I was already that. The number one job is College Professor, so the only way to move up was to get a Ph.D. :)
An implosion in one tab should only take out that tab (or worst-case that window).
If you use threads, an implosion in one tab (thread) will still crash the whole process. Worse yet, runaway pointers will corrupt the address space of other threads, corrupting them and making them crash in places unrelated to the bug. As I said, the solution is to run each document in a separate PROCESS. The context switch overhead in Linux is the same, but now every document is protected, and one crash will not take down the whole browser.
Actually, I'm not opposed to all these nice new features they've added, although it might be nice to have some optional for smaller systems. Also, I am aware that Firefox developers fix bugs all the time. They're just not going after the REALLY BIG ones.
My biggest beef with Firefox is that it still crashes frequently and has massive memory leaks that require me to quit and restart the browser on a daily basis. It doesn't take much to get Firefox to grow to 1GB in memory footprint and start causing my system to thrash. A fundamental flaw is that it does not release memory back to the OS, so when you close tabs and windows, the process doesn't shrink. While this isn't directly Firefox's fault, there are lots of ways around this that they refuse to implement. On the other hand, the true memory leaks ARE their fault.
I once suggested a solution to their problems. The basic philosophy is that they want to fix the crashes. But at this rate, they never will, so it's better to find ways to limit the damage done by crashes. The best solution, IMHO, is to stop using threads. Instead, fork a separate process for each document and one more for the UI, and use IPC for them to communicate. This way, when a web page or plugin inevitably causes the browser to crash or even just grow too big, killing that one window or tab won't bring down the whole browser, and the memory it used will be returned to the OS. This will have the side-effect of making the browser much more responsive, because you're not kept from switching tabs while a DNS lookup hangs the browser for one document. Naturally, they didn't like my solution.
I think stability isn't really all that important to them, at least not proactively; if you're just reactive to bugs, you're never going to get a solid product.
Is it just me, or does it seem rather unkind to go about declaring, "Look at me! I just conducted a cyber-attack against China!" Hey, I'm no fan of China's government or censorship, and I am aware that China have tried to attack other countries' computers, but two wrongs don't make a right. Unless we're doing something defensive to ward off an attack from China, I see little point in taunting them and giving them reason to tighten security even further. It just doesn't seem right.
The biggest problem for the FOSS community is not that we haven't spread OOo enough. The biggest problem is hardware vendors that won't release documentation we need to develop open source drivers! If you're going to donate money, why not donate to the people who are working on developing hardware specifically for the FOSS community? (You know who they are.)
The OGP is being lead by three hardware designers who anticipate doing most of the hardware design themselves, although they are teaching Verilog on the OGP mailing list.
Sorry. Got the address wrong. The open graphics project is at www.opengraphics.ORG.
No, I don't mean merely fully-documented hardware. I mean hardware whose wiring diagrams and/or hardware description language is available under a Free Software license. There's a group doing this. They're called the Open Graphics Project, and they've got real hardware that's going to go on sale at the end of the summer. Most hardware vendors are very resistant to publishing documentation, and they only grudgingly release it after much begging. The OGP is dedicated to designing hardware with Free Software in mind. No more begging, because now you have more documentation than you need!
If you're interested in having open hardware or even just hardware that's designed for FOSS users, with drivers that will be Free Software, stable, and fixable, then you should support the OGP. See them at http://www.opengraphics.com!
This article is all fluff. They don't say anything really interesting. Ok, they can communicate. If that's so, then engineers can record it and perform analysis on the lexicon and gramatical structure. I want to know something about that! I'm sure it won't match up well to human language, but that's okay, because human languages are themselves very diverse in the way things are represented. Would it kill them to give a few examples of 'words' (even if they're described in terms of musical notes or whatever), what they mean, and how they go together to form sentences?