Ideally, they could use MP3's, but I suspect that you're probably talking more along the lines of Ogg, which, let's be honest, doesn't even appear on the radar for [the BBC] (nor most of their audience).
You know, usually you'd be right, but you went and picked the one example where you are wrong.
Just what are we protecting our children from? When do they lose the benefit of that protection? Is shielding them from things that they're are GOING to be exposed to for the rest of their lives really protecting them at all?
In short, yes.
You have the air of a teenager who does not spend much time with children. The fact is that a six year old is not equipped to understand sex. With sufficient "education" they could probably pass a sex-ed exam, but that's "book learning"; they still don't understand it. Among other things, they are literally not physically equipped to understand what "sex drive" or "horny" really means.
You have forgotten this because you are now old enough to understand, but in your lack of empathy you forget that everyone is not like you, especially children.
The problem is that what a child does not truly understand will be filled in with something, and the odds of them filling it in correctly are effectively zero. Surely you've seen one of those humor postings that contains 20 or 30 "explanations" from children about how the world works, all very funny, all very wrong. Now imagine that with sex, where they don't have the first clue what it is.
While one does not necessarily need to go to extremes to shield a child (because mercifully they are rather uncurious about stuff they have no inkling even exists; most 5 or 6 year olds should be happy with the explanations that babies require a mommy and a daddy, and probe for only limited details beyond that), it is still better to shield them from stuff that they can not and will not understand, until they have a framework for handling it.
For a more neutral example, look at the number of Slashdot-type people who believe mystical things about Electromagnetism or Quantum Physics or other subjects they totally don't understand. Their ignorance is filled in with garbage.
Furthermore, unlike misunderstanding QM or EM, which is relatively harmless, a misunderstanding of sex has empirically verifiable negative effects on people, ranging from merely awkward moments that should't have been awkward to seriously maladjustments (often caused by early sexual abuse; remember I'm using this as an extreme) requiring years of therapy to address, if it can be addressed at all.
Shielding a child from these things is an attempt to prevent the child from experiencing these negative effects. Any parent who doesn't shield their kid to a large degree is doing their child a serious, potentially life-changing (negatively) misservice.
I'm a big believer that we seriously underestimate our children routinely and are harming them thereby. But this is an exception. Try to teach a third-grader calculus, and they won't get it (with rare exceptions; see Piaget's theories for reasoning on that), but the misunderstandings they will develop won't harm them significantly. That's not true for sex; it has real effects on relationships and understanding their place in the world.
For a humorous demonstration of this, there's a South Park episode where the kids learn about sex; I recommend it to you. It's not as far out as it might seem; the only reason that sort of thing doesn't happen in real life (except for the final silly Mad-Max-style assault bit) is that kids feed back to their parents what they learned, and some of the parents would have noticed sooner the misconceptions they were developing and taken steps to defuse them. Otherwise, the damage done to the children's relationships (and in the real world, it could be worse; it certainly wouldn't be artifically erased at the end of the episode when the Reset Button is pushed) would be real.
I can see how to do this, technically, I think. It's not easy and would require easily two or three years with a qualified team, and some serious training for the seed content creators, but it could be done. The good news is that a lot of the work would be surprisingly generic, and in the end, you'd have a framework for such games that you could plug into a lot of genres. Plus the end result would mean that the content creators, like I said, would be seed creators; they would not need to specify every last item in the game, but they could let the computer "grow" towns and such.
Surprisingly, IMHO, the biggest problem is balancing. People need to feel like they have some amount of control over things, yet with tens of thousands of people on a given server, they probably don't. Getting the balancing right could easily take another two or three years.
Another bonus, once it's done, is that you get real quests with real results, enough for everybody to have something to do.
I can't imagine we'll see this for a long time, though; it's certainly not something somebody could sit down and slam out, it will be very, very subtle work that will need very skillful people to perform. Current MMORPGs only need perhaps a quarter as much programming talent as this one would need. I'd like to see it, I'd even like to work on it, but I wouldn't expect to see it for decades, easily.
Well, there must be a way to set up a system that WILL allow you to make money, without invoking IP.
No, there isn't, almost by definition. Any system that REQUIRES monetary payment before certain usage of certain things like programs will have IP-aspects. Period.
(Fully voluntary donation would be the only alternative, with absolutely no compensation for donation above and beyond feeling good. That is unlikely to support a software industry.)
Yeah, Blix was a real pity. The premise was so cool and reasonably innovative. (Can't expect games nowadays to look like absolutely nothing that has come before, what with tens of thousands of games existing already.) Executiong on it sucked; I could create several better puzzles with those capabilities in a couple of hours.
Blix should be made into a poster child of failed potential in original video games.
Everything you describe, except sensory deprivation, are optical or auditory illusions, not hallucinations. They reflect weaknesses in our perceptual system, or sometimes, they reflect strengths.
For example, in our eyeballs, before the signal even goes out on the optic nerve, some edge detection is performed on the incoming optical input. If you remember the optical illusion where there is a regular grid of black squares, delimited by white lines, and you see little black sparkles in the intersection of the white lines flashing everywhere, that's your "edge detection" you're seeing. Despite the fact those little sparkles are illusions, they really flow from a strength of our visual system, not a weakness; the first step a computer vision system will perform is quite often an edge-detection stage, and how well done the edge-detection is can have a huge impact on the effectiveness of the system.
Some drugs and being excessively tired can also cause you "edge detection" to go crazy, making things seem to shimmer. (Like in the Simpsons when Lisa drank from the amusement park water; that's the effect they were trying to simulate.)
I also think, though I don't know, that the fancy moving patterns you see when you close your eyes and concentrate on what you're seeing is the edge detection system semi-randomly firing, and providing input to the even higher-level brain functions.
Now, "acute sensory deprivation" does cause hallucinations as your brain over-interprets what little stimulation it has; in a way, it's just an optical illusion writ large and occurring on a higher semantic level, but there is a qualitative difference. I would say that you provided a counterexample to the grandparent post's claim, but it still fails to provide any evidence that a video game could affect people in any serious way through the application of visual or auditory stimulus that we would consider within the domain of a normal video game. (i.e., loud low sounds can cause naseua, but that's not normal video game fare.)
(Some well-done video games can affect us emotionally, but it's done with perfectly normal stimuli, just well-assembled on the conceptual (story) level.)
The point that the video game as described is effectively impossible still stands.
Has this been fixed in the newer Jabber clients for Windows?
Truthfully, I don't know. I never had problems with gabber on Linux, and that was a while ago; open source products like that tend towards monotonically increasing quality (though I've seen exceptions).
My personal interest in Jabber tends to extend to the abilities of the protocol beyond normal IM, so I'm not up on the clients themselves. (I've got something in the oven that probably isn't a Killer App but should still introduce a lot of people to the idea that Jabber isn't just for IM, including many who may have never heard of it otherwise.)
The vast majority of my CPU's time is spent waiting for data to arrive, from memory, from the disk, from the keyboard and mouse, from the network (!), and from a wide variety of other sources, all orders of magnitude slower then my CPU.
There's a damn good reason almost nobody cares about this, and the ones that do care already care, and that is that for the vast majority of what people do every day, none of that matters.
You want to create Yet Another Functional Language? Hey, great, I'd hate to be the guy who convinced Larry Wall not to write Perl. But you might want to consider whether the problems you think exist really exist, or if they are merely abstract "Wouldn't it be nice if..." problems. A lot of smart people have been over this ground and it's neither as easy, nor as profitable, as you seem to think it is. It's your life.
I'd much rather not have to rely on a remote computer for communicating through other mediums.... 1. Decentralized message transfer. I don't want my message going in whole form off across the network, to run into any old stumbling block like a central server or network outage.
You don't have to rely on remote servers... Jabber is decentralized. To make this happen, run a Jabber server on both the target and destination machines. Voila, only two computers involved in the IM transaction.
If that's not good enough and you're thinking even more decentralized, then you're getting really radical and you're going to find other nice properties of an IM system will suffer; in particular all schemes for even further decentralization will cost you full seconds (or even tens of seconds) for routing, and I think you'd find that largely unacceptable if you actually had it working in front of you right now.
You'll need to run a server on either machine anyhow if you're going to have a "decentralized" system, it's oxymoronic to try to create a "server-free" system, so it might as well be Jabber. (Remember "server" here just means "recieving TCP/IP packets".)
Of course, by running your own server, assuming it's on a machine that isn't always on, you sacrifice the benefits of running the server on an always-on system, like message queueing while you're offline... but if you're like me and don't consider IMs to be critical, that's fine.
2. I want it to be encrypted (by default and as part of the protocol, so my non-techie friends don't have to touch it to be done properly..
Valid criticism, though this is a client problem, not a server or protocol problem.
3. Easily integrated other types of data through use of a paralell decentralized stream (sounds contradictory, doesn't it?). I want to be able to easily put files across to the other user, streamed if I'd like to, for webcam use. Something of an IRC blend in that latter aspect of it.
This is covered in the Jabber protocol, via the OOB specification. I believe some of the clients implement this. Some of what you are saying is sorta contradictory sounding; Jabber is as decentralized as you can reasonably get already.
4. Obviously open source. Not even a question. I want people tinkering with this constantly, making it better and harder to interfere with.
The Jabber server is listed as GPL v. 2 by my Gentoo portage system. It doesn't get much more open source then that. The existance of a commercial branch is a net gain; it makes it that much more likely it will continue to be around.
It would be popular and desireable enough that I wouldn't have any friends on the other mediums to bother with.
Of course there's not a damn thing any IM program can do about that; not even Microsoft can create users by executive fiat.
but a bit quicker due to the message protocol itself, which is vague in my head, but starting to form.
I don't think you dislike Jabber... I think you tried one or two, probably half-baked, clients and disliked those. Sounds to me like Jabber is 90% of the way to what you want, except for the "number of people using" it issue which really can't be held against the IM system itself. Please don't try to create a competing protocol; you'd be much better off spending your time polishing up one of the more-mature Jabber clients to add the last couple of features you want, not creating an IM system from scratch.
(My other desire is better compression of the stream; apparently SSL gives you this in addition to security, so I guess that kills two birds with one stone if you get more people to use that automatically.)
you'd be pissed when the dove finally made it back with host not found.
Especially since history indicates that the standard retry time was seven days long. 14 days to send a one-bit message ("host found" vs. "host not found") sucks pretty hard.
Better make sure you get the hostname right the first time....
Finally, Mr. Carey is right. If SCO's claims are without merit, then they have placed themselves at a huge risk of a substantial judgment against them. Of all our sakes, I hope that this is the case.
Screw SCO getting a big judgement against them. I want the SEC here; any doubt I had that this is at least partially a stock ploy just went out the window. Forget punishing SCO, I want the people in jail!
A bug found by a Red Hat engineer or user is frequently in the "upstream package" (at least, that's the term Gentoo uses; I don't know how universal it is), that, when fixed, will propogate back down to all Linux distributions sooner or later.
(Note I am not the original poster who made the claim.)
You may have worked for MS and known what kind of testing they do, but nowhere in your post do you claim to have done the same at RedHat or IBM. How, then, can you make such a claim?
In all fairness to Microsoft, I am fairly certain that Microsoft employs more test engineers directly then Red Hat employees engineers total. It is not completely logically rigorous to therefore conclude Microsoft necessarily does more testing in terms of man-hours (need a few more statements), but it's a fairly safe conclusion.
But the compairision is not "fair" because the Linux folk share testing, while Microsoft is responsible for their own. A bug found by a Red Hat engineer or user is frequently in the "upstream package" (at least, that's the term Gentoo uses; I don't know how universal it is), that, when fixed, will propogate back down to all Linux distributions sooner or later.
In truth, I'd submit there's no way to "fairly" compare the testing the two groups do; it's just too different. All I can say is while it is again not necessarily a logically rigorous thing to say, it's safe to say that Open Source is indeed tested quite thoroughly on the ground that all insufficiently tested software is basically a seething mass of bugs, quite a bit of Open Source software is not a seething mass of bugs, therefore, quite a bit of Open Source software is sufficiently tested. Through what means, in the end, doesn't matter to the end user terribly much.
Asking for justification of the claim is a fair challenge, though; this message is not meant to imply otherwise.
I request that the next feature to develop is an option where you just wave or shake the miniCD at the computer to remedy any problems. This would alleviate the hassle of putting the miniCD into the tray and running it.
Sounds like a great Open Source project to make your fame with. Please make it RFC 2321 compliant.
I've never, to this date, had an issue with Hello World.
Perhaps, but I've seen a "Hello X" that had a buffer overflow, copying the first command line argument into a fixed-size buffer before printing. (The student was fuzzy on the fact that they could have directly passed the command line argument to printf... though even then you need to check that it exists!)
Anything above Hello World in C is potentially dangerous.
Please go and have a look at the GnuCash codebase before slagging the developers off.
I didn't slag the developers off. I'd suggest a closer reading of my message, with a more detached point of view. The main point is much more general.
Evidently the docs aren't "good enough"; proof by demonstration. I hope lessons can be learned by all. God only knows how many hours have been wasted by me trying to use software (open source and commercial both) with documentation written by people who can't seem to write in any language, computer or human, enough to write themselves out of a paper bag. The worst thing is the more the program needs docs (customizations, innovative new open source projects), the less likely it is to have them. An hour spent on docs can add hundreds or thousands of man-hours of value to a project. Any encouragement of developers to write docs is a good thing.
I think the people who will play this are college students, who will play it with their roommates.
Mmmmmm.... that's really a rather small market. Sure, there's always the four-some room (not sexually, at least, not to my knowlege) that always seems to have video game sounds coming out of it day or night, but they're the exception, not the rule.
(I lived on seven or eight floors in college, and every single one of them had a group like that, one and only one.)
Moreover, it's always sports sounds coming out of the room, not much of anything else. About as far from the FF type you can get.
I hate to sound down on it because I like to see innovative things succeed; it raises the chance we'll see other innovation. I hope it does work...
This fits into my pet theory of successful open-source projects rather nicely; every single flaw except one boils down to a lack of documentation.
"Work on the developer documentation problem" - obvious
"Fix core capabilities in the engine" - the exception, though one could stretch and observe that a lot of the problem is probably that nobody has a clue what is broken due to lack of documentation.
"Improve interoperability with other software or new modules" - fundamentally, the fact it was "non-interoperable" in the first place boils down to a lack of documentation, because why bother adding hooks to anything if nobody can figure out how to use them in less then a year? Adding hooks is easy, relatively speaking, and the payback is huge; the only reason to not do it is if you realize nobody could possibly use them if you added them.
"Make sure the mailing lists are easily searchable" - obvious
"Get more people write access to the website" - obvious
"Quickly implement a Wiki or similar system" - obvious
"Spend less time answering some types of questions" - they should be able to point people at a FAQ, a common type of documentation
If it isn't documented, it doesn't exist. GnuCash's problem is an excess of non-existence, which is rather odd considering how many lines of code it has.
It is so much easier to start the documentation in the first place, and keep it up, then to get to 250,000 LOC and just then try to start. Sometimes clever coders can actually be a liability to a project, because they can plow on where lesser men and women would have needed to pause, document, possibly re-organize, and simplify.
my $s = 'DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS';
could this not set a precedent for Civil copyright cases?
There shouldn't be a precedent to be set! If somebody else uses a computer to do something, it's 100% their responsibility if that's a legal thing to do. (If they don't have permission to use that computer, they're already starting out on the wrong foot legally.) The fact that it happens to be your computer should be mostly meaningless; you didn't do anything.
Maybe someday, when it's possible to reliably say "This computer is 100% secure", then we can blame people for everything their computer does. In the meantime, security vulnerabilities in old mainstays like ssh and man and other things continue to be found.
The only concievable legal basis for nailing a computer owner for something they had nothing to do with and weren't even aware was happening is sheer convenience, and the goal of Justice is not to make law enforcement convenient. In fact, convenient law enforcement is nearly diametrically opposed to Justice, as a practical matter.
Will this make people use it as an excuse? Of course it will! So what? People use "self-defense" as an excuse for murder all the time. Sometimes it's a lie. Sometimes it's the truth. It remains a valid defense; I would not want to live in a society where self-defense is the same as murder. That it might be used as an excuse is a completely invalid argument; you're implicitly appealing to law-enforcement convenience, and that is not a valid thing to argue for. Justice should not be convenient (mostly the first paragraph, although the point underscores the whole piece).
Multiplayer is like magic juice; add it to any game and it is instantly more fun.
Personally, I'd find the comment "The one player mode feels a bit lonely as the gameplay tends to become routine." to probably be pretty informative. Given the number of people who will not be able to come up with three other people to play this with... everyone I know has a console or three, but there's no way in hell four of us could consistently book time for this... even in high school four person groupings were often hard to come up with... I suspect this is going to be one of Squares rather-more-frequent-then-fanboys-admit blunders, rather then a success.
There is an empirical measure of this: Will Square do a sequel with this style? If so, I'm wrong; if not, I'm right.
Seriously, no. Infamy dies out exponentially over time, with initial size proportional to the dastardliness of the initial infamous act. SCO re-earns high infamy marks with every press release, but will sooner or later flame out, and rapidly drop below Nazi's.
Unless SCO manages to literally kill millions of Linux users, which is a little unlikely.
Slashdot Mirror
Ideally, they could use MP3's, but I suspect that you're probably talking more along the lines of Ogg, which, let's be honest, doesn't even appear on the radar for [the BBC] (nor most of their audience).
You know, usually you'd be right, but you went and picked the one example where you are wrong.
Ouch. What were the odds?
Just what are we protecting our children from? When do they lose the benefit of that protection? Is shielding them from things that they're are GOING to be exposed to for the rest of their lives really protecting them at all?
In short, yes.
You have the air of a teenager who does not spend much time with children. The fact is that a six year old is not equipped to understand sex. With sufficient "education" they could probably pass a sex-ed exam, but that's "book learning"; they still don't understand it. Among other things, they are literally not physically equipped to understand what "sex drive" or "horny" really means.
You have forgotten this because you are now old enough to understand, but in your lack of empathy you forget that everyone is not like you, especially children.
The problem is that what a child does not truly understand will be filled in with something, and the odds of them filling it in correctly are effectively zero. Surely you've seen one of those humor postings that contains 20 or 30 "explanations" from children about how the world works, all very funny, all very wrong. Now imagine that with sex, where they don't have the first clue what it is.
While one does not necessarily need to go to extremes to shield a child (because mercifully they are rather uncurious about stuff they have no inkling even exists; most 5 or 6 year olds should be happy with the explanations that babies require a mommy and a daddy, and probe for only limited details beyond that), it is still better to shield them from stuff that they can not and will not understand, until they have a framework for handling it.
For a more neutral example, look at the number of Slashdot-type people who believe mystical things about Electromagnetism or Quantum Physics or other subjects they totally don't understand. Their ignorance is filled in with garbage.
Furthermore, unlike misunderstanding QM or EM, which is relatively harmless, a misunderstanding of sex has empirically verifiable negative effects on people, ranging from merely awkward moments that should't have been awkward to seriously maladjustments (often caused by early sexual abuse; remember I'm using this as an extreme) requiring years of therapy to address, if it can be addressed at all.
Shielding a child from these things is an attempt to prevent the child from experiencing these negative effects. Any parent who doesn't shield their kid to a large degree is doing their child a serious, potentially life-changing (negatively) misservice.
I'm a big believer that we seriously underestimate our children routinely and are harming them thereby. But this is an exception. Try to teach a third-grader calculus, and they won't get it (with rare exceptions; see Piaget's theories for reasoning on that), but the misunderstandings they will develop won't harm them significantly. That's not true for sex; it has real effects on relationships and understanding their place in the world.
For a humorous demonstration of this, there's a South Park episode where the kids learn about sex; I recommend it to you. It's not as far out as it might seem; the only reason that sort of thing doesn't happen in real life (except for the final silly Mad-Max-style assault bit) is that kids feed back to their parents what they learned, and some of the parents would have noticed sooner the misconceptions they were developing and taken steps to defuse them. Otherwise, the damage done to the children's relationships (and in the real world, it could be worse; it certainly wouldn't be artifically erased at the end of the episode when the Reset Button is pushed) would be real.
Oh, and it's not cold at all, especially on the sunny side.
That's not an advantage, that's a disadvantage. Cold is much easier to deal with then hot. Reasons why left as an exercise to the reader.
I can see how to do this, technically, I think. It's not easy and would require easily two or three years with a qualified team, and some serious training for the seed content creators, but it could be done. The good news is that a lot of the work would be surprisingly generic, and in the end, you'd have a framework for such games that you could plug into a lot of genres. Plus the end result would mean that the content creators, like I said, would be seed creators; they would not need to specify every last item in the game, but they could let the computer "grow" towns and such.
Surprisingly, IMHO, the biggest problem is balancing. People need to feel like they have some amount of control over things, yet with tens of thousands of people on a given server, they probably don't. Getting the balancing right could easily take another two or three years.
Another bonus, once it's done, is that you get real quests with real results, enough for everybody to have something to do.
I can't imagine we'll see this for a long time, though; it's certainly not something somebody could sit down and slam out, it will be very, very subtle work that will need very skillful people to perform. Current MMORPGs only need perhaps a quarter as much programming talent as this one would need. I'd like to see it, I'd even like to work on it, but I wouldn't expect to see it for decades, easily.
Well, there must be a way to set up a system that WILL allow you to make money, without invoking IP.
No, there isn't, almost by definition. Any system that REQUIRES monetary payment before certain usage of certain things like programs will have IP-aspects. Period.
(Fully voluntary donation would be the only alternative, with absolutely no compensation for donation above and beyond feeling good. That is unlikely to support a software industry.)
For the record, Jabber-the-protocol can handle international characters perfectly, as long as the chars are in Unicode.
The clients are at fault if they can't handle the Unicode, and they need to be poked and prodded until they do.
Also, Jabber contact lists are stored on the server, too.
Yeah, Blix was a real pity. The premise was so cool and reasonably innovative. (Can't expect games nowadays to look like absolutely nothing that has come before, what with tens of thousands of games existing already.) Executiong on it sucked; I could create several better puzzles with those capabilities in a couple of hours.
Blix should be made into a poster child of failed potential in original video games.
Everything you describe, except sensory deprivation, are optical or auditory illusions, not hallucinations. They reflect weaknesses in our perceptual system, or sometimes, they reflect strengths.
For example, in our eyeballs, before the signal even goes out on the optic nerve, some edge detection is performed on the incoming optical input. If you remember the optical illusion where there is a regular grid of black squares, delimited by white lines, and you see little black sparkles in the intersection of the white lines flashing everywhere, that's your "edge detection" you're seeing. Despite the fact those little sparkles are illusions, they really flow from a strength of our visual system, not a weakness; the first step a computer vision system will perform is quite often an edge-detection stage, and how well done the edge-detection is can have a huge impact on the effectiveness of the system.
Some drugs and being excessively tired can also cause you "edge detection" to go crazy, making things seem to shimmer. (Like in the Simpsons when Lisa drank from the amusement park water; that's the effect they were trying to simulate.)
I also think, though I don't know, that the fancy moving patterns you see when you close your eyes and concentrate on what you're seeing is the edge detection system semi-randomly firing, and providing input to the even higher-level brain functions.
Now, "acute sensory deprivation" does cause hallucinations as your brain over-interprets what little stimulation it has; in a way, it's just an optical illusion writ large and occurring on a higher semantic level, but there is a qualitative difference. I would say that you provided a counterexample to the grandparent post's claim, but it still fails to provide any evidence that a video game could affect people in any serious way through the application of visual or auditory stimulus that we would consider within the domain of a normal video game. (i.e., loud low sounds can cause naseua, but that's not normal video game fare.)
(Some well-done video games can affect us emotionally, but it's done with perfectly normal stimuli, just well-assembled on the conceptual (story) level.)
The point that the video game as described is effectively impossible still stands.
Has this been fixed in the newer Jabber clients for Windows?
Truthfully, I don't know. I never had problems with gabber on Linux, and that was a while ago; open source products like that tend towards monotonically increasing quality (though I've seen exceptions).
My personal interest in Jabber tends to extend to the abilities of the protocol beyond normal IM, so I'm not up on the clients themselves. (I've got something in the oven that probably isn't a Killer App but should still introduce a lot of people to the idea that Jabber isn't just for IM, including many who may have never heard of it otherwise.)
The vast majority of my CPU's time is spent waiting for data to arrive, from memory, from the disk, from the keyboard and mouse, from the network (!), and from a wide variety of other sources, all orders of magnitude slower then my CPU.
There's a damn good reason almost nobody cares about this, and the ones that do care already care, and that is that for the vast majority of what people do every day, none of that matters.
You want to create Yet Another Functional Language? Hey, great, I'd hate to be the guy who convinced Larry Wall not to write Perl. But you might want to consider whether the problems you think exist really exist, or if they are merely abstract "Wouldn't it be nice if..." problems. A lot of smart people have been over this ground and it's neither as easy, nor as profitable, as you seem to think it is. It's your life.
I'd much rather not have to rely on a remote computer for communicating through other mediums.... 1. Decentralized message transfer. I don't want my message going in whole form off across the network, to run into any old stumbling block like a central server or network outage.
You don't have to rely on remote servers... Jabber is decentralized. To make this happen, run a Jabber server on both the target and destination machines. Voila, only two computers involved in the IM transaction.
If that's not good enough and you're thinking even more decentralized, then you're getting really radical and you're going to find other nice properties of an IM system will suffer; in particular all schemes for even further decentralization will cost you full seconds (or even tens of seconds) for routing, and I think you'd find that largely unacceptable if you actually had it working in front of you right now.
You'll need to run a server on either machine anyhow if you're going to have a "decentralized" system, it's oxymoronic to try to create a "server-free" system, so it might as well be Jabber. (Remember "server" here just means "recieving TCP/IP packets".)
Of course, by running your own server, assuming it's on a machine that isn't always on, you sacrifice the benefits of running the server on an always-on system, like message queueing while you're offline... but if you're like me and don't consider IMs to be critical, that's fine.
2. I want it to be encrypted (by default and as part of the protocol, so my non-techie friends don't have to touch it to be done properly..
Valid criticism, though this is a client problem, not a server or protocol problem.
3. Easily integrated other types of data through use of a paralell decentralized stream (sounds contradictory, doesn't it?). I want to be able to easily put files across to the other user, streamed if I'd like to, for webcam use. Something of an IRC blend in that latter aspect of it.
This is covered in the Jabber protocol, via the OOB specification. I believe some of the clients implement this. Some of what you are saying is sorta contradictory sounding; Jabber is as decentralized as you can reasonably get already.
4. Obviously open source. Not even a question. I want people tinkering with this constantly, making it better and harder to interfere with.
The Jabber server is listed as GPL v. 2 by my Gentoo portage system. It doesn't get much more open source then that. The existance of a commercial branch is a net gain; it makes it that much more likely it will continue to be around.
It would be popular and desireable enough that I wouldn't have any friends on the other mediums to bother with.
Of course there's not a damn thing any IM program can do about that; not even Microsoft can create users by executive fiat.
but a bit quicker due to the message protocol itself, which is vague in my head, but starting to form.
I don't think you dislike Jabber... I think you tried one or two, probably half-baked, clients and disliked those. Sounds to me like Jabber is 90% of the way to what you want, except for the "number of people using" it issue which really can't be held against the IM system itself. Please don't try to create a competing protocol; you'd be much better off spending your time polishing up one of the more-mature Jabber clients to add the last couple of features you want, not creating an IM system from scratch.
(My other desire is better compression of the stream; apparently SSL gives you this in addition to security, so I guess that kills two birds with one stone if you get more people to use that automatically.)
you'd be pissed when the dove finally made it back with host not found.
Especially since history indicates that the standard retry time was seven days long. 14 days to send a one-bit message ("host found" vs. "host not found") sucks pretty hard.
Better make sure you get the hostname right the first time....
Lansing, MI is out. I'm posting from Michigan State University which has its own power station.
Finally, Mr. Carey is right. If SCO's claims are without merit, then they have placed themselves at a huge risk of a substantial judgment against them. Of all our sakes, I hope that this is the case.
Screw SCO getting a big judgement against them. I want the SEC here; any doubt I had that this is at least partially a stock ploy just went out the window. Forget punishing SCO, I want the people in jail!
Geez, learn to read, will you?
A bug found by a Red Hat engineer or user is frequently in the "upstream package" (at least, that's the term Gentoo uses; I don't know how universal it is), that, when fixed, will propogate back down to all Linux distributions sooner or later.
(Note I am not the original poster who made the claim.)
You may have worked for MS and known what kind of testing they do, but nowhere in your post do you claim to have done the same at RedHat or IBM. How, then, can you make such a claim?
In all fairness to Microsoft, I am fairly certain that Microsoft employs more test engineers directly then Red Hat employees engineers total. It is not completely logically rigorous to therefore conclude Microsoft necessarily does more testing in terms of man-hours (need a few more statements), but it's a fairly safe conclusion.
But the compairision is not "fair" because the Linux folk share testing, while Microsoft is responsible for their own. A bug found by a Red Hat engineer or user is frequently in the "upstream package" (at least, that's the term Gentoo uses; I don't know how universal it is), that, when fixed, will propogate back down to all Linux distributions sooner or later.
In truth, I'd submit there's no way to "fairly" compare the testing the two groups do; it's just too different. All I can say is while it is again not necessarily a logically rigorous thing to say, it's safe to say that Open Source is indeed tested quite thoroughly on the ground that all insufficiently tested software is basically a seething mass of bugs, quite a bit of Open Source software is not a seething mass of bugs, therefore, quite a bit of Open Source software is sufficiently tested. Through what means, in the end, doesn't matter to the end user terribly much.
Asking for justification of the claim is a fair challenge, though; this message is not meant to imply otherwise.
I request that the next feature to develop is an option where you just wave or shake the miniCD at the computer to remedy any problems. This would alleviate the hassle of putting the miniCD into the tray and running it.
Sounds like a great Open Source project to make your fame with. Please make it RFC 2321 compliant.
Standards are very important, after all.
Support Human Justice for Human Beings!
I've never, to this date, had an issue with Hello World.
Perhaps, but I've seen a "Hello X" that had a buffer overflow, copying the first command line argument into a fixed-size buffer before printing. (The student was fuzzy on the fact that they could have directly passed the command line argument to printf... though even then you need to check that it exists!)
Anything above Hello World in C is potentially dangerous.
Please go and have a look at the GnuCash codebase before slagging the developers off.
I didn't slag the developers off. I'd suggest a closer reading of my message, with a more detached point of view. The main point is much more general.
Evidently the docs aren't "good enough"; proof by demonstration. I hope lessons can be learned by all. God only knows how many hours have been wasted by me trying to use software (open source and commercial both) with documentation written by people who can't seem to write in any language, computer or human, enough to write themselves out of a paper bag. The worst thing is the more the program needs docs (customizations, innovative new open source projects), the less likely it is to have them. An hour spent on docs can add hundreds or thousands of man-hours of value to a project. Any encouragement of developers to write docs is a good thing.
I think the people who will play this are college students, who will play it with their roommates.
Mmmmmm.... that's really a rather small market. Sure, there's always the four-some room (not sexually, at least, not to my knowlege) that always seems to have video game sounds coming out of it day or night, but they're the exception, not the rule.
(I lived on seven or eight floors in college, and every single one of them had a group like that, one and only one.)
Moreover, it's always sports sounds coming out of the room, not much of anything else. About as far from the FF type you can get.
I hate to sound down on it because I like to see innovative things succeed; it raises the chance we'll see other innovation. I hope it does work...
This fits into my pet theory of successful open-source projects rather nicely; every single flaw except one boils down to a lack of documentation.
"Work on the developer documentation problem" - obvious
"Fix core capabilities in the engine" - the exception, though one could stretch and observe that a lot of the problem is probably that nobody has a clue what is broken due to lack of documentation.
"Improve interoperability with other software or new modules" - fundamentally, the fact it was "non-interoperable" in the first place boils down to a lack of documentation, because why bother adding hooks to anything if nobody can figure out how to use them in less then a year? Adding hooks is easy, relatively speaking, and the payback is huge; the only reason to not do it is if you realize nobody could possibly use them if you added them.
"Make sure the mailing lists are easily searchable" - obvious
"Get more people write access to the website" - obvious
"Quickly implement a Wiki or similar system" - obvious
"Spend less time answering some types of questions" - they should be able to point people at a FAQ, a common type of documentation
If it isn't documented, it doesn't exist. GnuCash's problem is an excess of non-existence, which is rather odd considering how many lines of code it has.
It is so much easier to start the documentation in the first place, and keep it up, then to get to 250,000 LOC and just then try to start. Sometimes clever coders can actually be a liability to a project, because they can plow on where lesser men and women would have needed to pause, document, possibly re-organize, and simplify.
my $s = 'DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS';
$s =~ s/DEVELOPERS/DOCUMENT IT/g;
could this not set a precedent for Civil copyright cases?
There shouldn't be a precedent to be set! If somebody else uses a computer to do something, it's 100% their responsibility if that's a legal thing to do. (If they don't have permission to use that computer, they're already starting out on the wrong foot legally.) The fact that it happens to be your computer should be mostly meaningless; you didn't do anything.
Maybe someday, when it's possible to reliably say "This computer is 100% secure", then we can blame people for everything their computer does. In the meantime, security vulnerabilities in old mainstays like ssh and man and other things continue to be found.
The only concievable legal basis for nailing a computer owner for something they had nothing to do with and weren't even aware was happening is sheer convenience, and the goal of Justice is not to make law enforcement convenient. In fact, convenient law enforcement is nearly diametrically opposed to Justice, as a practical matter.
Will this make people use it as an excuse? Of course it will! So what? People use "self-defense" as an excuse for murder all the time. Sometimes it's a lie. Sometimes it's the truth. It remains a valid defense; I would not want to live in a society where self-defense is the same as murder. That it might be used as an excuse is a completely invalid argument; you're implicitly appealing to law-enforcement convenience, and that is not a valid thing to argue for. Justice should not be convenient (mostly the first paragraph, although the point underscores the whole piece).
Multiplayer is like magic juice; add it to any game and it is instantly more fun.
Personally, I'd find the comment "The one player mode feels a bit lonely as the gameplay tends to become routine." to probably be pretty informative. Given the number of people who will not be able to come up with three other people to play this with... everyone I know has a console or three, but there's no way in hell four of us could consistently book time for this... even in high school four person groupings were often hard to come up with... I suspect this is going to be one of Squares rather-more-frequent-then-fanboys-admit blunders, rather then a success.
There is an empirical measure of this: Will Square do a sequel with this style? If so, I'm wrong; if not, I'm right.
Seriously, no. Infamy dies out exponentially over time, with initial size proportional to the dastardliness of the initial infamous act. SCO re-earns high infamy marks with every press release, but will sooner or later flame out, and rapidly drop below Nazi's.
Unless SCO manages to literally kill millions of Linux users, which is a little unlikely.