And we are often told, time and time again, that fixed up-front costs are amortizable and actually don't factor as highly into TOC as do contractual costs such as support.
There will typically be a simple open source solution for what they are peddling that will save you enough to employ plenty of internal support.
Agreed and this is what I was saying... except for most organizations that care about what they do, there is no option of not purchasing both support or not employing internal support. So those are what I figured into the cost of what I was saying. I guess you could argue that both support and internal support are not required. I'll argue that they are. And, if they are, then, even by your own post, you agree that the end costs will be similar.
I haven't seen much detail as to what they'll be watching anyway. Will they be able to effectively do anything at all? Will they be technical enough to examine logs and databases? Will that even matter since someone with the approproiate skills/access can alter those anyway? What will the makeup of the group be? Having them all from BoB, for example, will accomplish nothing most likely and will not foster any good PR.
Right, because we have to assume it's just as good to pay up front and pay support as it is to just pay support.
I have no idea how you got that from my post. I only mention support contracts and in-house support staff as possibilities. This isn't much different from closed source practice other than the up-front-cost as you mention. Because of this, there will likely be little actual monitary savings. It isn't like they will download everything for free and not have some kind of support for it, which would be a fantastically insane way of doing things. I make no mention of whether it will cost more or less other than it will likely cost the same... unless you are arguing that support/staff for OSS will be strictly less expensive than that for closed source solutions. My response was to the parent post that seemed to be assuming that the Navy would download software for free and provide no mechanism of support for it, which is simply basement dweller thinking.
This has pretty much nothing to do with saving money except to only the most casual of (misinformed) glances. I'm sure it was used as a bullet point (although false) in trying to sell it to Congress.
The Navy is NOT going to just download crap, have a monkey install it, and hope for the best. At the minimum, they will need to buy support contracts. Additionally, they will most likely hire some support staff of their own. There will likely be little cost savings in actual dollar amounts.
The OTHER advantages of FOSS are what it's all about (open formats, source code overview if desired, source code escrow, etc.)
Ummm... yes? Looks like we are in agreement there.
FLOP is not a measurement - it's a thing. FADD (floating point add) is a FLOP (floating point operation). If you had a string of one hundred FADD instructions in sequence in a program, you could say there are 100 floating point operations right there... or 100 FLOPs. Now, if you said that it took two seconds to execute all those 100 FLOPs, you would have 50 FLOPS (100 floating point operations performed in two seconds would be 50 floating point operations per second).
I guess one may debate whether the "P" in FLOPS (floating point operations per second) is for the "P" in "Per" or is it part of the "OP" in "OPeration". My argument was to say that it was a part of "Operation" as FLOP is an acronym in itself for "floating point operation" and the "per second" is represented by the "S". I guess one could argue that "FLOP" is for "floating point operation" and "FLOPS" drops the "P" in "OPeration" and adds a "P" for "Per".
Re:This is what I HATE most about FOSS
on
GPLv2 Vs. GPLv3
·
· Score: 1
The *only* thing the GPL prevents me from doing is taking SOMEONE ELSES CODE and overriding their licensing choice.
Sounds a lot like DRM.
Re:This is what I HATE most about FOSS
on
GPLv2 Vs. GPLv3
·
· Score: 1
The GPL is about perpetuating the freedom of the *code*, specifically the freedom to modify the code.
First, *code* is an inanimate object and, as such, has no freedoms.
Second, the freedom of a person to modify the code is in no way hampered in GPL or BSD. However, your freedoms to do what you wish with the modifications to the code are quite different under each.
Under BSD, your freedoms to do what you wish with the (now modified) code are completely open - you may do with it what you wish.
Under GPL, your freedoms to do what you wish with the modifications are restricted to a binary choice - you may either never let anyone else have it outside your organization (which may be only yourself in the case you are not a business with employees) or you must make it available through GPL itself.
So, let's tally the choices... under BSD, your choices are infinite. Under GPL, your choices are two. The last time I checked a math book, infinite is more than two. There is no question as to which license gives more freedom to developers over the code that they produce.
The question comes from the originator of the unmodified code. In this case, the GPL is very much like DRM (which so many are so fired up about). The original producer wants to maintain control over what is done with the original code. In this case, the original producer wants to restrict the use of the body of work to be used only in ways that the original producer desires, this includes further use and licensing as dictated by a licensing agreement (is this DRM or GPL? sounds like both are the same here). In another case, consumers of that original body of work desire to use, modify, and otherwise "do what they want to with" the original body of work (are we talking about those who are against DRM or the BSD license?).
So, those who are against "Tivoisation" typically want to modify the Tivo to do various things like remove DRM, but they want the GPL to force Tivo to allow them to do it by dictating what rights they have over the code used in Tivo devices... I believe there are words used to describe this kind of mindset/behaviour...
Clarification to the above... 0%-12% faster than an equivalently clocked K8 in integer and x87 loads. There hasn't been anything really out yet for SSE that we've seen and a lot of work and resources were put into K10 to make SSE faster.
There have been four references to the performance of Barcelona lately. Three are pretty much in agreement that single threaded performance will be from 0%-12% faster than the equivalent clock speed K8. These can be found in the form of SPEC published by AMD, the 16 core 1.8GHz K10 demonstration using POVRay (where it wasn't 2x as fast as an 8 core K8 machine at the same clock frequency and the 8 core Intel Woodcrest, which you can already buy, was faster than it, as shown in an Intel response specifically to the AMD POVRay demonstration), and an NDA leak from one side that said they've been seeing up to 12% improvement. Another was the press expo where someone commented that "H.264 encoding was done in almost realtime" but that is too vague to be useful. If it were "close" to realtime, it'd be about 6x as fast as today's machines so there was something going on there (maybe the stack of the latest gen - to-be-released ATI video cards doing the work, who knows).
Given that WoW has been out for 2+ years now, there are a large number of both casual and "hard-core" gamers that are getting tired with the game and looking for something new.
Heh... and for some of us, it took less than six months after release. I got bored with WoW almost instantly.... took my time to try to enjoy it and ended up leveling up a few level 60s in about 4 months while trying to take it slowly, tossed the game out of boredom.
One floating point operation (say, an add), is a FLOP, not a FLO. Just like a No OPeration is a NOP (alternatively, NOOP, but assembly mnemonic is almost always NOP). If you want to know the rate at which a processor executes FLOPs, you say that it computes at X FLOPS.
Actually... I think it's more FLoating Point OPerations per Second.
One floating point operation (say, an add), is a FLOP, not a FLO. Just like a No OPeration is a NOP (alternatively, NOOP, but assembly mnemonic is almost always NOP). If you want to know the rate at which a processor executes FLOPs, you say that it computes at X FLOPS.
When you have access to developer knowledge when there are no manuals explaining the mechanics of the game, you'd better be pretty good. The equations governing capacitor recharge, shield recharge, to-hit by turrets, etc. have all been derived/approximated by logging and analysis by players, for example. Of course, for developers, they can just look at the code and tell their alliance. The same thing goes for how/when player owned stations go into and out of reinforcement and such.
Similarly, it's already been proven (t20) that developers use their status to create items (and effectively in-game money) for their alliances, which allow them to wage war. PvP in Eve is fairly brutal. You can easily lose a ship that you spent 40 hours gathering the in-game money to buy, only to lose the ship in about 30 seconds of a fight. All that time/money is gone and you have to do it again. Wars are typically won by attrition... one side just cannot afford to continue the war (run out of money) and many major alliances in the past have surrendered after only a month or two of all-out war. In a game where the developers can just give (or effectively give) their alliance all the money it needs, they will never break from lack of money.
BoB will end up owning all of 0.0 eventually anyway as they will have so many super capital ships that it will be pointless to try to fight them. At that point, I'm pretty sure the game will die off as those who don't like living in Empire will just quit.
mmorpgs offer never-ending opportunities for character advancement and development.
Never ending trips into UBRS, LBRS, MC, BL, Strat, Scholo, ZG, etc. does not equate to never-ending opportunities for character advancement and development.
There are different models of parallel computing... what you describe is not much different from threadpools and worker threads... reasonably coarse grained computing. What happens to your model when events have to communicate to each other in a reasonable way? Hint: you end up with all the same problems you claim they avoid.
The first step of parallel programming is to realize that there is no One Solution that works for all problems. There are a number of patterns that work well for certain classes of problems. When you get down to some of the stuff done in HPC. for example, you need parallel solvers, not course grained task farms and those are two different beasts.
And this is where you've gone astray... in Eve, the PvE aspect is fairly minor compared to the PvP aspect. There is no MMO is screwing the players... it's the players screwing each other over. You rarely die to NPCs. You die to other players. When you do, your ship explodes along with some of the equipment you had on it and the victor can loot your wreck to recover items that didn't explode. Stop thinking of Eve is a PvE game because it isn't.
Plus, you have to realize that there is no one game or one way to have fun. Eve enjoys a niche market because there is a niche of players who like it. It sounds like you aren't of this niche so don't play Eve.
And that's one of the problems... most computer users don't want to put ANY work into the OS. When you say that "put a little work into it", they stop listening and turn away.
I've offered to install Linux on all of my family's computers, particularly when they have HDD failures and the like where you have to reinstall the OS. That's only about a dozen machines but the number of Linux installs that I've done has been zero. I've tried to sell them on it being free, "more stable", less prone to virus/malware, etc. You know why they won't? Every one of them has some application that they like and they ask "Is it on Linux". I have to say "No, but X$ is and that's a similar/replacement application". That seals the deal... Windows for them.
People like, and are comfortable with, what they know and most don't want to have to relearn "everything" just because they install a different OS. They aren't like us who like to tinker and exploring a new program isn't fun for them. I play with new programs all the time and throw them away if I don't like them. Most people don't want to do that... learning something just to throw it away when they find out it doesn't do what they want is not fun for them. This is particularly troublesome when they don't want to have the risk of having to move wholesale to a new platform (OS) and are afraid to find out that something they want/like doesn't work the same or doesn't work at all and then they have to move back.
And... believe it or not... many 'older' people do not know how to type. Telling them that they can type stuff on a command line and that it's 'more powerful' does NOT make them happy. In fact, it repulses them. Particularly when the experiences they've had when trying to deal with a command line even on Windows and they learn that you cannot make mistakes (syntax or otherwise) or the computer will 'fuss' at them or, at worst, do something they didn't want it to do. Think of "find . -name \*.jpg -exec cp {} ~me/pictures \;" and what that would look like to them and what they would be afraid would happen if they got any of those wierd characters wrong.
Good point. It's almost like either they don't care about GPLv3 in general, don't care enough to read and understand GPLv3, or don't understand the differences between GPLv3 and GPLv2. All of which, given that code will be committed to that license policy, potentially blindly, are pretty scary. Does the OSS community trust these people that much that they'll blindly accept whatever license they decree?
(Disclaimer: I tend to release my personally written stuff under BSD unless what I'm working on has other licensing, then it's whatever license that body of work is under.)
Yup... I don't play WoW anymore (haven't for over a year) but I do play other games. Push-to-talk is required when we're on Vent. There's nothing more annoying than having someone go AFK but you can hear them talking with someone else in the background, or hear them eating/drinking near the microphone, or even worse, have them sneeze/cough and blow your eardrums out.
It was even before that... MUDs were all about player created content. Just because it was text and not graphics is not sufficient reason to dismiss it.
Hard to say, actually. The P4, for example, had some novel technology in it (advanced branch prediction, cache, etc.) but had other parts that caused it to have problems (pathological retry, for example). The Opteron also had some novel technology (IMC, HT, etc.) as well but a lot of its core wasn't necessarily that technologically advanced. It's hard to say which one was more technologically advanced... brute force can go a long ways for pure performance.
Yup. Bad case of judgement in this one. They could have had useful training exercises with planned and preannounced drills instead of this unannounced/surprise one.
Slashdot Mirror
And we are often told, time and time again, that fixed up-front costs are amortizable and actually don't factor as highly into TOC as do contractual costs such as support.
Agreed and this is what I was saying... except for most organizations that care about what they do, there is no option of not purchasing both support or not employing internal support. So those are what I figured into the cost of what I was saying. I guess you could argue that both support and internal support are not required. I'll argue that they are. And, if they are, then, even by your own post, you agree that the end costs will be similar.
I haven't seen much detail as to what they'll be watching anyway. Will they be able to effectively do anything at all? Will they be technical enough to examine logs and databases? Will that even matter since someone with the approproiate skills/access can alter those anyway? What will the makeup of the group be? Having them all from BoB, for example, will accomplish nothing most likely and will not foster any good PR.
I have no idea how you got that from my post. I only mention support contracts and in-house support staff as possibilities. This isn't much different from closed source practice other than the up-front-cost as you mention. Because of this, there will likely be little actual monitary savings. It isn't like they will download everything for free and not have some kind of support for it, which would be a fantastically insane way of doing things. I make no mention of whether it will cost more or less other than it will likely cost the same... unless you are arguing that support/staff for OSS will be strictly less expensive than that for closed source solutions. My response was to the parent post that seemed to be assuming that the Navy would download software for free and provide no mechanism of support for it, which is simply basement dweller thinking.
This has pretty much nothing to do with saving money except to only the most casual of (misinformed) glances. I'm sure it was used as a bullet point (although false) in trying to sell it to Congress.
The Navy is NOT going to just download crap, have a monkey install it, and hope for the best. At the minimum, they will need to buy support contracts. Additionally, they will most likely hire some support staff of their own. There will likely be little cost savings in actual dollar amounts.
The OTHER advantages of FOSS are what it's all about (open formats, source code overview if desired, source code escrow, etc.)
Ummm... yes? Looks like we are in agreement there.
FLOP is not a measurement - it's a thing. FADD (floating point add) is a FLOP (floating point operation). If you had a string of one hundred FADD instructions in sequence in a program, you could say there are 100 floating point operations right there... or 100 FLOPs. Now, if you said that it took two seconds to execute all those 100 FLOPs, you would have 50 FLOPS (100 floating point operations performed in two seconds would be 50 floating point operations per second).
I guess one may debate whether the "P" in FLOPS (floating point operations per second) is for the "P" in "Per" or is it part of the "OP" in "OPeration". My argument was to say that it was a part of "Operation" as FLOP is an acronym in itself for "floating point operation" and the "per second" is represented by the "S". I guess one could argue that "FLOP" is for "floating point operation" and "FLOPS" drops the "P" in "OPeration" and adds a "P" for "Per".
Sounds a lot like DRM.
First, *code* is an inanimate object and, as such, has no freedoms.
Second, the freedom of a person to modify the code is in no way hampered in GPL or BSD. However, your freedoms to do what you wish with the modifications to the code are quite different under each.
Under BSD, your freedoms to do what you wish with the (now modified) code are completely open - you may do with it what you wish.
Under GPL, your freedoms to do what you wish with the modifications are restricted to a binary choice - you may either never let anyone else have it outside your organization (which may be only yourself in the case you are not a business with employees) or you must make it available through GPL itself.
So, let's tally the choices... under BSD, your choices are infinite. Under GPL, your choices are two. The last time I checked a math book, infinite is more than two. There is no question as to which license gives more freedom to developers over the code that they produce.
The question comes from the originator of the unmodified code. In this case, the GPL is very much like DRM (which so many are so fired up about). The original producer wants to maintain control over what is done with the original code. In this case, the original producer wants to restrict the use of the body of work to be used only in ways that the original producer desires, this includes further use and licensing as dictated by a licensing agreement (is this DRM or GPL? sounds like both are the same here). In another case, consumers of that original body of work desire to use, modify, and otherwise "do what they want to with" the original body of work (are we talking about those who are against DRM or the BSD license?).
So, those who are against "Tivoisation" typically want to modify the Tivo to do various things like remove DRM, but they want the GPL to force Tivo to allow them to do it by dictating what rights they have over the code used in Tivo devices... I believe there are words used to describe this kind of mindset/behaviour...
Clarification to the above... 0%-12% faster than an equivalently clocked K8 in integer and x87 loads. There hasn't been anything really out yet for SSE that we've seen and a lot of work and resources were put into K10 to make SSE faster.
There have been four references to the performance of Barcelona lately. Three are pretty much in agreement that single threaded performance will be from 0%-12% faster than the equivalent clock speed K8. These can be found in the form of SPEC published by AMD, the 16 core 1.8GHz K10 demonstration using POVRay (where it wasn't 2x as fast as an 8 core K8 machine at the same clock frequency and the 8 core Intel Woodcrest, which you can already buy, was faster than it, as shown in an Intel response specifically to the AMD POVRay demonstration), and an NDA leak from one side that said they've been seeing up to 12% improvement. Another was the press expo where someone commented that "H.264 encoding was done in almost realtime" but that is too vague to be useful. If it were "close" to realtime, it'd be about 6x as fast as today's machines so there was something going on there (maybe the stack of the latest gen - to-be-released ATI video cards doing the work, who knows).
Heh... and for some of us, it took less than six months after release. I got bored with WoW almost instantly.... took my time to try to enjoy it and ended up leveling up a few level 60s in about 4 months while trying to take it slowly, tossed the game out of boredom.
Stupid inability to edit posts... :(
One floating point operation (say, an add), is a FLOP, not a FLO. Just like a No OPeration is a NOP (alternatively, NOOP, but assembly mnemonic is almost always NOP). If you want to know the rate at which a processor executes FLOPs, you say that it computes at X FLOPS.
Actually... I think it's more FLoating Point OPerations per Second.
One floating point operation (say, an add), is a FLOP, not a FLO. Just like a No OPeration is a NOP (alternatively, NOOP, but assembly mnemonic is almost always NOP). If you want to know the rate at which a processor executes FLOPs, you say that it computes at X FLOPS.
When you have access to developer knowledge when there are no manuals explaining the mechanics of the game, you'd better be pretty good. The equations governing capacitor recharge, shield recharge, to-hit by turrets, etc. have all been derived/approximated by logging and analysis by players, for example. Of course, for developers, they can just look at the code and tell their alliance. The same thing goes for how/when player owned stations go into and out of reinforcement and such.
Similarly, it's already been proven (t20) that developers use their status to create items (and effectively in-game money) for their alliances, which allow them to wage war. PvP in Eve is fairly brutal. You can easily lose a ship that you spent 40 hours gathering the in-game money to buy, only to lose the ship in about 30 seconds of a fight. All that time/money is gone and you have to do it again. Wars are typically won by attrition... one side just cannot afford to continue the war (run out of money) and many major alliances in the past have surrendered after only a month or two of all-out war. In a game where the developers can just give (or effectively give) their alliance all the money it needs, they will never break from lack of money.
BoB will end up owning all of 0.0 eventually anyway as they will have so many super capital ships that it will be pointless to try to fight them. At that point, I'm pretty sure the game will die off as those who don't like living in Empire will just quit.
Never ending trips into UBRS, LBRS, MC, BL, Strat, Scholo, ZG, etc. does not equate to never-ending opportunities for character advancement and development.
There are different models of parallel computing... what you describe is not much different from threadpools and worker threads... reasonably coarse grained computing. What happens to your model when events have to communicate to each other in a reasonable way? Hint: you end up with all the same problems you claim they avoid.
The first step of parallel programming is to realize that there is no One Solution that works for all problems. There are a number of patterns that work well for certain classes of problems. When you get down to some of the stuff done in HPC. for example, you need parallel solvers, not course grained task farms and those are two different beasts.
And this is where you've gone astray... in Eve, the PvE aspect is fairly minor compared to the PvP aspect. There is no MMO is screwing the players... it's the players screwing each other over. You rarely die to NPCs. You die to other players. When you do, your ship explodes along with some of the equipment you had on it and the victor can loot your wreck to recover items that didn't explode. Stop thinking of Eve is a PvE game because it isn't.
Plus, you have to realize that there is no one game or one way to have fun. Eve enjoys a niche market because there is a niche of players who like it. It sounds like you aren't of this niche so don't play Eve.
Myself am not sure. Myself thinks it might be "yourselves're's". But don't ask myself, myself am not sure. :)
And that's one of the problems... most computer users don't want to put ANY work into the OS. When you say that "put a little work into it", they stop listening and turn away.
I've offered to install Linux on all of my family's computers, particularly when they have HDD failures and the like where you have to reinstall the OS. That's only about a dozen machines but the number of Linux installs that I've done has been zero. I've tried to sell them on it being free, "more stable", less prone to virus/malware, etc. You know why they won't? Every one of them has some application that they like and they ask "Is it on Linux". I have to say "No, but X$ is and that's a similar/replacement application". That seals the deal... Windows for them.
People like, and are comfortable with, what they know and most don't want to have to relearn "everything" just because they install a different OS. They aren't like us who like to tinker and exploring a new program isn't fun for them. I play with new programs all the time and throw them away if I don't like them. Most people don't want to do that... learning something just to throw it away when they find out it doesn't do what they want is not fun for them. This is particularly troublesome when they don't want to have the risk of having to move wholesale to a new platform (OS) and are afraid to find out that something they want/like doesn't work the same or doesn't work at all and then they have to move back.
And... believe it or not... many 'older' people do not know how to type. Telling them that they can type stuff on a command line and that it's 'more powerful' does NOT make them happy. In fact, it repulses them. Particularly when the experiences they've had when trying to deal with a command line even on Windows and they learn that you cannot make mistakes (syntax or otherwise) or the computer will 'fuss' at them or, at worst, do something they didn't want it to do. Think of "find . -name \*.jpg -exec cp {} ~me/pictures \;" and what that would look like to them and what they would be afraid would happen if they got any of those wierd characters wrong.
Good point. It's almost like either they don't care about GPLv3 in general, don't care enough to read and understand GPLv3, or don't understand the differences between GPLv3 and GPLv2. All of which, given that code will be committed to that license policy, potentially blindly, are pretty scary. Does the OSS community trust these people that much that they'll blindly accept whatever license they decree?
(Disclaimer: I tend to release my personally written stuff under BSD unless what I'm working on has other licensing, then it's whatever license that body of work is under.)
Yup... I don't play WoW anymore (haven't for over a year) but I do play other games. Push-to-talk is required when we're on Vent. There's nothing more annoying than having someone go AFK but you can hear them talking with someone else in the background, or hear them eating/drinking near the microphone, or even worse, have them sneeze/cough and blow your eardrums out.
It was even before that... MUDs were all about player created content. Just because it was text and not graphics is not sufficient reason to dismiss it.
If the financial reports are accurate, AMD doesn't have a couple of years to sort it out. Their timeframe for sorting it out is significantly shorter.
Hard to say, actually. The P4, for example, had some novel technology in it (advanced branch prediction, cache, etc.) but had other parts that caused it to have problems (pathological retry, for example). The Opteron also had some novel technology (IMC, HT, etc.) as well but a lot of its core wasn't necessarily that technologically advanced. It's hard to say which one was more technologically advanced... brute force can go a long ways for pure performance.
Yup. Bad case of judgement in this one. They could have had useful training exercises with planned and preannounced drills instead of this unannounced/surprise one.