Interesting points. Another thing is that mass variation is one of the things which is opposing Linux being accepted en masse as a desktop operating system - you can't teach someone to simply "use Linux", in general. Pros and cons to anything, I guess.
Although your assertion about open-source is correct, it has the same common failing that a lot of advocacy of open source does - open source is mostly beneficial when one is willing to spend time and effort to modify code. While on the side of code maintenance this is fantastic, everyone benefits from a few volunteer patch coders, making ones own service implementation by modifying source so it doesn't behave as the core system it's based upon is, in the real world, almost always going to be the work of a hobbyist. A real production server is unlikely to see a benefit due to this.
Bear in mind, also, that many world-exposed open source services (ssh, Apache, etc.) are available on Windows as well as Linux. Your point is completely valid, though, and you do allude to all the difficulties I'm saying in your second paragraph there.
This is the thing, though. Open source software has many, many benefits, but I feel that a lot of them are overstated in many contexts. For the average home user, the benefit of open source is not that they can tweak the code - most won't know the first thing about coding - it's a combination of the price and the fact that there are so many people maintaining the software (although this study depreciates the benefits of the second somewhat). Don't get me wrong, I'm all for Linux on the desktop (still not sure it's ready, but it's making leaps and bounds at present), I just feel a lot of open source advocates aren't really marketing it for desktop use as well as they might be.
That's the real root of the problem right there - not everyone's a network admin, but most people are expecting to be able to do a lot of the things that only network admins were doing just a few years ago. Functionality vs. security is theoretically always a balancing act, and the sad fact is that people are always going to be tricked into lowering their guard. Although a lot of the people in this thread have been decrying how Linux can be made more secure, default security is, by far, the best benchmark for the home user.
However, the fact that the tests were done in a server environment kinda ruins that...
A completely secure system would be completely useless -- there's a balancing act here. Adware could be wiped out by not allowing people to install programs (or by blocking all outgoing internet traffic), but it's just not a good compromise.
I like the idea of computers being able to automatically manage their own security a little more, but in the end the most successful attacks are usually those which just trick people. Look at email viruses.
What if you re-encode back to the original WMA (I assume) form, sans DRM?
This hack works by "playing" the media file into a raw audio format then recoding, so theoretically there'd still be significant loss, unless you could find some way to systematically determine how the file was originally encoded (which I don't think is possible). It's similar to plugging your speakers socket into your line-in, then recording that, except without converting to analogue in the mean time.
Yeah, I've seen it, but their main problems have generally never lasted longer than a few hours (I think the largest problem was with the launch of HL2, but I did use Steam until a couple of months prior to that since I was behind a University proxy - and lack of proxy support is something I was upset about). It just seems to me that any online system is bound to have server issues from time to time.
The offline facility has served me well in the past, though. The only gotcha is the case where you are mid-update and lose connectivity with Steam (which, for the record, has never happened to me), where you cannot play again until you reconnect and get the update. I believe this is where the acronym YMMV comes in, though.
I wouldn't refer to Steam as evil. Not by a long shot. It perhaps made the "everyone has internet access" assumption before it was strictly true, but it's not like "Internet Access" isn't listed on the system requirements. It's a fine system.
I just really think that if you are going to have someone in a role to do a comparison right, you really want a person with deep technical understanding in that role to really understand any comparison at a deep level.
I'm not sure I agree with that - I think a less-technical user would possibly even reduce the chance of the "creeping support" you mention later on. He's not the one doing the comparison, he hires third-parties to execute the comparisons. As a less-technical user, he gets them to explain what they mean, and he's basically dependant upon that. A technical user could play with the numbers somewhat without fear of being found out - a non-technical user doesn't know the relevance of playing with one metric over another.
And to organise and co-ordinate testing, you really want someone with good skills in organising and co-ordinating testing, rather than a technical computer user. He tells them he wants a comparison of TCO, and the third-party (presumably) decides what the best way to go about that would be.
The spyware thing you mention at the end is an oft-cited argument, but I'm not convinced it's relevant here - XP just isn't going to get that kind of overhaul any time soon. It breaks too much existing software. It will be more interesting to see what they do to address this in Longhorn.
Case-sensitive is just the way computers are. If you see two different characters, the computer is representing them internally as different things, at least until it's interpreted them. Case-insensitivity can have a huge processing cost (particularly when working with data), now that so many things are done in Unicode. Not to mention that it's just not relevant in some languages.
But yes, it is treating the computer well in favour of the user, which is in general bad form. I don't believe that CamelCase is "the only" argument against case-insensitivity in any way, shape, or form.
I don't so much disagree as think it depends on your perspective. C and C++ both were, and both remain, excellent at what they were designed for: being a portable assembly language and being a powerful systems programming language for skilled programmers, respectively. They also have niche uses elsewhere, such as writing high-performance libraries that use a lot of maths (3D graphics, for example). The problems started when they became popular for other tasks -- notably application programming by non-expert developers -- because there wasn't a lot of choice. Today there is, and it's more important now to choose the right tool for the job.
Good point, well made. That's very close to what I was trying to say.
The unreal games are fantastic for their modularity - in Windows, they can be configured to use any one of several renderers (DX, OGL and a few proprietary ones which have probably disappeared now). A lot of places don't see the benefit in implementing such an abstraction layer, though. A real pity.
Indeed. But going into the nitty-gritty details of things like this when trying to explain to someone who's just confused seemed a little bit counter-productive....
Wikipedia's a very useful thing to link to in case people want in-depth knowledge. Today, I didn't have to Google search to find answers, though, since I study this stuff (ironically, I posted that answer while I should've been in a lecture about computational complexity).
Heh, I don't know why I went off on one there, actually -- now I've R'd TFA, all this distinction between FSMs and suchlike are nearly completely pointless. Blast!
You do get space-bounded TMs, though, and they're more sensible things to be dealing with when working with results about computation. Although making a space-bounded UTM implementation with a train set that actually accepted usefully-sized programs would be completely impractical...
Finite State Machines, however, are useless as models of computation when you're treating them in that way. True, you can theoretically model any physical computation device with an FSM (albeit one with billions of states, even for the most simple systems which allow arbitrary computation), there is a difference between being a simple regular language acceptor and being Turing Complete.
A Turing Machine is a simple model of computation that encompasses anything that can be computed by a computer. The strongest claim about the ability of a programming language is that it's "Turing Complete", which means that anything that can be computed on a Turing Machine can be computed in a language. Turing Machines are designed to be very simple, and they're good for theoretical things about computer science.
A Universal Turing Machine is a Turing Machine that takes, as its input, an encoding of another Turing Machine, then simulates it. As such, you can prove that with a Turing Machine, you can compute anything that any other Turing Machine can.
By contrast, Finite State Machines, or Finite Automata, are far less complex models of computation. If you treat them as language acceptors (i.e., everything that they compute is whether or not a string is valid in a language) they are only as powerful as simple regular expressions. They can be modelled very quickly by computers, though, since they are deterministic and require no lookahead.
Hopefully C will be being phased out with most applications that don't require break-neck speed or legacy compatibility, in favour of more modern languages. I know some people disagree on this, but C and C++ are, in my eyes, not so useful as they once were. The performance gain in older languages in most cases really doesn't justify the productivity loss.
I agree 100% about Javascript, though. I've been using it (I write Mozilla extensions from time-to-time) and it feels like being forced through a thin mesh screen. Urgh.
2. SDL. Truly, either you've never used Linux or you've lived in a cave for the past ten years to never have heard about it.
I heard somewhere that the biggest problem with SDL is that it's designed to be simple, so a lot of more-advanced functionality simply isn't present. Is there any truth to that?
All this competition leading to superior services for the end-user is sickening me. How am I supposed to be jaded and skeptical about capitalism when it's working?
Slashdot Mirror
Interesting points. Another thing is that mass variation is one of the things which is opposing Linux being accepted en masse as a desktop operating system - you can't teach someone to simply "use Linux", in general. Pros and cons to anything, I guess.
Although your assertion about open-source is correct, it has the same common failing that a lot of advocacy of open source does - open source is mostly beneficial when one is willing to spend time and effort to modify code. While on the side of code maintenance this is fantastic, everyone benefits from a few volunteer patch coders, making ones own service implementation by modifying source so it doesn't behave as the core system it's based upon is, in the real world, almost always going to be the work of a hobbyist. A real production server is unlikely to see a benefit due to this.
Bear in mind, also, that many world-exposed open source services (ssh, Apache, etc.) are available on Windows as well as Linux. Your point is completely valid, though, and you do allude to all the difficulties I'm saying in your second paragraph there.
This is the thing, though. Open source software has many, many benefits, but I feel that a lot of them are overstated in many contexts. For the average home user, the benefit of open source is not that they can tweak the code - most won't know the first thing about coding - it's a combination of the price and the fact that there are so many people maintaining the software (although this study depreciates the benefits of the second somewhat). Don't get me wrong, I'm all for Linux on the desktop (still not sure it's ready, but it's making leaps and bounds at present), I just feel a lot of open source advocates aren't really marketing it for desktop use as well as they might be.
That's the real root of the problem right there - not everyone's a network admin, but most people are expecting to be able to do a lot of the things that only network admins were doing just a few years ago. Functionality vs. security is theoretically always a balancing act, and the sad fact is that people are always going to be tricked into lowering their guard. Although a lot of the people in this thread have been decrying how Linux can be made more secure, default security is, by far, the best benchmark for the home user.
However, the fact that the tests were done in a server environment kinda ruins that...
A completely secure system would be completely useless -- there's a balancing act here. Adware could be wiped out by not allowing people to install programs (or by blocking all outgoing internet traffic), but it's just not a good compromise.
I like the idea of computers being able to automatically manage their own security a little more, but in the end the most successful attacks are usually those which just trick people. Look at email viruses.
Indeed.
Mass culling it is, then.
Yeah, I've seen it, but their main problems have generally never lasted longer than a few hours (I think the largest problem was with the launch of HL2, but I did use Steam until a couple of months prior to that since I was behind a University proxy - and lack of proxy support is something I was upset about). It just seems to me that any online system is bound to have server issues from time to time.
The offline facility has served me well in the past, though. The only gotcha is the case where you are mid-update and lose connectivity with Steam (which, for the record, has never happened to me), where you cannot play again until you reconnect and get the update. I believe this is where the acronym YMMV comes in, though.
I wouldn't refer to Steam as evil. Not by a long shot. It perhaps made the "everyone has internet access" assumption before it was strictly true, but it's not like "Internet Access" isn't listed on the system requirements. It's a fine system.
Page five of this has a pretty graph, seems reasonably legit (although it's only certain sources of emissions, I think it covers the major ones).
I doubt it'll be there by default, but I guess it could theoretically be added as an extension/plugin (as is the form it exists in Firefox).
And to organise and co-ordinate testing, you really want someone with good skills in organising and co-ordinating testing, rather than a technical computer user. He tells them he wants a comparison of TCO, and the third-party (presumably) decides what the best way to go about that would be.
The spyware thing you mention at the end is an oft-cited argument, but I'm not convinced it's relevant here - XP just isn't going to get that kind of overhaul any time soon. It breaks too much existing software. It will be more interesting to see what they do to address this in Longhorn.
Yes, it can be represented as an FSM. It's just useless like that. The context is not useful here...
Case-sensitive is just the way computers are. If you see two different characters, the computer is representing them internally as different things, at least until it's interpreted them. Case-insensitivity can have a huge processing cost (particularly when working with data), now that so many things are done in Unicode. Not to mention that it's just not relevant in some languages.
There's a good quote about this in an explanation about why XML is case-sensitive.
But yes, it is treating the computer well in favour of the user, which is in general bad form. I don't believe that CamelCase is "the only" argument against case-insensitivity in any way, shape, or form.
The unreal games are fantastic for their modularity - in Windows, they can be configured to use any one of several renderers (DX, OGL and a few proprietary ones which have probably disappeared now). A lot of places don't see the benefit in implementing such an abstraction layer, though. A real pity.
Indeed. But going into the nitty-gritty details of things like this when trying to explain to someone who's just confused seemed a little bit counter-productive....
I'm not sure I understand what you mean!
Wikipedia's a very useful thing to link to in case people want in-depth knowledge. Today, I didn't have to Google search to find answers, though, since I study this stuff (ironically, I posted that answer while I should've been in a lecture about computational complexity).
Nice! I guess the main problem now is finding the "best ones" for developers to use.
Heh, I don't know why I went off on one there, actually -- now I've R'd TFA, all this distinction between FSMs and suchlike are nearly completely pointless. Blast!
You do get space-bounded TMs, though, and they're more sensible things to be dealing with when working with results about computation. Although making a space-bounded UTM implementation with a train set that actually accepted usefully-sized programs would be completely impractical...
Finite State Machines, however, are useless as models of computation when you're treating them in that way. True, you can theoretically model any physical computation device with an FSM (albeit one with billions of states, even for the most simple systems which allow arbitrary computation), there is a difference between being a simple regular language acceptor and being Turing Complete.
A Turing Machine is a simple model of computation that encompasses anything that can be computed by a computer. The strongest claim about the ability of a programming language is that it's "Turing Complete", which means that anything that can be computed on a Turing Machine can be computed in a language. Turing Machines are designed to be very simple, and they're good for theoretical things about computer science.
A Universal Turing Machine is a Turing Machine that takes, as its input, an encoding of another Turing Machine, then simulates it. As such, you can prove that with a Turing Machine, you can compute anything that any other Turing Machine can.
By contrast, Finite State Machines, or Finite Automata, are far less complex models of computation. If you treat them as language acceptors (i.e., everything that they compute is whether or not a string is valid in a language) they are only as powerful as simple regular expressions. They can be modelled very quickly by computers, though, since they are deterministic and require no lookahead.
Hopefully C will be being phased out with most applications that don't require break-neck speed or legacy compatibility, in favour of more modern languages. I know some people disagree on this, but C and C++ are, in my eyes, not so useful as they once were. The performance gain in older languages in most cases really doesn't justify the productivity loss.
I agree 100% about Javascript, though. I've been using it (I write Mozilla extensions from time-to-time) and it feels like being forced through a thin mesh screen. Urgh.
All this competition leading to superior services for the end-user is sickening me. How am I supposed to be jaded and skeptical about capitalism when it's working?