The 6502 might - but the 6501AQ did not. The 6501AQ was (is?) the embedded processing version of the 6502, complete with i/o ports mapped into zero page, on-board RAM (64 bytes!) and 2k EPROM
IIRC, the 1 MHz version didn't even need an external clock.
There's a fundamental flaw in your argument: no one has a right to make a profit on their work.
Scientists generally produce ideas, which can then often benefit the world. Typically they earn a salary, and do not get a royalty everytime someone (say) invokes the theory of gravitation.
Work which garners royalties is rewarded on the basis of how popular it is, not how good it is, or on how much work went in to manufacture it. Some popular entertainers earn millions per year while probably doing less public good than someone responsible for mainting a disease-free water supply to a city, who would earn considerably less.
As has been said many times before, the point of patent law is to encourage innovation, not to reward corporations - the latter is simply how the former is typically achieved.
Basicly, the implementation of intellectual property is unfair and fundamentally flawed. Throwing it out entirely
probably wouldn't work, but the current system is simply messed up.
You know, no one[1] in Australia has actually heard of Steve Irwin. He's not on our TVs, nor mentioned in the media. Probably for the best.
From the little second hand information I've seen, let me apologise on behalf of the country for this individual. There's probably a very good reason why he's over there and not over here though. One wonders if he really is Australian?
Actually UTF-16 can't represent the same range as UTF-8 or UTF-32, it's a bit weird. UTF-16 uses surrogate characters to represent the 16 UCS-4 planes 0x00010000 through 0x0010FFFF as a pair of 16-bit words.
As a preliminary, Unicode and ISO 10646 aren't the same standard, but are kept pretty much in synchronisation. ISO 10646 provides a character set with a 4-byte representation, and a compatible smaller set with a 2-byte representation. These representations have encodings such as UTF-8, UTF-16, and UTF-32. UTF-32 encodes every Unicode character in 32 bits and can represent the full 2^31 codepoints, while UTF-8 and UTF-16 as described in the Unicode 3.1 document are variable length representations that can represent approximately 2,100,000 and 1,100,000 codepoints respectively.
One of the design principles was to provide a lossless representation of any currently used character set in Unicode, so that a round-trip re-encoding of text from one encoding to Unicode and back again would lose no information. Another was to keep distinct code-points for any characters that had different semantics, or different 'abstract shapes'.
It turns out that one can satisfy these requirements for the Japanese kanji, Chinese hanzi (traditional and simplified) and Korean hanja without requiring a seperate code-point for each; in Unicode version 2.0, approximately 121,000 such characters were able to be represented in 20,902 code points. Note that those characters which have distinct shapes but the same meaning, and those which are similar enough to be classified as calligraphic variants but have distinct meanings, are all represented by distinct code-points. (One caveat: in practice there are some exceptions as regards the preservation of information after a round-trip encoding to Unicode and back. For example, the CCCII encoding of hanzi explicitly catalogues calligraphic variations, and as such doesn't map 1-1 onto Unicode.)
Of course, the actual glyph that corresponds to one of these unified codes will change depending upon the context in which it is rendered. For example the character 0x6d77 corresponding to the character for sea in both Chinese (Mandarin 'hai3') and Japanese ('umi') is drawn with one fewer stroke in Japanese than in Chinese. These typographical details are important, but can (and debatably, should) be dealt with outside the context of character encoding. Unicode has support for language tags which in the absence of any higher-level information can indicate the language context of the characters following them. Typically though, this information should be stored as part of a richer document structure (as is possible in XML for example.) Correct display of characters will require the presence of the appropriate font and a mechanism (such as LOCALE in a simple one language case) for selecting this font.
Given this unification then, one really can fit most of the characters for which there already extant (non-Unicode) encodings into 16 bits. With Unicode 3.1/ISO 10646-2 (which uses more than 65536 codepoints) this representation is AFAIK pretty much complete, including for example all of the hanzi of CNS 11643-1992 and CNS 11643-1986 plane 15 (the most complete hanzi encoding outside of CCCII.)
With this in mind, one can argue against the points raised in the article:
The unification scheme, allows the representation of the 170,000 characters the author calculates in 70,000 or so codepoints. Which it now does with Unicode 3.1. The use of external context is still necessary for correct rendering, but if the document has no structure for representing language context, there are Unicode language tags that can fill this role. Similarly, context would be required for the presentation of different calligraphic variants of Roman characters (e.g. fraktur.)
Unification is quite unlike the analogy described 'in Western Terms'. 'M' and 'N' could not be identified, as they semanticly distinguish words (e.g., 'rum' and 'run' have very different meanings.) Traditional characters and their simplified analogues are not identified under Unicode, so even if 'Q' were simply a fancier 'C' (which of course it is not), it wouldn't be given the same codepoint.
Unicode is not limited to 16 bits as stated in the introduction to the article. There are over 2000 million available codepoints in UCS-4 and UTF-8, and UTF-16 can represent approximately 1 million of these. There is plenty of room - even in UTF-16 - to encode more characters as the need arises.
With the exception of calligraphic variants in CCCII, Unicode can already faithfully represent characters in the major Chinese, Japanese and Korean character encoding standards.
A little bit of research by the article author would have made the article unnecessary.
References: Unicode 3.1 document; CJKV Information Processing, Ken Lunde.
PS: In the time it took me to read the article, do some research and write this response, there have been over 300 slashdot comments. Wow.
Kudos of course to all those who have put the hard work in to make this release possible, but from a developer's point of view, coding for Gnome/GTK can still be a frustrating experience.
The underlying problems seem to be poor documentation and an unwillingness to make incremental updates. In particular:
Missing functionality: the GnomeCanvasLine smooth attribute doesn't smooth. The only documentation to indicate this:
gnome-libs-1.2.13/libgnomeui/gnome-canvas-line.c:1 192/* Handle smoothed lines by generating an expanded set ot points */
if (line->smooth && (line->num_points > 2)) {/* FIXME */
} else {
C++ bindings with incomplete or missing documentation.
C++ bindings with inconsistent memory management policies.
Widget functionality (multiple file selection is the best example) that has been debated literally for years, but has not ever actually been incorporated into a GTK release. Much wheel reinvention ensues.
Basic functionality missing from core libraries, let alone documentation. There are no docs for libart for example, which makes the complete lack of support for rendering to RGBA image buffers that much more suprising.
Much ad hocery - I shudder to think how much would break in the move to support other pixmap formats than RGB and RGBA 8-bit per channel.
Inconsistent interfaces - both in the C++ bindings and in the underlying C. Sometimes RGBA is 4 channels, sometimes it is 3 with the has_alpha flag set. Sometimes alpha is regarded as 8-bit, sometimes as 1-bit. Some container widgets in GTK-- support STL style mechanisms, some don't.
I'm sure these will in time be fixed. Some of these issues can only be addressed by structual changes in the code, making it inaccessible to the external developer without heaps of free time on their hands. The very infrequent development releases of GTK only compound it. When these issues are brought up on the mailing list, they are often ignored or dismissed. For all I know, lurking somewhere in CVS is complete documentation and a perfectly consistent sane and functional package - but if so, it's well hidden.
Things have improved a little on the solar front since, and further, if one really wanted to have a locally-solar powered vehicle, one would use the generating capacity of one's home to produce a portable form of energy (e.g. hydrogen) to fuel the car.
Doing the calculations though, is pretty grim:
In California, 20 square metres of area gathers on average roughly 110 kW hours of engery in a day.
The top theoretical efficiency for solar cells is about 88%. Current best in a commerical product is about 25%.
Best efficiency for producing hydrogen from water using electricity is about 70%. Best effeciency for a fuel cell in a vehicle is about 60%.
So, using best available technology, using a solar -> electricity -> hydrogen -> fuel cell path, we get about 10kW hours of energy per day from one house. This will drive an efficient crusing vehicle (stretching here, and claiming 10kW power consumption) for one hour.
With processes closer to the maximum theoretical efficiencies, and perhaps utilizing some more direct solar->hydrogen processes, one could possibly extract up to 5 hours worth of vehicle driving per household, foregoing any other sort of energy consumption.
Clearly, this isn't feasible, at least with that sort of energy consumption for a vehicle. With that consumption, it's basicly impossible to power a car with an energy source which is both renewable and local. The options are:
Non-local sources: there are great tracts of very sunny land that can be used to produce hydrogen.
Non-renewable but `nice' power generation: for example one can speculate that fusion energy will one day be both viable and cheap.
Find another solution to the transport problem: there are many negatives to spending 2 hours per day in traffic, energy waste is just one of them.
As far as I can tell, the only shortish term solution is the third. If we want to use energy sustainably, we have to rework our transport systems in a major way. At the moment, we're chewing up thousands of years of stored solar power in the form of fossil fuels.
On the bright side, 10kW hours of energy per household per day is quite nice, if we didn't have to worry about this whole transportation problem. It demonstrates that currently available solar and hydrogen technology is on the verge of being able to locally supply well in excess of all of our domestic energy needs, for those in the sunnier parts of the world.
I do remember one particular item featured on Beyond 2000's precursor show, 'Towards 2000'.
You may have seen them around - small disc thingies made of plastic with lots of tiny holes in them. Store music on them, and read it off with a laser. All very fancy. I think Phillips had something to do with it.
Also, I don't doubt that these lasers would cause increased ionization of atmospheric oxygen, leading to even further breakdowns in the ozone layer, as well as a host of physiological problems for all higher life-forms.
Given the choice, why on Earth would they pick a laser frequency to which the atmosphere wasn't nigh transparent? The whole point is to minimise signal loss. I'd be more worried about your microwave oven.
Have a passion and a critical developer's eye for games, in particular computer games!
A demo or small game demonstrates your ability to code, design and project manage.
(new point) Depending on the position, a strong mathematical or physics background helps: it's one thing to be able to code, another to be able to think logically about complex objects. A discipline like physics has direct application in physics modelling (of course) but the skills required to do science research apply well to the problems of code testing and debugging. Mathematics, similarly, is required for the more abstract computational geometry, but also provides methods for thinking rationally in general.
It really is a matter of being able to work 50 to 100 hours a week for weeks on end. It's not right, but it's the way most of the industry operates:/
I was fortunately able to join a games company as a programmer without previous games experience, or even a demo - but this is pretty uncommon. In my case, I was able to leverage ten years of other programming experience (network code, embedded controllers, etc.) and a strong maths background. At the other extreme, our best programmer had no formal IT experience and was basicly straight out of high school; what brought him to the interview stage was his demo.
Also, it sounds a bit mercenary, but the best time to join a company might be after they've just shipped their first game and are looking to expand. Chances are they won't have the funds to be too fussy about game industry experience, but will be desperate to get some new people in to support their next more ambitious project and to replace the 20% of people who left after the stress of the first project.
Coding real-time games to run over a 30kbit/sec connection is highly non-trivial. I'm speaking from experience (networking code for a car racing game: over modem, 8 to 12 players peer-to-peer networking).
If you update (say) 5 times a second, that's 200ms latency straight away, and you've already sucked up 10% of your bandwidth in packet headers. More in a peer-peer scenario! Then of course, you need to send each parameter in each object's config space in that update.
To minimise bandwidth wastage, you'd go client-server. But that effectively doubles the latency, and 400ms latency just from the networking is hard to compensate for. I won't go into all the ugly details - there are better discussions already online than that which I could write at 2am local time:) - but if you do the maths, you'll find it's not so easy after all.
I have to take issue with only one point: Diablo II networking is anything but good. The game makes little or no effort to accomodate pings higher than 300ms (modem + latency to game servers.) Many of the skills, spells etc. are dramatically less effective in these conditions. Teleporting monsters, freezes, etc. are not uncommon.
The sad thing is that network play over a LAN in Diablo II is little better, and sometimes worse! Great game, great gameplay, really really sucky network code.
Even a real-time strategy game can place high demands on bandwidth, when you only have a 30kbit/sec downstream pipe. Consider a four-player game: if unit-visibility is updated five times a second, and all the players have 100 roaming units, then before tricks are employed, that's 1500 unit position updates per second. With two-bytes per unit position, that's half the bandwidth used up already before compression, and that's just position information!
So RTS games require fancy bandwidth-saving tricks too. It's not trivial.
As other posters have pointed out as well, there is also the issue of latency. Two modems between you and your opponent can mean 300ms worth of 'free fire' on a unit (depending on game design.) This can certainly affect game-play!
But as the editorial rightly pointed out - modems aren't going away anytime soon. ADSL, cable, etc. is available to only a small percentage of game players/purchasers, and it's an affordable option for even fewer. Then, with both the Internet and the online-games market being global, the issue of latency isn't about to vanish either; It's hard to avoid 150ms of latency crossing the Pacific.
One thing that has really irked me in previous releases of GNOME, is that all the components and gnome-aware programs needed to be installed in the same directory for them to interoperate properly.
If one wants to maintain different versions of applications simultaneously, this is a royal pain in the neck. It's also irksome, in that it makes management of software through use of different application directories more awkward (forcing install directory != run directory, and a forest of symlinks.)
Does GNOME 1.4 finally address this issue, with some sort of search path mechanism? Does KDE suffer from similar issues? (Yes, this is something that aggravates me enough, that it could entice me to switch my desktop preference!)
Apple is no saint, but if anyone made the computer an acessible device, it was they, not Microsoft. Don't buy their hype. Windows and MS Office is ubiquitous now because of their abuses of the industry which led to their monopoly position; they didn't get that position by having superior software at the time.
Well, car's are dangerous things. That's why there is an extensive system of licenses and tests in most countries. If people just did whatever they liked on the road in a car, there would be mayhem. You wouldn't know what to expect.
A webpage is not a car. It's (typically) not nearly as dangerous. But one can make analogies. Knowing the difference between text and markup is as fundamental a part of contributing to the web as knowing the difference between the clutch and the accelerator when driving.
It's not too much to expect that drivers have a basic literacy as regards road rules, signs and the various control mechanisms of a car. Similarly, basic HTML, the language of the web, should be at least familiar to those who produce web content. Just as a working knowledge of car mechanics is only rarely useful in the everyday context of driving, the knowledge of HTTP and Apache configuration is not something one would expect every web author to have. I do believe your argument in fact better supports my own point.
The US Government would not have had to step in and make this sort of thing mandatory, had it been done properly to begin with.
Sometimes just letting people do their own thing simply doesn't work out so hot. This is why there are building codes, mandatory drug trials, etc.
When `the Market' fails, the Government should step in. That's one of the reasons why you have one. So stop bitching.
Let me get this straight... people can't learn to type <b> and </b>?
I'm flabbergasted. This is not rocket science.
I was going to make some snide remark about users drooling in their keyboards, but I'm sure those poor people who might desire to contribute to Slashdot but are cursed with a lack of motor control would not only be able to grasp the concept of marked text but would infintely prefer a scheme such with tags to some system requiring fine control of a mouse or pointer.
Call me elitist, but some fundamental level of web literacy is not too much to ask of people who are themselves contributing to the web.
When will you people learn, that the look and feel of a site
Is just as important as it's content?
This is just wrong.
If look and feel is just as important to you, the provider of the information, then the WWW with HTML is not for you. You want a flash presentation or a PDF.
HTML is rendered on multiple platforms, on different media, for people with different requirements. There is simply no way one can ensure that the look and feel of a site is preserved. None. Not only that, but the attempts by authors to make them so generally result in making the content itself inaccessible to between 5% and 20% of readers. This is obviously screwy.
I'm sure there are some applications for which the exact presentation of content is a crucial component of the content itself. I can't recall the last time I came across such a web page though. While there are thousands (millions?) which do sacrifice accessibility and usability on the altar of `user experience'.
If you need exact presentation, use flash and PDF. If you actually have anything important to say, use HTML and live with the fact that it won't look (or sound, or print) the same to every reader. Just cope.
There are more important things than the Internet, sure. Like food. But information access is still more than just a luxury.
In many places poverty is the result of a power differential. (In many others of course it can be the result of natural disasters, but bear with me!) One of the tools which allows power structures to remain entrenched is control over information. Free access to unfiltered information won't be a panacea, but it can certainly help to curb the worst abuses of power. When people can communicate quickly and anonymously, abuses can be addressed earlier and more effectively.
Most people seem to have a sense of justice. So when the message can get out, the population at large can effect change. There would have been no outrage at Nike for its explotive practices had no news of them ever come to light.
Of course information by itself is insufficient - there has to be a critical reader at the receiving end. Here again, the Internet can provide educational resources where there would otherwise be none, or very carefully controlled selection. The control of the 'net by advertising interests will see such applications marginalised or controlled.
Slashdot Mirror
The 6502 might - but the 6501AQ did not. The 6501AQ was (is?) the embedded processing version of the 6502, complete with i/o ports mapped into zero page, on-board RAM (64 bytes!) and 2k EPROM
IIRC, the 1 MHz version didn't even need an external clock.
It was fun to code for, if a bit tight :)
There's a fundamental flaw in your argument: no one has a right to make a profit on their work.
Scientists generally produce ideas, which can then often benefit the world. Typically they earn a salary, and do not get a royalty everytime someone (say) invokes the theory of gravitation.
Work which garners royalties is rewarded on the basis of how popular it is, not how good it is, or on how much work went in to manufacture it. Some popular entertainers earn millions per year while probably doing less public good than someone responsible for mainting a disease-free water supply to a city, who would earn considerably less.
As has been said many times before, the point of patent law is to encourage innovation, not to reward corporations - the latter is simply how the former is typically achieved.
Basicly, the implementation of intellectual property is unfair and fundamentally flawed. Throwing it out entirely probably wouldn't work, but the current system is simply messed up.
You know, no one[1] in Australia has actually heard of Steve Irwin. He's not on our TVs, nor mentioned in the media. Probably for the best.
From the little second hand information I've seen, let me apologise on behalf of the country for this individual. There's probably a very good reason why he's over there and not over here though. One wonders if he really is Australian?
[1] Broad sweeping generalizations are us.
Actually UTF-16 can't represent the same range as UTF-8 or UTF-32, it's a bit weird. UTF-16 uses surrogate characters to represent the 16 UCS-4 planes 0x00010000 through 0x0010FFFF as a pair of 16-bit words.
As a preliminary, Unicode and ISO 10646 aren't the same standard, but are kept pretty much in synchronisation. ISO 10646 provides a character set with a 4-byte representation, and a compatible smaller set with a 2-byte representation. These representations have encodings such as UTF-8, UTF-16, and UTF-32. UTF-32 encodes every Unicode character in 32 bits and can represent the full 2^31 codepoints, while UTF-8 and UTF-16 as described in the Unicode 3.1 document are variable length representations that can represent approximately 2,100,000 and 1,100,000 codepoints respectively.
One of the design principles was to provide a lossless representation of any currently used character set in Unicode, so that a round-trip re-encoding of text from one encoding to Unicode and back again would lose no information. Another was to keep distinct code-points for any characters that had different semantics, or different 'abstract shapes'.
It turns out that one can satisfy these requirements for the Japanese kanji, Chinese hanzi (traditional and simplified) and Korean hanja without requiring a seperate code-point for each; in Unicode version 2.0, approximately 121,000 such characters were able to be represented in 20,902 code points. Note that those characters which have distinct shapes but the same meaning, and those which are similar enough to be classified as calligraphic variants but have distinct meanings, are all represented by distinct code-points. (One caveat: in practice there are some exceptions as regards the preservation of information after a round-trip encoding to Unicode and back. For example, the CCCII encoding of hanzi explicitly catalogues calligraphic variations, and as such doesn't map 1-1 onto Unicode.)
Of course, the actual glyph that corresponds to one of these unified codes will change depending upon the context in which it is rendered. For example the character 0x6d77 corresponding to the character for sea in both Chinese (Mandarin 'hai3') and Japanese ('umi') is drawn with one fewer stroke in Japanese than in Chinese. These typographical details are important, but can (and debatably, should) be dealt with outside the context of character encoding. Unicode has support for language tags which in the absence of any higher-level information can indicate the language context of the characters following them. Typically though, this information should be stored as part of a richer document structure (as is possible in XML for example.) Correct display of characters will require the presence of the appropriate font and a mechanism (such as LOCALE in a simple one language case) for selecting this font.
Given this unification then, one really can fit most of the characters for which there already extant (non-Unicode) encodings into 16 bits. With Unicode 3.1/ISO 10646-2 (which uses more than 65536 codepoints) this representation is AFAIK pretty much complete, including for example all of the hanzi of CNS 11643-1992 and CNS 11643-1986 plane 15 (the most complete hanzi encoding outside of CCCII.)
With this in mind, one can argue against the points raised in the article:
A little bit of research by the article author would have made the article unnecessary.
References:
Unicode 3.1 document;
CJKV Information Processing, Ken Lunde.
PS: In the time it took me to read the article, do some research and write this response, there have been over 300 slashdot comments. Wow.
Beer Good. Open Source Bad.
Kudos of course to all those who have put the hard work in to make this release possible, but from a developer's point of view, coding for Gnome/GTK can still be a frustrating experience.
The underlying problems seem to be poor documentation and an unwillingness to make incremental updates. In particular:
I'm sure these will in time be fixed. Some of these issues can only be addressed by structual changes in the code, making it inaccessible to the external developer without heaps of free time on their hands. The very infrequent development releases of GTK only compound it. When these issues are brought up on the mailing list, they are often ignored or dismissed. For all I know, lurking somewhere in CVS is complete documentation and a perfectly consistent sane and functional package - but if so, it's well hidden.
Things have improved a little on the solar front since, and further, if one really wanted to have a locally-solar powered vehicle, one would use the generating capacity of one's home to produce a portable form of energy (e.g. hydrogen) to fuel the car.
Doing the calculations though, is pretty grim:
- In California, 20 square metres of area gathers on average roughly 110 kW hours of engery in a day.
- The top theoretical efficiency for solar cells is about 88%. Current best in a commerical product is about 25%.
- Best efficiency for producing hydrogen from water using electricity is about 70%. Best effeciency for a fuel cell in a vehicle is about 60%.
So, using best available technology, using a solar -> electricity -> hydrogen -> fuel cell path, we get about 10kW hours of energy per day from one house. This will drive an efficient crusing vehicle (stretching here, and claiming 10kW power consumption) for one hour.With processes closer to the maximum theoretical efficiencies, and perhaps utilizing some more direct solar->hydrogen processes, one could possibly extract up to 5 hours worth of vehicle driving per household, foregoing any other sort of energy consumption.
Clearly, this isn't feasible, at least with that sort of energy consumption for a vehicle. With that consumption, it's basicly impossible to power a car with an energy source which is both renewable and local. The options are:
As far as I can tell, the only shortish term solution is the third. If we want to use energy sustainably, we have to rework our transport systems in a major way. At the moment, we're chewing up thousands of years of stored solar power in the form of fossil fuels.
On the bright side, 10kW hours of energy per household per day is quite nice, if we didn't have to worry about this whole transportation problem. It demonstrates that currently available solar and hydrogen technology is on the verge of being able to locally supply well in excess of all of our domestic energy needs, for those in the sunnier parts of the world.
I do remember one particular item featured on Beyond 2000's precursor show, 'Towards 2000'.
You may have seen them around - small disc thingies made of plastic with lots of tiny holes in them. Store music on them, and read it off with a laser. All very fancy. I think Phillips had something to do with it.
Given the choice, why on Earth would they pick a laser frequency to which the atmosphere wasn't nigh transparent? The whole point is to minimise signal loss. I'd be more worried about your microwave oven.
Let me confirm what others have said already:
I was fortunately able to join a games company as a programmer without previous games experience, or even a demo - but this is pretty uncommon. In my case, I was able to leverage ten years of other programming experience (network code, embedded controllers, etc.) and a strong maths background. At the other extreme, our best programmer had no formal IT experience and was basicly straight out of high school; what brought him to the interview stage was his demo.
Also, it sounds a bit mercenary, but the best time to join a company might be after they've just shipped their first game and are looking to expand. Chances are they won't have the funds to be too fussy about game industry experience, but will be desperate to get some new people in to support their next more ambitious project and to replace the 20% of people who left after the stress of the first project.
Coding real-time games to run over a 30kbit/sec connection is highly non-trivial. I'm speaking from experience (networking code for a car racing game: over modem, 8 to 12 players peer-to-peer networking).
If you update (say) 5 times a second, that's 200ms latency straight away, and you've already sucked up 10% of your bandwidth in packet headers. More in a peer-peer scenario! Then of course, you need to send each parameter in each object's config space in that update.
To minimise bandwidth wastage, you'd go client-server. But that effectively doubles the latency, and 400ms latency just from the networking is hard to compensate for. I won't go into all the ugly details - there are better discussions already online than that which I could write at 2am local time :) - but if you do the maths, you'll find it's not so easy after all.
I have to take issue with only one point: Diablo II networking is anything but good. The game makes little or no effort to accomodate pings higher than 300ms (modem + latency to game servers.) Many of the skills, spells etc. are dramatically less effective in these conditions. Teleporting monsters, freezes, etc. are not uncommon.
The sad thing is that network play over a LAN in Diablo II is little better, and sometimes worse! Great game, great gameplay, really really sucky network code.
Even a real-time strategy game can place high demands on bandwidth, when you only have a 30kbit/sec downstream pipe. Consider a four-player game: if unit-visibility is updated five times a second, and all the players have 100 roaming units, then before tricks are employed, that's 1500 unit position updates per second. With two-bytes per unit position, that's half the bandwidth used up already before compression, and that's just position information!
So RTS games require fancy bandwidth-saving tricks too. It's not trivial.
As other posters have pointed out as well, there is also the issue of latency. Two modems between you and your opponent can mean 300ms worth of 'free fire' on a unit (depending on game design.) This can certainly affect game-play!
But as the editorial rightly pointed out - modems aren't going away anytime soon. ADSL, cable, etc. is available to only a small percentage of game players/purchasers, and it's an affordable option for even fewer. Then, with both the Internet and the online-games market being global, the issue of latency isn't about to vanish either; It's hard to avoid 150ms of latency crossing the Pacific.
Hello? Who modded this as Flamebait? Did you read the thing I was replying too? Sheesh.
One thing that has really irked me in previous releases of GNOME, is that all the components and gnome-aware programs needed to be installed in the same directory for them to interoperate properly.
If one wants to maintain different versions of applications simultaneously, this is a royal pain in the neck. It's also irksome, in that it makes management of software through use of different application directories more awkward (forcing install directory != run directory, and a forest of symlinks.)
Does GNOME 1.4 finally address this issue, with some sort of search path mechanism? Does KDE suffer from similar issues? (Yes, this is something that aggravates me enough, that it could entice me to switch my desktop preference!)
Apple is no saint, but if anyone made the computer an acessible device, it was they, not Microsoft. Don't buy their hype. Windows and MS Office is ubiquitous now because of their abuses of the industry which led to their monopoly position; they didn't get that position by having superior software at the time.
Communism, an ideal promoting fairness and equality, is worse than the Satanic, being associated with all that evil. Ooookay,
Well, car's are dangerous things. That's why there is an extensive system of licenses and tests in most countries. If people just did whatever they liked on the road in a car, there would be mayhem. You wouldn't know what to expect.
A webpage is not a car. It's (typically) not nearly as dangerous. But one can make analogies. Knowing the difference between text and markup is as fundamental a part of contributing to the web as knowing the difference between the clutch and the accelerator when driving.
It's not too much to expect that drivers have a basic literacy as regards road rules, signs and the various control mechanisms of a car. Similarly, basic HTML, the language of the web, should be at least familiar to those who produce web content. Just as a working knowledge of car mechanics is only rarely useful in the everyday context of driving, the knowledge of HTTP and Apache configuration is not something one would expect every web author to have. I do believe your argument in fact better supports my own point.
If you're a professional web designer with this sort of attitude, you shouldn't be.
The US Government would not have had to step in and make this sort of thing mandatory, had it been done properly to begin with. Sometimes just letting people do their own thing simply doesn't work out so hot. This is why there are building codes, mandatory drug trials, etc.
When `the Market' fails, the Government should step in. That's one of the reasons why you have one. So stop bitching.
O! How I agree with this!
Javascript has never made a site faster or easier to navigate for me, and usually just screws things up.
Die, javascript, die!
Let me get this straight ... people can't learn to type <b> and </b>?
I'm flabbergasted. This is not rocket science.
I was going to make some snide remark about users drooling in their keyboards, but I'm sure those poor people who might desire to contribute to Slashdot but are cursed with a lack of motor control would not only be able to grasp the concept of marked text but would infintely prefer a scheme such with tags to some system requiring fine control of a mouse or pointer.
Call me elitist, but some fundamental level of web literacy is not too much to ask of people who are themselves contributing to the web.
And you should be using <em> instead, anyway.
G-funk wrote,
This is just wrong.
If look and feel is just as important to you, the provider of the information, then the WWW with HTML is not for you. You want a flash presentation or a PDF.
HTML is rendered on multiple platforms, on different media, for people with different requirements. There is simply no way one can ensure that the look and feel of a site is preserved. None. Not only that, but the attempts by authors to make them so generally result in making the content itself inaccessible to between 5% and 20% of readers. This is obviously screwy.
I'm sure there are some applications for which the exact presentation of content is a crucial component of the content itself. I can't recall the last time I came across such a web page though. While there are thousands (millions?) which do sacrifice accessibility and usability on the altar of `user experience'.
If you need exact presentation, use flash and PDF. If you actually have anything important to say, use HTML and live with the fact that it won't look (or sound, or print) the same to every reader. Just cope.
There are more important things than the Internet, sure. Like food. But information access is still more than just a luxury.
In many places poverty is the result of a power differential. (In many others of course it can be the result of natural disasters, but bear with me!) One of the tools which allows power structures to remain entrenched is control over information. Free access to unfiltered information won't be a panacea, but it can certainly help to curb the worst abuses of power. When people can communicate quickly and anonymously, abuses can be addressed earlier and more effectively.
Most people seem to have a sense of justice. So when the message can get out, the population at large can effect change. There would have been no outrage at Nike for its explotive practices had no news of them ever come to light.
Of course information by itself is insufficient - there has to be a critical reader at the receiving end. Here again, the Internet can provide educational resources where there would otherwise be none, or very carefully controlled selection. The control of the 'net by advertising interests will see such applications marginalised or controlled.