CS is about being able to advance the state of the art. It's related to IT in very much the same way physics is related to auto mechanics: you need to understand *some* physics to be any good at auto mechanics, but you're not going to be up for a Nobel prize anytime soon, and you'll probably stand there like a deer in headlights if people start trotting out Maxwell's equations.
However, most people who study CS and get degrees in the field are really not all that different from before they got the degree. CS, like most other sciences, is not very useful at the baccalaureate level; it only begins to have real application to real tasks once you get into the graduate level, and it doesn't come into its own until you get deeply into the post-graduate work. (Nobody is impressed by a bachelor's in physics or biology, either; strangely enough, I meet a lot of bartenders that have those.)
So if you're not planning to go for the doctorate, target the general area where you want to work: CS people are usually at a desk creating software, and IT people are usually in the basement monitoring hardware. If you don't really like either of those things, look into certifications; once you get into the Real World (TM), anything less than a master's degree is just a label that tells them where you "belong". Find people that are where you want to be, and get what they have.
Without an image, going only on the description provided, it sounds like we're already seeing this sort of thing.
On several occasions, I've seen a little banner on the top of my TiVo screen during a commercial that says to press the thumbs-up button for more information; pressing the button takes me to a little infomercial area where they can market the product in more depth and detail. It seems like what they're describing is just a slightly different size and form factor, so they can get a better response rate.
This doesn't affect me much anyway, because I see commercials as short films; it's like meta-media, so I tend to watch the commercials rather than fast-forward through them. And besides, TiVo doesn't work well with Comcast's existing cable boxes, so I'd really like the DVR integrated with my cable box; then maybe it could CHANGE THE CHANNEL CORRECTLY. Forking stick-on IR emitters are just garbage.
However, with only *slightly* more education, a disassembly can be examined. If you're smart enough to read a pile of undocumented and largely uncommented C code from multiple unknown authors, you should be smart enough to learn assembly language. It's no more difficult or inconvenient for a developer to learn assembly language than it is for a non-developer to learn C, so if this is too much for you, maybe C is too much for them.
Not to in any way deny the usefulness of open source, but honestly... an option the vast majority of people will never exercise is not really a legitimate option. Just as nobody is going to run out and learn assembly language so they can trace through the Windows kernel, nobody in Brazil is going to go learn C so they can check their source for privacy violations.
Besides, what idiot leaves the offending code in the source? Distribute the originals. That way, you get everybody who doesn't recompile their whole system, whether they read the source or not. Of course, a DISASSEMBLY would still reveal the problem...;)
> The presentation there tries to > reverse-engineer the concept of fun.
I've been an admirer of Raph Koster for a long time, because he's one of a very few people (like Will Wright, Dr. Cat, and JC Lawrence) who are actively thinking about our assumptions related to games and gaming. Raph's particular angle at the moment is to examine what exactly we mean when we say a game is "fun", so the idea of breaking a game into its component atoms isn't so much an end in itself as a mechanism to identify the larger patterns of the game.
Up to the present point in time, when we've examined games, we've done so in macro-fashion: the field of play, the player, the enemy, the avenue of advancement. However, when you start breaking things down to their atomic natures, Raph seems to think (and I tend to agree) that these macro-elements of the game will resolve themselves to a few repeating patterns. Once you have those patterns, you can then examine how combinations of those patterns make a game fun, and how much fun they produce.
I also think Raph is after this for the right reason -- to make games more fun, as opposed to the industry's goal to make more money by determining the "formula" for a hit game. There are some people I *won't* name who are geared in that direction, and while I appreciate the need to look at this angle (the game industry advances by trial-and-error, with each successful game paying the bills for several failures)... I think the question of "what will make more money" is much less interesting than "what will be more fun". I also think "more fun" is more often attached to "more money" than the other way around.
Which is exactly why the kernel source would not be as useful as people think. Which subsystem's source would you really need to debug your specific project? Does it depend on other subsystems? Do those subsystems depend on still more subsystems?
It's not really a problem in terms of Microsoft identifying and packaging up the source (which is probably not all THAT difficult), it's a problem in terms of the developer understanding which packages are needed. The level of complexity is high enough that access to the Windows source probably wouldn't solve your problems, but just give you a whole new set of problems you didn't have before.
To use a weird metaphor, NT is sort of like a sandwich. It's got all these layers, and they're all stacked up together, but none of those layers is the "real" sandwich. When you need to debug the sandwich, you can't get by with just the source to the bologna or the lettuce, you need the source to the whole sandwich -- because the problem might be in the mayonnaise, and even if it isn't you're still going to have to trace through the mayonnaise to get to the bread. That doesn't make it a bad sandwich, it just means you don't have a whole lot of legitimate options to do a partial source release.
Java wants me to write my code in a "properly" object oriented fashion. Unfortunately, I don't like "proper" OO. I think a lot of problems simply don't work well as objects, and you just end up building a complicated ad-hoc infrastructure with the sole purpose of making your problem look like it's composed of objects.
The flaw in this idea is that the resulting solution does not really represent the problem, so extending it requires you to futz around with that infrastructure that makes it look like objects.
The basic dividing line
on
Girls Got Game
·
· Score: 2, Insightful
The essential dividing line between "girl games" and "boy games" has nothing to do with gender, it has to do with ancillary activity. Women *like* ancillary activities. While most men would start a game and just focus on how to make their onscreen persona accomplish the goal, most women prefer to experience the game in much greater detail. But until recent years, we haven't really had much to offer in the way of ancillary activity, because we had to squeeze and strain to get the game's core into the tiny amount of memory we had.
Essentially, older games simply weren't good enough for women to care about them. We're not tapping into some previously unknown market, we're just edging onto the radar of a more discerning consumer.
> many of the "magic incantations" > currently required would start to > make more sense.
I think if you start back-stepping through Windows driver development until you get back to the 3.0 days, it *will* make sense. Backward compatibility is the primary reason for this sort of magic; when you develop a Windows device driver, it has to stand a reasonable chance of working with all properly-designed Windows apps from the last two decades, or people get upset. A lot of arcana got carried forth from the previous versions of Windows, and some of it just can't be abstracted into anything easier.
On the bright side, this is why you can play old games from a USB thumb drive. Sure, they had to jump through some extra hoops to write the driver, but I tend to think it was worth it.
As far as kernel source not making a distribution, Windows is pretty monolithic. Unlike Linux, where most of your system is isolated in small stand-alone utilities, pretty much everything in Windows is woven together such that it would be a nightmare to try and untangle it. Longhorn may start to address this, but it's an architectural condition that can't really be resolved without making some major changes to the O/S.
I'd be interested in seeing how well this sort of thing works with procedural code, e.g. the overview descriptions you might write as a comment in a function body before you start writing the "real" function. I don't see a lot of productive stuff coming out of this as it stands now... nouns turn into classes and verbs turn into methods, but that seems to be about it.
I'd recommend going with some established solution that fits your budget. Rolling your own is likely to expose your users to all kinds of subtle security issues that could result in some nefarious jerk getting their credit card numbers or the like.
A creative solution I heard once was to auction "thanks" on eBay. For $2.50, you could buy the seller's "thanks", and you could buy as many (or as few) as you liked through the usual Dutch auction process. I don't know if anyone ever actually did this, but you might want to consider it.
Personally, I always use PayPal for website donations. I've never had anyone object.
> Why would we need sony music at > ALL if bands can sell their albums > directly to you?
This is just an idea, but a major label could start to think of itself as an exclusive "club" of sorts, where they use their economies of scale to get discounted rates on things musicians need. In return, you just pay a (large) monthly fee and hand over X% of your sales revenue.
This would look and feel a lot like what labels do today, but the label would be unable to hold an artist or his music "hostage" by failing to market and promote it.
I find it strange that they say "fully compliant". What if you create a document that is NOT fully compliant? Maybe that substitutes one tag for another? You'd probably need a lawyer to answer that question, but it's an interesting question.
> what is in GPL3 thats causing > all the commotion
Possibility.
Knowing that there will be a GPL v3, there are many people screaming of doom and gloom, because it could be TERRIBLE! It's POSSIBLE that RMS could do HORRIBLE things, just look at this protracted convoluted example! WE'RE ALL GOING TO DIE! DIE OR GO TO JAIL! OR BOTH! And then the philosophers will starve and you'll have to reboot.
Of course, if you like the GPL v2, chances are you're going to like the GPL v3. It's probably not going to be that different. The GPL exists and goes through versions primarily to keep the lawyers happy, not to push us into a trap.
On the other hand, if you think the GPL v2 *is* a trap, v3 will be pretty much the same trap. Meet the new boss, and all that.
From my perspective, a security *vulnerability* isn't a feature, it's a bug. So while you're completely right about bugs... the user has direct recourse on Linux, but none on Windows... my initial statement still stands. A feature (in the absence of bugs) is not insecure, unless and until it is *used* in an insecure manner.
It's a case of the system violating users' expectations; when the system surprises the user with unexpected behavior, the problem might be in the system, or it might be in the user's expectations. For some reason, we forget about this dual possibility and lump *everything* on Linux into flawed user expectations, while we lump everything on Windows into a flawed system.
It seems to me that we do this because historically, most Linux "flaws" are user error, while most Windows "flaws" are apparently not. I certainly don't think it's *wrong* to blame the user on Linux or the system on Windows, if that is indeed where the problem lies; I just think it's wrong to assume the problem lies there before undertaking any examination at all.
Because large projects live in large directory structures, and there's usually not a single makefile that can "clean" all of them. I commonly have close to a gig of.o files living in subdirectories off my home.
I keep promising myself that I'm going to write a script to ferret out makefiles and "make clean" in that directory, but it's SO much faster to "rm -rf *.o", and... um... I don't always do makefiles. Sometimes I just stick my compilation command line in a file and type `cat [whatever]` at the prompt. Now pardon me while I run and hide from the outraged mob.;)
> inverse is the word that properly > describes this relationship
Only if you're willing to accept an *additive* inverse relationship (as with +5 and -5), which doesn't accurately reflect an important component of the multiplicative inverse (reciprocal): as the imbalance between one side and the other grows, so too does the imbalance in the effect of changes. Thus, once the balance is skewed one way or the other, it takes large reductions in what you have to achieve what you lack.
This makes changes in the status quo very difficult, so I think it's a lot closer to what we see in the real world -- e.g. with Linux trying to gain a foothold in the desktop market or Microsoft trying to secure Windows. The situation improves as balance is approached, but in the beginning you're investing a lot of time and energy for nearly insignificant benefits while suffering what seem like massive losses. The converse applies, as well: when you enhance your existing strength, it's very easy to achieve big gains for comparatively tiny losses.
Realistically, "reciprocal" isn't exactly correct either, but IMO it seems closer.
There is an old saying: UNIX doesn't stop you from doing stupid things, because that would stop you from doing clever things.
We used to complain that you couldn't do clever things on Windows. Now we're complaining that you can do stupid things on Windows.
Meanwhile, Linux continues happily letting people do even stupider things, and whenever these people complain -- we respond that it's their own stupid fault for not being smarter.
So why is it always the user's fault on Linux, but always Microsoft's fault on Windows? It seems to me that all the recent email worms need some dumbass to actually RUN THE PROGRAM. On Linux, we would say this user was stupid. But on Windows, this user was victimised by Microsoft's insecure operating system? I don't think so.
Security is the reciprocal of convenience, and the developer is simply unqualified to determine what security I need and what convenience I don't.
> The variety of different groups of > people here is enough that you should > be able to find some element that you > like.
But vast numbers of people don't tend to distinguish themselves. They tend to homogenise, and then ATTEMPT to distinguish themselves (largely unsuccessfully). While every Linux user group is, indeed, different... they all LOOK the same from the outside. This makes it very difficult to figure out which one is going to have the smart and friendly people who can help you with your problems, and which one is the local chapter of the open source thumb-up-ass brigade.
> it's impossible to generalize > about the entire group
It's impossible NOT to generalise. How can you productively discuss the community of Linux users without generalities? There are too many of us, as you've just pointed out yourself.
Like spammers, marketers are laboring under the delusion that the only reason you haven't bought their crap is because you simply do not know about it. The idea that you may know all about it and not WANT it... well, that's an alien concept to them. They are absolutely convinced that if you don't want it, you must not understand it.
Since I think DRM is the enabling technology that gives a lot of old-school media people the warm fuzzies they need to put things out in digital format at all, I have a love/hate relationship with it. I love that people will give me SOME access to things in digital format as long as they can control it with DRM, but I hate that these people don't tend to have a forking clue what kind of control they really need.
I think the best way to handle DRM is to ignore it entirely. Some artists are scared that we want to steal their work and not pay them for it, and when we whine about DRM, they think that's really what we're complaining about. They aren't clueful about how DRM really does make our lives more difficult, so they think we have a problem with DRM because we're trying to steal their work and we can't.
That gives them two dangerous messages: first, that the world really *is* full of pirates and thieves; and second, that DRM really is stopping piracy. DRM is only going to go away when these artists feel secure in the idea that they can put out unprotected work and still get paid for it.
Of course, that's how they always did things, but somehow they think the rules have changed somewhere along the line.
This IS an elegant solution. Here is data on a machine that is hard to script. There is a machine that is easy to script. I need to write a script to analyse this data. Which is more elegant: sending the data to the other machine, or scripting the existing one? Looks pretty obvious to me.
Bandwidth is cheap. Machines are cheap. Programmers scripting an architecture they don't like, on the other hand -- that's expensive.
Whining about how hard it is to do things also tends to waste valuable time you could spend doing it.
> you choose what operating system you use > by how much you like other people using it?
In the case of Linux, those other people are your support channel. This is one of the many things that makes open source different. In the commercial arena, if I don't like a company's support channel, they aren't going to sell me anything. So if you don't like the users of some open source project, the same sort of decision ought to fall out of that.
Here on my desk I have a nice, friendly, responsive Windows machine.
Over in a high-availability datacenter hooked into fat network pipes, I have three Linux servers.
Why, exactly, do I need to automate something on my Windows box? I can much more easily tell my desktop PC to send the data to a Linux box, which I can script like there's no tomorrow. The results can then be sent back to me, and I can look at them right here on my Windows desktop.
So what's the problem? Just like when I'm logged into my Linux machine and I get an attachment in MS Word format, I simply forward the mail and turn to my Windows machine to open it. And if I ever see the need, I'll happily drop a Mac on the desktop next to my Windows box. We're NETWORKED, people. There's simply no reason to pursue homogeneity anymore.
Slashdot Mirror
CS is about being able to advance the state of the art. It's related to IT in very much the same way physics is related to auto mechanics: you need to understand *some* physics to be any good at auto mechanics, but you're not going to be up for a Nobel prize anytime soon, and you'll probably stand there like a deer in headlights if people start trotting out Maxwell's equations.
However, most people who study CS and get degrees in the field are really not all that different from before they got the degree. CS, like most other sciences, is not very useful at the baccalaureate level; it only begins to have real application to real tasks once you get into the graduate level, and it doesn't come into its own until you get deeply into the post-graduate work. (Nobody is impressed by a bachelor's in physics or biology, either; strangely enough, I meet a lot of bartenders that have those.)
So if you're not planning to go for the doctorate, target the general area where you want to work: CS people are usually at a desk creating software, and IT people are usually in the basement monitoring hardware. If you don't really like either of those things, look into certifications; once you get into the Real World (TM), anything less than a master's degree is just a label that tells them where you "belong". Find people that are where you want to be, and get what they have.
Now that I've seen that, I suddenly have to wrestle with the fundamental insanity of having FOND MEMORIES about COBOL.
Why couldn't you have just left well enough alone, so I could keep happily despising it?
Next thing you know, I'll be pining away for OS/390 JCL.
Without an image, going only on the description provided, it sounds like we're already seeing this sort of thing.
On several occasions, I've seen a little banner on the top of my TiVo screen during a commercial that says to press the thumbs-up button for more information; pressing the button takes me to a little infomercial area where they can market the product in more depth and detail. It seems like what they're describing is just a slightly different size and form factor, so they can get a better response rate.
This doesn't affect me much anyway, because I see commercials as short films; it's like meta-media, so I tend to watch the commercials rather than fast-forward through them. And besides, TiVo doesn't work well with Comcast's existing cable boxes, so I'd really like the DVR integrated with my cable box; then maybe it could CHANGE THE CHANNEL CORRECTLY. Forking stick-on IR emitters are just garbage.
> With closed source, they have no such option.
;)
However, with only *slightly* more education, a disassembly can be examined. If you're smart enough to read a pile of undocumented and largely uncommented C code from multiple unknown authors, you should be smart enough to learn assembly language. It's no more difficult or inconvenient for a developer to learn assembly language than it is for a non-developer to learn C, so if this is too much for you, maybe C is too much for them.
Not to in any way deny the usefulness of open source, but honestly... an option the vast majority of people will never exercise is not really a legitimate option. Just as nobody is going to run out and learn assembly language so they can trace through the Windows kernel, nobody in Brazil is going to go learn C so they can check their source for privacy violations.
Besides, what idiot leaves the offending code in the source? Distribute the originals. That way, you get everybody who doesn't recompile their whole system, whether they read the source or not. Of course, a DISASSEMBLY would still reveal the problem...
> The presentation there tries to
> reverse-engineer the concept of fun.
I've been an admirer of Raph Koster for a long time, because he's one of a very few people (like Will Wright, Dr. Cat, and JC Lawrence) who are actively thinking about our assumptions related to games and gaming. Raph's particular angle at the moment is to examine what exactly we mean when we say a game is "fun", so the idea of breaking a game into its component atoms isn't so much an end in itself as a mechanism to identify the larger patterns of the game.
Up to the present point in time, when we've examined games, we've done so in macro-fashion: the field of play, the player, the enemy, the avenue of advancement. However, when you start breaking things down to their atomic natures, Raph seems to think (and I tend to agree) that these macro-elements of the game will resolve themselves to a few repeating patterns. Once you have those patterns, you can then examine how combinations of those patterns make a game fun, and how much fun they produce.
I also think Raph is after this for the right reason -- to make games more fun, as opposed to the industry's goal to make more money by determining the "formula" for a hit game. There are some people I *won't* name who are geared in that direction, and while I appreciate the need to look at this angle (the game industry advances by trial-and-error, with each successful game paying the bills for several failures)... I think the question of "what will make more money" is much less interesting than "what will be more fun". I also think "more fun" is more often attached to "more money" than the other way around.
Which is exactly why the kernel source would not be as useful as people think. Which subsystem's source would you really need to debug your specific project? Does it depend on other subsystems? Do those subsystems depend on still more subsystems?
It's not really a problem in terms of Microsoft identifying and packaging up the source (which is probably not all THAT difficult), it's a problem in terms of the developer understanding which packages are needed. The level of complexity is high enough that access to the Windows source probably wouldn't solve your problems, but just give you a whole new set of problems you didn't have before.
To use a weird metaphor, NT is sort of like a sandwich. It's got all these layers, and they're all stacked up together, but none of those layers is the "real" sandwich. When you need to debug the sandwich, you can't get by with just the source to the bologna or the lettuce, you need the source to the whole sandwich -- because the problem might be in the mayonnaise, and even if it isn't you're still going to have to trace through the mayonnaise to get to the bread. That doesn't make it a bad sandwich, it just means you don't have a whole lot of legitimate options to do a partial source release.
Dammit, now I want a sandwich.
Java wants me to write my code in a "properly" object oriented fashion. Unfortunately, I don't like "proper" OO. I think a lot of problems simply don't work well as objects, and you just end up building a complicated ad-hoc infrastructure with the sole purpose of making your problem look like it's composed of objects.
The flaw in this idea is that the resulting solution does not really represent the problem, so extending it requires you to futz around with that infrastructure that makes it look like objects.
The essential dividing line between "girl games" and "boy games" has nothing to do with gender, it has to do with ancillary activity. Women *like* ancillary activities. While most men would start a game and just focus on how to make their onscreen persona accomplish the goal, most women prefer to experience the game in much greater detail. But until recent years, we haven't really had much to offer in the way of ancillary activity, because we had to squeeze and strain to get the game's core into the tiny amount of memory we had.
Essentially, older games simply weren't good enough for women to care about them. We're not tapping into some previously unknown market, we're just edging onto the radar of a more discerning consumer.
> many of the "magic incantations"
> currently required would start to
> make more sense.
I think if you start back-stepping through Windows driver development until you get back to the 3.0 days, it *will* make sense. Backward compatibility is the primary reason for this sort of magic; when you develop a Windows device driver, it has to stand a reasonable chance of working with all properly-designed Windows apps from the last two decades, or people get upset. A lot of arcana got carried forth from the previous versions of Windows, and some of it just can't be abstracted into anything easier.
On the bright side, this is why you can play old games from a USB thumb drive. Sure, they had to jump through some extra hoops to write the driver, but I tend to think it was worth it.
As far as kernel source not making a distribution, Windows is pretty monolithic. Unlike Linux, where most of your system is isolated in small stand-alone utilities, pretty much everything in Windows is woven together such that it would be a nightmare to try and untangle it. Longhorn may start to address this, but it's an architectural condition that can't really be resolved without making some major changes to the O/S.
I'd be interested in seeing how well this sort of thing works with procedural code, e.g. the overview descriptions you might write as a comment in a function body before you start writing the "real" function. I don't see a lot of productive stuff coming out of this as it stands now... nouns turn into classes and verbs turn into methods, but that seems to be about it.
I'd recommend going with some established solution that fits your budget. Rolling your own is likely to expose your users to all kinds of subtle security issues that could result in some nefarious jerk getting their credit card numbers or the like.
A creative solution I heard once was to auction "thanks" on eBay. For $2.50, you could buy the seller's "thanks", and you could buy as many (or as few) as you liked through the usual Dutch auction process. I don't know if anyone ever actually did this, but you might want to consider it.
Personally, I always use PayPal for website donations. I've never had anyone object.
> Why would we need sony music at
> ALL if bands can sell their albums
> directly to you?
This is just an idea, but a major label could start to think of itself as an exclusive "club" of sorts, where they use their economies of scale to get discounted rates on things musicians need. In return, you just pay a (large) monthly fee and hand over X% of your sales revenue.
This would look and feel a lot like what labels do today, but the label would be unable to hold an artist or his music "hostage" by failing to market and promote it.
I find it strange that they say "fully compliant". What if you create a document that is NOT fully compliant? Maybe that substitutes one tag for another? You'd probably need a lawyer to answer that question, but it's an interesting question.
> what is in GPL3 thats causing
> all the commotion
Possibility.
Knowing that there will be a GPL v3, there are many people screaming of doom and gloom, because it could be TERRIBLE! It's POSSIBLE that RMS could do HORRIBLE things, just look at this protracted convoluted example! WE'RE ALL GOING TO DIE! DIE OR GO TO JAIL! OR BOTH! And then the philosophers will starve and you'll have to reboot.
Of course, if you like the GPL v2, chances are you're going to like the GPL v3. It's probably not going to be that different. The GPL exists and goes through versions primarily to keep the lawyers happy, not to push us into a trap.
On the other hand, if you think the GPL v2 *is* a trap, v3 will be pretty much the same trap. Meet the new boss, and all that.
From my perspective, a security *vulnerability* isn't a feature, it's a bug. So while you're completely right about bugs... the user has direct recourse on Linux, but none on Windows... my initial statement still stands. A feature (in the absence of bugs) is not insecure, unless and until it is *used* in an insecure manner.
It's a case of the system violating users' expectations; when the system surprises the user with unexpected behavior, the problem might be in the system, or it might be in the user's expectations. For some reason, we forget about this dual possibility and lump *everything* on Linux into flawed user expectations, while we lump everything on Windows into a flawed system.
It seems to me that we do this because historically, most Linux "flaws" are user error, while most Windows "flaws" are apparently not. I certainly don't think it's *wrong* to blame the user on Linux or the system on Windows, if that is indeed where the problem lies; I just think it's wrong to assume the problem lies there before undertaking any examination at all.
> Why would you rm -r .o files?
.o files living in subdirectories off my home.
;)
Because large projects live in large directory structures, and there's usually not a single makefile that can "clean" all of them. I commonly have close to a gig of
I keep promising myself that I'm going to write a script to ferret out makefiles and "make clean" in that directory, but it's SO much faster to "rm -rf *.o", and... um... I don't always do makefiles. Sometimes I just stick my compilation command line in a file and type `cat [whatever]` at the prompt. Now pardon me while I run and hide from the outraged mob.
> Linux does let you do incredibly
> stupid things, but only as root.
So if I type "rm -rf *>o" in my home directory, instead of "rm -rf *.o" like I intended, nothing happens unless I'm root?
Just because it didn't ruin YOUR day doesn't mean it wasn't stupid.
> inverse is the word that properly
> describes this relationship
Only if you're willing to accept an *additive* inverse relationship (as with +5 and -5), which doesn't accurately reflect an important component of the multiplicative inverse (reciprocal): as the imbalance between one side and the other grows, so too does the imbalance in the effect of changes. Thus, once the balance is skewed one way or the other, it takes large reductions in what you have to achieve what you lack.
This makes changes in the status quo very difficult, so I think it's a lot closer to what we see in the real world -- e.g. with Linux trying to gain a foothold in the desktop market or Microsoft trying to secure Windows. The situation improves as balance is approached, but in the beginning you're investing a lot of time and energy for nearly insignificant benefits while suffering what seem like massive losses. The converse applies, as well: when you enhance your existing strength, it's very easy to achieve big gains for comparatively tiny losses.
Realistically, "reciprocal" isn't exactly correct either, but IMO it seems closer.
Features are not insecure, users are insecure.
There is an old saying: UNIX doesn't stop you from doing stupid things, because that would stop you from doing clever things.
We used to complain that you couldn't do clever things on Windows. Now we're complaining that you can do stupid things on Windows.
Meanwhile, Linux continues happily letting people do even stupider things, and whenever these people complain -- we respond that it's their own stupid fault for not being smarter.
So why is it always the user's fault on Linux, but always Microsoft's fault on Windows? It seems to me that all the recent email worms need some dumbass to actually RUN THE PROGRAM. On Linux, we would say this user was stupid. But on Windows, this user was victimised by Microsoft's insecure operating system? I don't think so.
Security is the reciprocal of convenience, and the developer is simply unqualified to determine what security I need and what convenience I don't.
> The variety of different groups of
> people here is enough that you should
> be able to find some element that you
> like.
But vast numbers of people don't tend to distinguish themselves. They tend to homogenise, and then ATTEMPT to distinguish themselves (largely unsuccessfully). While every Linux user group is, indeed, different... they all LOOK the same from the outside. This makes it very difficult to figure out which one is going to have the smart and friendly people who can help you with your problems, and which one is the local chapter of the open source thumb-up-ass brigade.
> it's impossible to generalize
> about the entire group
It's impossible NOT to generalise. How can you productively discuss the community of Linux users without generalities? There are too many of us, as you've just pointed out yourself.
Like spammers, marketers are laboring under the delusion that the only reason you haven't bought their crap is because you simply do not know about it. The idea that you may know all about it and not WANT it... well, that's an alien concept to them. They are absolutely convinced that if you don't want it, you must not understand it.
Since I think DRM is the enabling technology that gives a lot of old-school media people the warm fuzzies they need to put things out in digital format at all, I have a love/hate relationship with it. I love that people will give me SOME access to things in digital format as long as they can control it with DRM, but I hate that these people don't tend to have a forking clue what kind of control they really need.
I think the best way to handle DRM is to ignore it entirely. Some artists are scared that we want to steal their work and not pay them for it, and when we whine about DRM, they think that's really what we're complaining about. They aren't clueful about how DRM really does make our lives more difficult, so they think we have a problem with DRM because we're trying to steal their work and we can't.
That gives them two dangerous messages: first, that the world really *is* full of pirates and thieves; and second, that DRM really is stopping piracy. DRM is only going to go away when these artists feel secure in the idea that they can put out unprotected work and still get paid for it.
Of course, that's how they always did things, but somehow they think the rules have changed somewhere along the line.
> Ever heard of elegant solutions ?
This IS an elegant solution. Here is data on a machine that is hard to script. There is a machine that is easy to script. I need to write a script to analyse this data. Which is more elegant: sending the data to the other machine, or scripting the existing one? Looks pretty obvious to me.
Bandwidth is cheap. Machines are cheap. Programmers scripting an architecture they don't like, on the other hand -- that's expensive.
Whining about how hard it is to do things also tends to waste valuable time you could spend doing it.
> you choose what operating system you use
> by how much you like other people using it?
In the case of Linux, those other people are your support channel. This is one of the many things that makes open source different. In the commercial arena, if I don't like a company's support channel, they aren't going to sell me anything. So if you don't like the users of some open source project, the same sort of decision ought to fall out of that.
Here on my desk I have a nice, friendly, responsive Windows machine. Over in a high-availability datacenter hooked into fat network pipes, I have three Linux servers. Why, exactly, do I need to automate something on my Windows box? I can much more easily tell my desktop PC to send the data to a Linux box, which I can script like there's no tomorrow. The results can then be sent back to me, and I can look at them right here on my Windows desktop. So what's the problem? Just like when I'm logged into my Linux machine and I get an attachment in MS Word format, I simply forward the mail and turn to my Windows machine to open it. And if I ever see the need, I'll happily drop a Mac on the desktop next to my Windows box. We're NETWORKED, people. There's simply no reason to pursue homogeneity anymore.