Ah yes, good old Civ 4. I once had a very highly promoted samurai army defending a hill that held off ten attacks from enemy riflemen units without being completely destroyed which resulted in even more promotions for the defending samurai. The samurai unit was easily one of the best special units in that game, especially because they had first strike and could reliably defeat even the early gunpowder units. Realistic? Probably not, but it was pretty funny to see those enemy AI riflemen defeated one after another by those pesky veteran samurai.
That's nothing like as annoying as in Civ1, where losing a tank or battleship when attacking some barbarian pikemen was just too easily done.
Based off of a sample size of 1. Nice generalization.
Well, I've observed the problem at multiple locations in the US and none in the EU. Still anecdotal, but a quick bayesian analysis does indicate that assuming that there's some kind of issue in the US. I've also had it described to me as being due to the use of different wiring methodologies, but couldn't verify that from personal knowledge. I suppose the effect could be relatively amplified due to the lower voltage and consequently larger currents involved, which would make any resistive load in the wiring have a disproportionately larger effect.
The article is arguing that *any* API that is exposed on the net *must* implement oath so that third parties can use it. Seems pretty crazy to argue that any api exposed to the internet must implement third party app access.
It's also crazy to claim that OAuth is the only mechanism for doing it. There are others that are stronger, though more of a PITA; we were doing secure third party service access by other mechanisms (there are a few variations based on client-authenticated SSL with security assertions) 10 years ago, and that expertise still exists. The good thing about OAuth is that it works very easily with browsers and is relatively simple for simple websites to support, but if there are no browsers or it's not a simple conventional website? OAuth might not be for you. (In fact, it definitely can't be for you if you don't have a user in the loop; some other mechanism is required.)
The US also isn't your typical country. It's far more comparable to the EU as a whole than to any one EU country.
People in the EU underestimate how different the US states are from each other; the US is not homogenous at all. People in the US underestimate how different the EU member countries are from each other; the EU members are far more different from each other than any US states are.
if all of the decentralized projects are on github, then they are not decentralized... github is the center.
The repositories are decentralized; losing github wouldn't maroon the code. But other things are still centralized as far as I can see, notably including issue databases. That's not very important for a small project, but for a large one that's absolutely critical.
Subversion was originally tigris.org. Geronimo and Derby were IBM products (all donated). Also log4j.
Apache has developed or adopted more products than I can count. OpenJPA, Apache Commons, Axis, CXF, Velocity, Struts. The list goes on and on.
That's part of what they do — provide umbrella support for projects with things like hosting, governance, legal and stuff like that. They're clear indicators of success, of impact. Coding isn't the only thing that a project needs. (FWIW, CXF has definitely been developed quite a bit since adoption.)
People already complain on 60 Hz on computer monitors as too slow for games.
There are people who will complain at 240 Hz refresh rates for their displays as being too slow. Luckily they'll be able to buy Denon cables to fix this.
The other problem with a Midi file (and regular sheet music) is that, while it provides instructions for playing a piece of music, it doesn't give you a means of duplicating a performance exactly.
That's a different problem. Sheet music (or MIDI) is like source code, whereas a performance is like a compiled executable. There are many tools that work well for source but which don't for executables (e.g., version control systems like git or svn) so we should not be surprised when not all concepts work perfectly for music either. Indeed, the purpose of open source music has got to first be to allow others to create their own performances from the "source", and secondly to allow others to create their own derived "source".
What's more, I can assure you that not all "performances" of programs — compilations into executable programs — are the same. Even with the exact same codebase, picking a different compiler (i.e., a different instrument) can make significant differences to the quality of the results. (I have source code where one compiler produces a resulting executable that goes more than twice as fast as output produced by another compiler, despite everything else being the same in every respect.) This does not invalidate the idea of open source. It just shows that things are never as straightforward as you might hope, and that there really are some interesting analogies. Yet music is still not the same thing as computer programs; we shouldn't expect perfection in our analogies.
An M1 MBT would go through the mountain; it would not crash.
A few billion tons of rock would like to respectfully disagree with that sentiment. They're not going anywhere. Or at least you hope not, as if they are, the tank's in a heap of trouble; landslides are like that...
It would be far cheaper to build a streamlined self-driving bus that can do 120MPH on existing road infrastructure.
We've some experience with what would be required to make those sorts of bus systems work here in the UK. Unless you come up with some magic to deal with congestion, that bus is going to be doing 40MPH on average, whether or not it is self-driving. The easiest way to keep the way clear for the (whole fleet of) bus(es) is to build a separated roadway; just designating a lane wouldn't work nearly so well, given the propensity of some people to be assholes. However, a separated roadway takes space, either requiring more land to be acquired (in other words, a train route with rubber tyres) or requiring substantial amounts of space to be taken away from the existing roads.
Infrastructure isn't cheap, however you present it, and if you want to improve travel times and capacity you're going to have to invest as what you've already got is very close to full.
But if they make $10k/year selling support for the code you wrote that's ok?
If that's their personal income from doing that, they'd better have another job too. It's not very much, only like $200 a week on average. Maybe above the bread line, but only just.
And in any case, they can be undercut by someone else. It's not like they have an exclusive right to make money from supporting that piece of code.
You can't just start digging up pristine forest or people's back yards for your rail.
Wrong. This is the sort of thing that eminent domain laws are exactly for. It's usual to try to minimise the use of such things (it's cheaper if the line-owner already owns the land) but that won't stop things if there is a will to make them happen.
Ownership is a social construct. Always was. Such things are subject to change where there is a good enough reason.
Unless you have figured out a way to get electricity out of the air, for the forseeable future, we are going to be using fossil fuel
Wind power exists. Solar power exists. Hydro power exists. Nuclear power exists. None of those are horribly experimental (unlike fusion) so all that's needed is rolling them out. We also know how to move electrical power long distances. We have all the technology already.
It will be a long time before solar and wind and other sources can replace fossil fuel plants.
Not as long as you think. It's not a scientific barrier. It's not a technological barrier. It's not even an engineering barrier. In many ways, the biggest barrier to fixing things is actually nay-sayers like you.
While it may be more economical to generate electricity in a central point and then transmit it where needed, the maintenance of those transmission lines, particularly for thousands of miles of railroad track would more than offset the savings.
No, but you're having to invest a fair bit of capital to get into a system with lower operating costs. That's a classic trade-off. Sometimes, people choose higher operating costs because they can't justify the capital spend, but it's still cheaper to have the power generation units and fuel not needing acceleration and braking. (The other benefit of all-electric trains is that it becomes practical to use braking systems that convert the kinetic energy back into electric energy as you won't have big problems with storing that energy, so reducing costs. Regenerative braking helps a lot.)
In other words, let's use 10,000 year old primitive rules and notions to drive 21st century transportation expenditures.
Of course. We've not had telecommunications for nearly long enough (less than 140 years, with widespread telephone ownership for quite a lot less and videoconferencing for a lot less) for us to have evolved significantly to be happier using it than seeing people in person. Give it a few thousand years, say 100 generations, and I'm sure humanity will be far happier with telecoms.
Once you say something isn't for the enterprise you almost guarantee that it will be a > $1B business (or fundamental tech used in a $1B business) in the next couple years.
Really? Woohoo! Testing and validation and all of those good practical software engineering principles aren't for the enterprise.
they say they cant afford to pay us to come in five days a week while during that time people are sent back and forth to hawaii (airfare, hotel, per diem) for things a video teleconference could accomplish, among other extravagant wastes of money
On the point of video conferencing, it's not quite as good as that. Even leaving aside the technical difficulties (getting volume levels right seems to be the hardest thing) there are other problems. In particular, a video conference is rather more like a teleconference than a meeting in person; there are things that are just much easier to do face to face. It seems to be just how people work socially. What the video conference can do though is reduce the frequency of F2F meetings to the level required for social purposes (one every few months seems to be enough) with interim meetings done via telecommunications.
The downside is that this encourages management to have more meetings...
The real innovation of Cloud is not in the technology, where it is just a bunch of stuff that already existed brought together with some improved networking. The real innovation is in the business models enabled by it, both for providers and customers. Super short-term rent of remote hardware while hiding all the details of what is going on from the downstream consumers? That lets you do all sorts of interesting things that were wholly impractical before. Every time I see someone saying that the Cloud has no innovation, I think to myself "there is someone who is missing the point". It's not about technical innovation (though there's probably some involved), it's about what you can do with it.
I'm no business type though. I just had the good fortune to be working on a project that was studying business models for distributed computing at the time Cloud took off. (The project had other problems, notably a vastly over-complex architecture, but its business and market studies were sound.)
IMHO dynamic typing works best in programs under 20 lines of code, works OK 20-1000 and starts to fall apart after 1000.
I know people with 10 million line scripting language programs that they use to run oil rigs. I think they're crazy to have a program that large! (In any language.)
But the real key to good practice isn't OOP so much as component-based programming where those components, and the glue between them, can be in different languages. Each component can be separately tested and has a defined interface, so that's great for robustness and scalability, and the right language for each part can be used. Every programming language implies its own set of abstractions, so using the one that has the most suitable ones for the particular problem being tackled in a component is a huge benefit, and yet the selection of abstractions is always a trade-off as you can't have them all. (Some things are just better off high-level, others low-level. And that's a simplification.) The best thing in the past 20-30 years of software engineering has been the gradual decline of the do-it-all-in-one-language dogma.
You know why we have that? Because nobody wants to pay for what it would cost to do it the other way. They'd mostly rather have cheaper stuff without the liability insurance, with customers purchasing their own insurance if they want. We know this is a winning model because that's what everyone — the "market" — chooses when given have a chance. (Some parts of the market work the way you seem to prefer, usually those with safety-critical systems, but they're very expensive and very much the exceptional cases.)
Trying to replicate results can be very expensive and time consuming.
It's worthwhile doing though. A result that can be reproduced is genuinely useful. Of course, what "reproduce" means is not trivial at all, as there are a lot of unique experiments and data collections out there. (You can't rewind the natural world just so you can put a different set of instruments in place to measure an event again in more detail.) Reproduction might mean using a different approach to analysis of the raw data, or measuring another "sufficiently similar" thing, or trying to do exactly the same thing in a different lab; it all depends on exactly what is being studied and exactly what is being claimed.
Slashdot Mirror
Good example? Civ 4.
Ah yes, good old Civ 4. I once had a very highly promoted samurai army defending a hill that held off ten attacks from enemy riflemen units without being completely destroyed which resulted in even more promotions for the defending samurai. The samurai unit was easily one of the best special units in that game, especially because they had first strike and could reliably defeat even the early gunpowder units. Realistic? Probably not, but it was pretty funny to see those enemy AI riflemen defeated one after another by those pesky veteran samurai.
That's nothing like as annoying as in Civ1, where losing a tank or battleship when attacking some barbarian pikemen was just too easily done.
Based off of a sample size of 1. Nice generalization.
Well, I've observed the problem at multiple locations in the US and none in the EU. Still anecdotal, but a quick bayesian analysis does indicate that assuming that there's some kind of issue in the US. I've also had it described to me as being due to the use of different wiring methodologies, but couldn't verify that from personal knowledge. I suppose the effect could be relatively amplified due to the lower voltage and consequently larger currents involved, which would make any resistive load in the wiring have a disproportionately larger effect.
The article is arguing that *any* API that is exposed on the net *must* implement oath so that third parties can use it. Seems pretty crazy to argue that any api exposed to the internet must implement third party app access.
It's also crazy to claim that OAuth is the only mechanism for doing it. There are others that are stronger, though more of a PITA; we were doing secure third party service access by other mechanisms (there are a few variations based on client-authenticated SSL with security assertions) 10 years ago, and that expertise still exists. The good thing about OAuth is that it works very easily with browsers and is relatively simple for simple websites to support, but if there are no browsers or it's not a simple conventional website? OAuth might not be for you. (In fact, it definitely can't be for you if you don't have a user in the loop; some other mechanism is required.)
The US also isn't your typical country. It's far more comparable to the EU as a whole than to any one EU country.
People in the EU underestimate how different the US states are from each other; the US is not homogenous at all. People in the US underestimate how different the EU member countries are from each other; the EU members are far more different from each other than any US states are.
if all of the decentralized projects are on github, then they are not decentralized... github is the center.
The repositories are decentralized; losing github wouldn't maroon the code. But other things are still centralized as far as I can see, notably including issue databases. That's not very important for a small project, but for a large one that's absolutely critical.
Subversion was originally tigris.org. Geronimo and Derby were IBM products (all donated). Also log4j.
Apache has developed or adopted more products than I can count. OpenJPA, Apache Commons, Axis, CXF, Velocity, Struts. The list goes on and on.
That's part of what they do — provide umbrella support for projects with things like hosting, governance, legal and stuff like that. They're clear indicators of success, of impact. Coding isn't the only thing that a project needs. (FWIW, CXF has definitely been developed quite a bit since adoption.)
Amazon is doing well in many ways, but as a competitor to Netflix? No way.
Which market are you in? Amazon are the incumbent in some (which lets them get a much better selection of content there).
People already complain on 60 Hz on computer monitors as too slow for games.
There are people who will complain at 240 Hz refresh rates for their displays as being too slow. Luckily they'll be able to buy Denon cables to fix this.
The other problem with a Midi file (and regular sheet music) is that, while it provides instructions for playing a piece of music, it doesn't give you a means of duplicating a performance exactly.
That's a different problem. Sheet music (or MIDI) is like source code, whereas a performance is like a compiled executable. There are many tools that work well for source but which don't for executables (e.g., version control systems like git or svn) so we should not be surprised when not all concepts work perfectly for music either. Indeed, the purpose of open source music has got to first be to allow others to create their own performances from the "source", and secondly to allow others to create their own derived "source".
What's more, I can assure you that not all "performances" of programs — compilations into executable programs — are the same. Even with the exact same codebase, picking a different compiler (i.e., a different instrument) can make significant differences to the quality of the results. (I have source code where one compiler produces a resulting executable that goes more than twice as fast as output produced by another compiler, despite everything else being the same in every respect.) This does not invalidate the idea of open source. It just shows that things are never as straightforward as you might hope, and that there really are some interesting analogies. Yet music is still not the same thing as computer programs; we shouldn't expect perfection in our analogies.
An M1 MBT would go through the mountain; it would not crash.
A few billion tons of rock would like to respectfully disagree with that sentiment. They're not going anywhere. Or at least you hope not, as if they are, the tank's in a heap of trouble; landslides are like that...
It's powered by the users own sense of self importance.
Did the BMW patents expire already?
Why do you think there's no iCar yet?
It would be far cheaper to build a streamlined self-driving bus that can do 120MPH on existing road infrastructure.
We've some experience with what would be required to make those sorts of bus systems work here in the UK. Unless you come up with some magic to deal with congestion, that bus is going to be doing 40MPH on average, whether or not it is self-driving. The easiest way to keep the way clear for the (whole fleet of) bus(es) is to build a separated roadway; just designating a lane wouldn't work nearly so well, given the propensity of some people to be assholes. However, a separated roadway takes space, either requiring more land to be acquired (in other words, a train route with rubber tyres) or requiring substantial amounts of space to be taken away from the existing roads.
Infrastructure isn't cheap, however you present it, and if you want to improve travel times and capacity you're going to have to invest as what you've already got is very close to full.
But if they make $10k/year selling support for the code you wrote that's ok?
If that's their personal income from doing that, they'd better have another job too. It's not very much, only like $200 a week on average. Maybe above the bread line, but only just.
And in any case, they can be undercut by someone else. It's not like they have an exclusive right to make money from supporting that piece of code.
You can't just start digging up pristine forest or people's back yards for your rail.
Wrong. This is the sort of thing that eminent domain laws are exactly for. It's usual to try to minimise the use of such things (it's cheaper if the line-owner already owns the land) but that won't stop things if there is a will to make them happen.
Ownership is a social construct. Always was. Such things are subject to change where there is a good enough reason.
Unless you have figured out a way to get electricity out of the air, for the forseeable future, we are going to be using fossil fuel
Wind power exists. Solar power exists. Hydro power exists. Nuclear power exists. None of those are horribly experimental (unlike fusion) so all that's needed is rolling them out. We also know how to move electrical power long distances. We have all the technology already.
It will be a long time before solar and wind and other sources can replace fossil fuel plants.
Not as long as you think. It's not a scientific barrier. It's not a technological barrier. It's not even an engineering barrier. In many ways, the biggest barrier to fixing things is actually nay-sayers like you.
While it may be more economical to generate electricity in a central point and then transmit it where needed, the maintenance of those transmission lines, particularly for thousands of miles of railroad track would more than offset the savings.
No, but you're having to invest a fair bit of capital to get into a system with lower operating costs. That's a classic trade-off. Sometimes, people choose higher operating costs because they can't justify the capital spend, but it's still cheaper to have the power generation units and fuel not needing acceleration and braking. (The other benefit of all-electric trains is that it becomes practical to use braking systems that convert the kinetic energy back into electric energy as you won't have big problems with storing that energy, so reducing costs. Regenerative braking helps a lot.)
In other words, let's use 10,000 year old primitive rules and notions to drive 21st century transportation expenditures.
Of course. We've not had telecommunications for nearly long enough (less than 140 years, with widespread telephone ownership for quite a lot less and videoconferencing for a lot less) for us to have evolved significantly to be happier using it than seeing people in person. Give it a few thousand years, say 100 generations, and I'm sure humanity will be far happier with telecoms.
Or all dead from some random passing apocalypse.
penguins in the Arctic Circle
They're just using their frequent flyer bonus miles up.
Once you say something isn't for the enterprise you almost guarantee that it will be a > $1B business (or fundamental tech used in a $1B business) in the next couple years.
Really? Woohoo! Testing and validation and all of those good practical software engineering principles aren't for the enterprise.
(Please may you be correct!)
they say they cant afford to pay us to come in five days a week while during that time people are sent back and forth to hawaii (airfare, hotel, per diem) for things a video teleconference could accomplish, among other extravagant wastes of money
On the point of video conferencing, it's not quite as good as that. Even leaving aside the technical difficulties (getting volume levels right seems to be the hardest thing) there are other problems. In particular, a video conference is rather more like a teleconference than a meeting in person; there are things that are just much easier to do face to face. It seems to be just how people work socially. What the video conference can do though is reduce the frequency of F2F meetings to the level required for social purposes (one every few months seems to be enough) with interim meetings done via telecommunications.
The downside is that this encourages management to have more meetings...
The real innovation of Cloud is not in the technology, where it is just a bunch of stuff that already existed brought together with some improved networking. The real innovation is in the business models enabled by it, both for providers and customers. Super short-term rent of remote hardware while hiding all the details of what is going on from the downstream consumers? That lets you do all sorts of interesting things that were wholly impractical before. Every time I see someone saying that the Cloud has no innovation, I think to myself "there is someone who is missing the point". It's not about technical innovation (though there's probably some involved), it's about what you can do with it.
I'm no business type though. I just had the good fortune to be working on a project that was studying business models for distributed computing at the time Cloud took off. (The project had other problems, notably a vastly over-complex architecture, but its business and market studies were sound.)
typical conspiracy-theorist paranoid
friends
There's a fatal flaw in your thinking right there...
There's only one problem with that: lemmings aren't like lemmings.
Yes, but financial markets are like the stereotype of lemmings.
IMHO dynamic typing works best in programs under 20 lines of code, works OK 20-1000 and starts to fall apart after 1000.
I know people with 10 million line scripting language programs that they use to run oil rigs. I think they're crazy to have a program that large! (In any language.)
But the real key to good practice isn't OOP so much as component-based programming where those components, and the glue between them, can be in different languages. Each component can be separately tested and has a defined interface, so that's great for robustness and scalability, and the right language for each part can be used. Every programming language implies its own set of abstractions, so using the one that has the most suitable ones for the particular problem being tackled in a component is a huge benefit, and yet the selection of abstractions is always a trade-off as you can't have them all. (Some things are just better off high-level, others low-level. And that's a simplification.) The best thing in the past 20-30 years of software engineering has been the gradual decline of the do-it-all-in-one-language dogma.
Lack of liability
You know why we have that? Because nobody wants to pay for what it would cost to do it the other way. They'd mostly rather have cheaper stuff without the liability insurance, with customers purchasing their own insurance if they want. We know this is a winning model because that's what everyone — the "market" — chooses when given have a chance. (Some parts of the market work the way you seem to prefer, usually those with safety-critical systems, but they're very expensive and very much the exceptional cases.)
Trying to replicate results can be very expensive and time consuming.
It's worthwhile doing though. A result that can be reproduced is genuinely useful. Of course, what "reproduce" means is not trivial at all, as there are a lot of unique experiments and data collections out there. (You can't rewind the natural world just so you can put a different set of instruments in place to measure an event again in more detail.) Reproduction might mean using a different approach to analysis of the raw data, or measuring another "sufficiently similar" thing, or trying to do exactly the same thing in a different lab; it all depends on exactly what is being studied and exactly what is being claimed.