I am somewhat amused by the difference in our initial interpretations, though -- the Open Source proponent jumps immediately to practical matters ("you're doing it wrong" in the sense of pounding a nail with a screwdriver) and the Free Software proponent jumps immediately to moral matters. Seems somewhat representative of the differences in focus between the movements as a whole.
Please accept my apologies for insinuating ill will earlier.
Let me be clear, then. When I say "you're doing it wrong", I don't mean "in a manner which is morally wrong". I mean "in a manner which is likely impractical".
What if you can't get it, because it conflicts with the interests, goals or methods of the developers of the package you want to customize?
Then you've got a decision to make, obviously -- comparing the costs of maintaining your patch in-house versus the benefit it provides.
These are fairly uncommon edge cases, however. Upstream may fairly often reject a specific implementation, but it's generally quite possible to work with them to come up with a solution for your problem which makes everyone happy.
Many companies have learned the hard way the true cost of custom software, which in many ways can be worse than proprietary software.
If you're making custom software out of your OSS software, you're doing it wrong.
If you're doing it right, you're submitting your changes back upstream -- so the software doesn't "stand dead-still", as you put it, even on those times when you aren't shoveling man-hours into improvements. If you happen to be curious for some examples, google around for patches under my name submitted to open source projects over the last decade. Just about all of those were paid for by my employers -- from the OS X VNC plugin bugfix to the feature enhancements to libvirt to improved cover page generation for HylaFAX.
For the work I did at Dell, we worked together with Red Hat to get as many of the libvirt and qemu improvements we wanted as possible into the RHEL6 release schedule, enabling some of Dell's internal QA tools to work out-of-the-box with RHEL6 (whereas those same tools required heavy tweaking on RHEL5). Sure, we could have gotten the same thing done as a professional services engagement rather than a friendly collaboration between engineering groups... but this way was far easier, cheaper and lower-paperwork (and by building the patches in-house, we made sure that we got exactly what we wanted).
I don't see how money is being made with "several companies bankrolling" a piece of software that scratches a common itch. Is it that a particular company sees that it can make money by using, though not owning, a particular piece of software and they don't mind their money making improvements available to other people?
Typically it's "bankrolling" by assigning some of your people to spend some of their time on making improvements you happen to need and contributing them upstream.
(Contributing improvements upstream means that you won't need to continually maintain your patches, that they'll eventually be included in vendor packages/kernels and thus that you'll later need to do less packaging yourself, and is otherwise a money-saving action. As a somewhat-related aside -- once upon a time I worked in embedded Linux, and you had companies who structured their default contracts for kernel work such that everything was submitted upstream, making each contract effectively a one-time engagement when everything was done right, and others who didn't... ehh... encourage their clients to pursue submitting their code, such that said clients would keep paying in to keep their patch current with newer upstream kernels).
Serious question: Why didn't the private sector bring us the interstate highway system? Would we be in a better or worse situation right now if it had?
GWT builds faster-executing JavaScript than I can write by hand in a reasonable amount of time, just as a C compiler builds faster assembly than most people can build without digging in and hand-optimizing. Likewise, it builds code optimized for different "targets" -- an IE6-optimized version, an IE7-optimized version, a Firefox-optimized version, etc etc. As such, it provides the tools to build a faster site with wider browser compatibility than one would necessarily be able to build without it.
Is this to say that people can't build slow, browser-incompatible sites using GWT? Of course not -- just as people can write spaghetti code using Python; having a helpful toolchain doesn't absolve the actual developer of responsibility.
Google uses GWT for AdWords -- their cash-cow infrastructure. With such successes, pinning even partial blame for failures on that same tooling just doesn't make sense without a more detailed explanation.
So if we can't fix everything, we should fix nothing? Are you referring to total energy consumption in the context of comparative efficiency numbers by your "back where we're at today in 10 years" assertion? If so, and you expect that we'll have twice as many vehicles in 10 years, cancelling out the doubled wheel-to-well efficiency numbers... well, then, we're supporting twice as many vehicles on the same amount of energy input, and we're less dependent on foreign oil (as we're using locally-mined coal), and we're able to quickly switch our transportation infrastructure to running on nuclear energy as fast as we can bring the plants up. All of those sound like good things to me.
Are you saying that a person writing a review saying "Company X screwed me!" would intentionally add semantic information to the hyperlink indicating that Company X is trustworthy? Or are you saying that the folks who own review clearinghouse sites (specifically, ones with high Pagerank values) would intentionally provide metadata contrary to the reviews that they host?
The topic for this article is presumptively honest negative reviews on trusted review sites (as other sites -- such as those run directly by the scammers -- wouldn't have the necessary PageRank "weight") pulling up the rank of the companies they pan. I don't see how adding the opportunity to provide metadata with hyperlinks (with the nofollow tag as a trivial example) would in any way make the problem worse.
That's the job of the BBcode rendering engine. If they're not adding rel=nofollow universally (or, at minimum, by default), the folks maintaining the relevant libraries need a smack upside the head.
With respect to pollution, switching to grid power dramatically reduces hydrocarbons and carbon monoxide (to the tune of >95%), substantially reduces nitrogen oxides, and will substantially increase sulpher oxide and particulate output in countries (including both the US and UK) where coal- and oil-fired plants are common (while reducing them in other areas such as France and Japan).
Overall efficiency, by contrast, is far less ambiguous: Electric vehicles themselves get about 88% efficiency; after taking into account power plant efficiency, transmission efficiency and charging losses, that number goes down to 28% overall -- but this is still wildly favorable to 14% overall (15% vehicle efficiency, 8% losses during the refining process) for internal combustion engines.
It's all part of the "Green economy" so get to building those new transformers so those coal fired power plants can get the power to where it needs to be.
A single modern coal-powered plant is better than hundreds of thousands of individiual internal combustion engines it replaces in this case.
What's more, the plant can be monitored and upgraded all at once, in one place. An individual vehicle's spark timing is off and they're blowing unburned fuel out the back and it doesn't get fixed 'till they next fail inspection, and that assumes they're complying with the law by bringing their vehicle in for inspection at all.
Seriously -- I'd take nuclear over coal any day, but centrally burned coal is far better than the status quo. (What's especially fun is how folks make the same argument you do here in Austin -- where our electricity is natural gas, nuclear, hydroelectric, and less than 30% coal).
Having written applications with GWT, I find it anything but unwieldy.
Bringing static checking, JUnit-based testing, and modern code coverage tools to JavaScript (and doing a ton of micro-optimizations during the compilation process under the hood) does a world of good. Letting Java-based debugging tools be seamlessly used for debugging JavaScript is even better.
I've seen attempts to implement a GWT-like toolchain for other languages (Python, Scheme) -- and the competition all falls down not on having effective code compilation, but on having an effective debugging toolchain and workflow. Google, by contrast, got that part right.
Actually -- based on feedback from another commenter in this thread, I'm thinking of proposing to Austin (via the bicycle program manager, who knows the rest of the folks involved) that we consider adopting Portland's open source smartphone apps for problem-reporting. Haven't looked into what the server side needs to implement yet, but I'd be surprised if it'd be too ridiculous.
Hmm. I'd care about this much more for 311 (that is, the non-emergency catch-all city services line). Email wouldn't be bad either.
Seriously -- being able to send a photo of a pothole or a tree branch hanging too close to the road or someone illegally parked in a bike lane on a curve after a steep downhill (yes, there's an area on my commute matching exactly that description) with a GPS tag on the photo and a line or two of text would be much more convenient than pulling over and spending 5 minutes trying to figure out the address, walk the operator through deciding how to file the ticket (is it an immediate safety hazard or a maybe-next-week issue?), etc.
Huh. Here in Austin we have a car-share program with caps of $13/hr or $66/day (fuel, like insurance, is included in that price). I tend to use it as a cheap drive-it-yourself cab (bike breaks down? grab a car2go, fold the bike up and stick it in the trunk).
Over how many hours do you typically put in that 90 miles?
No, it's to make the crime a 'Class E' felony. i.e. unless superseded by state statute, a prison term greater than one year, but less than five. i.e. kiss your precious rights goodbye.
"Superseded by state statute" is pretty darned common. We'd need to actually do our research and look at whether the statute he was charged under specifies the type to determine this.
Because jails often can only hold people for one year. They give that extra day so he goes to prison instead of jail. ie. it's a worse punishment.
Actually, no, it's a more lenient sentence -- a year and a day means you're eligible for sentence reductions based on good behavior and the like; any less and you aren't.
It's not like such a team is either (1) doing things a support vendor would do or (2) idle.
It only makes sense to do such things in-house if you have a business need for the staff's skills otherwise -- and if you do, the reduced need for vendor support is icing.
That's fine and dandy if it's just your own server hooked up to your cable, but when it matters, going without support isn't a realistic option no matter how good the software is.
It's also fine and dandy if you have an in-house systems engineering team who can hack anything from the kernel through the app layer.
I've been part of that team at multiple shops. It's a pretty fun role -- lots of variety (everything from patching buggy DSDTs in the firmware of the servers we were using to extending the virtualization libraries with features we needed and pushing those upstream... and everything inbetween).
Not everyone needs a support contract, even if they're doing Serious Business. Indeed, if you're running tens of thousands of relatively cheap servers, those support contracts can be pretty expensive. (Not nearly as expensive as power and cooling, to be sure, but not entirely trivial either).
The homeowner in this article is a friend of mine (Google Cache link on account of the original being broken), and they didn't do much by way of trying to avoid his cameras.
Of course, him being armed and present did a lot more than cameras alone would have, too.
Slashdot Mirror
I am somewhat amused by the difference in our initial interpretations, though -- the Open Source proponent jumps immediately to practical matters ("you're doing it wrong" in the sense of pounding a nail with a screwdriver) and the Free Software proponent jumps immediately to moral matters. Seems somewhat representative of the differences in focus between the movements as a whole.
Please accept my apologies for insinuating ill will earlier.
Let me be clear, then. When I say "you're doing it wrong", I don't mean "in a manner which is morally wrong". I mean "in a manner which is likely impractical".
I didn't say "illegally", I said "wrong"... and then gave practical reasons why it's typically in one's self-interest to contribute upstream.
As such, I have trouble considering your post anything short of an intentional misreading.
Then you've got a decision to make, obviously -- comparing the costs of maintaining your patch in-house versus the benefit it provides.
These are fairly uncommon edge cases, however. Upstream may fairly often reject a specific implementation, but it's generally quite possible to work with them to come up with a solution for your problem which makes everyone happy.
If you're making custom software out of your OSS software, you're doing it wrong.
If you're doing it right, you're submitting your changes back upstream -- so the software doesn't "stand dead-still", as you put it, even on those times when you aren't shoveling man-hours into improvements. If you happen to be curious for some examples, google around for patches under my name submitted to open source projects over the last decade. Just about all of those were paid for by my employers -- from the OS X VNC plugin bugfix to the feature enhancements to libvirt to improved cover page generation for HylaFAX.
For the work I did at Dell, we worked together with Red Hat to get as many of the libvirt and qemu improvements we wanted as possible into the RHEL6 release schedule, enabling some of Dell's internal QA tools to work out-of-the-box with RHEL6 (whereas those same tools required heavy tweaking on RHEL5). Sure, we could have gotten the same thing done as a professional services engagement rather than a friendly collaboration between engineering groups... but this way was far easier, cheaper and lower-paperwork (and by building the patches in-house, we made sure that we got exactly what we wanted).
No surprises in this article for me.
Typically it's "bankrolling" by assigning some of your people to spend some of their time on making improvements you happen to need and contributing them upstream.
(Contributing improvements upstream means that you won't need to continually maintain your patches, that they'll eventually be included in vendor packages/kernels and thus that you'll later need to do less packaging yourself, and is otherwise a money-saving action. As a somewhat-related aside -- once upon a time I worked in embedded Linux, and you had companies who structured their default contracts for kernel work such that everything was submitted upstream, making each contract effectively a one-time engagement when everything was done right, and others who didn't... ehh... encourage their clients to pursue submitting their code, such that said clients would keep paying in to keep their patch current with newer upstream kernels).
Serious question: Why didn't the private sector bring us the interstate highway system? Would we be in a better or worse situation right now if it had?
You didn't make it clear exactly which issue you were blaming on which piece. The clarification is appreciated.
GWT builds faster-executing JavaScript than I can write by hand in a reasonable amount of time, just as a C compiler builds faster assembly than most people can build without digging in and hand-optimizing. Likewise, it builds code optimized for different "targets" -- an IE6-optimized version, an IE7-optimized version, a Firefox-optimized version, etc etc. As such, it provides the tools to build a faster site with wider browser compatibility than one would necessarily be able to build without it.
Is this to say that people can't build slow, browser-incompatible sites using GWT? Of course not -- just as people can write spaghetti code using Python; having a helpful toolchain doesn't absolve the actual developer of responsibility.
Google uses GWT for AdWords -- their cash-cow infrastructure. With such successes, pinning even partial blame for failures on that same tooling just doesn't make sense without a more detailed explanation.
So if we can't fix everything, we should fix nothing? Are you referring to total energy consumption in the context of comparative efficiency numbers by your "back where we're at today in 10 years" assertion? If so, and you expect that we'll have twice as many vehicles in 10 years, cancelling out the doubled wheel-to-well efficiency numbers... well, then, we're supporting twice as many vehicles on the same amount of energy input, and we're less dependent on foreign oil (as we're using locally-mined coal), and we're able to quickly switch our transportation infrastructure to running on nuclear energy as fast as we can bring the plants up. All of those sound like good things to me.
Sure -- but if those forum scripts don't tag such user-submitted links nofollow, they're doing it wrong.
Are you saying that a person writing a review saying "Company X screwed me!" would intentionally add semantic information to the hyperlink indicating that Company X is trustworthy? Or are you saying that the folks who own review clearinghouse sites (specifically, ones with high Pagerank values) would intentionally provide metadata contrary to the reviews that they host?
The topic for this article is presumptively honest negative reviews on trusted review sites (as other sites -- such as those run directly by the scammers -- wouldn't have the necessary PageRank "weight") pulling up the rank of the companies they pan. I don't see how adding the opportunity to provide metadata with hyperlinks (with the nofollow tag as a trivial example) would in any way make the problem worse.
That's the job of the BBcode rendering engine. If they're not adding rel=nofollow universally (or, at minimum, by default), the folks maintaining the relevant libraries need a smack upside the head.
Fair enough; see Debunking the Myth of EVs and Smokestacks for one source. I'll be citing numbers from that same paper below.
With respect to pollution, switching to grid power dramatically reduces hydrocarbons and carbon monoxide (to the tune of >95%), substantially reduces nitrogen oxides, and will substantially increase sulpher oxide and particulate output in countries (including both the US and UK) where coal- and oil-fired plants are common (while reducing them in other areas such as France and Japan).
Overall efficiency, by contrast, is far less ambiguous: Electric vehicles themselves get about 88% efficiency; after taking into account power plant efficiency, transmission efficiency and charging losses, that number goes down to 28% overall -- but this is still wildly favorable to 14% overall (15% vehicle efficiency, 8% losses during the refining process) for internal combustion engines.
This is still wildly expensive in terms of BTUs-per-mile compared to simply using lighter and more-efficient vehicles... but eh, gotta' start somewhere. :)
Feel free to present your own, competing sources.
A single modern coal-powered plant is better than hundreds of thousands of individiual internal combustion engines it replaces in this case.
What's more, the plant can be monitored and upgraded all at once, in one place. An individual vehicle's spark timing is off and they're blowing unburned fuel out the back and it doesn't get fixed 'till they next fail inspection, and that assumes they're complying with the law by bringing their vehicle in for inspection at all.
Seriously -- I'd take nuclear over coal any day, but centrally burned coal is far better than the status quo. (What's especially fun is how folks make the same argument you do here in Austin -- where our electricity is natural gas, nuclear, hydroelectric, and less than 30% coal).
Having written applications with GWT, I find it anything but unwieldy.
Bringing static checking, JUnit-based testing, and modern code coverage tools to JavaScript (and doing a ton of micro-optimizations during the compilation process under the hood) does a world of good. Letting Java-based debugging tools be seamlessly used for debugging JavaScript is even better.
I've seen attempts to implement a GWT-like toolchain for other languages (Python, Scheme) -- and the competition all falls down not on having effective code compilation, but on having an effective debugging toolchain and workflow. Google, by contrast, got that part right.
Actually -- based on feedback from another commenter in this thread, I'm thinking of proposing to Austin (via the bicycle program manager, who knows the rest of the folks involved) that we consider adopting Portland's open source smartphone apps for problem-reporting. Haven't looked into what the server side needs to implement yet, but I'd be surprised if it'd be too ridiculous.
Hmm. I'd care about this much more for 311 (that is, the non-emergency catch-all city services line). Email wouldn't be bad either.
Seriously -- being able to send a photo of a pothole or a tree branch hanging too close to the road or someone illegally parked in a bike lane on a curve after a steep downhill (yes, there's an area on my commute matching exactly that description) with a GPS tag on the photo and a line or two of text would be much more convenient than pulling over and spending 5 minutes trying to figure out the address, walk the operator through deciding how to file the ticket (is it an immediate safety hazard or a maybe-next-week issue?), etc.
So -- now we know the mechanism behind Nerd Sniping.
Huh. Here in Austin we have a car-share program with caps of $13/hr or $66/day (fuel, like insurance, is included in that price). I tend to use it as a cheap drive-it-yourself cab (bike breaks down? grab a car2go, fold the bike up and stick it in the trunk).
Over how many hours do you typically put in that 90 miles?
"Superseded by state statute" is pretty darned common. We'd need to actually do our research and look at whether the statute he was charged under specifies the type to determine this.
Actually, no, it's a more lenient sentence -- a year and a day means you're eligible for sentence reductions based on good behavior and the like; any less and you aren't.
It's not like such a team is either (1) doing things a support vendor would do or (2) idle.
It only makes sense to do such things in-house if you have a business need for the staff's skills otherwise -- and if you do, the reduced need for vendor support is icing.
It's also fine and dandy if you have an in-house systems engineering team who can hack anything from the kernel through the app layer.
I've been part of that team at multiple shops. It's a pretty fun role -- lots of variety (everything from patching buggy DSDTs in the firmware of the servers we were using to extending the virtualization libraries with features we needed and pushing those upstream... and everything inbetween).
Not everyone needs a support contract, even if they're doing Serious Business. Indeed, if you're running tens of thousands of relatively cheap servers, those support contracts can be pretty expensive. (Not nearly as expensive as power and cooling, to be sure, but not entirely trivial either).
Only if they're smart, and paying attention.
The homeowner in this article is a friend of mine (Google Cache link on account of the original being broken), and they didn't do much by way of trying to avoid his cameras.
Of course, him being armed and present did a lot more than cameras alone would have, too.