Both H (Bill Hewlett) and P (Dave Packard) were at Stanford prior to WW2. And Silicon Valley pre-dates the Internet era. See Fairchild Semiconductor, The Treacherous Eight, etc.
I think it is because we (as a community) should be past the piling-on stage and on to the constructive discussion stage. Snark doesn't add to the discussion.
I don't intend to jump into the ring, but as an observer, I don't think we're at that point yet. Here's the progression of the current anti-PHP flare up:
Jeff Atwood says PHP sucks
|- Says we should make other languages fill in on what PHP does best
|- Post goes on HN
|- PHP apologists say "No! PHP is fine, I've made a career out of it!"
|- 'Atwoodians' continue to reject PHP, ruby/python need to be more accessible
|- PHP apologists make reasonable arguments for why PHP isn't as bad as everyone says, while admitting its probably worse than python/ruby
There remains a conspicuous lack of response from the 'Atwoodian' camp regarding what could be done to add PHP's quick-start strengths to other languages so that PHP developers can develop similarly to how they currently do, just with a less wonky and problematic base language.
By no means, as an outsider, do I perceive the PHP apologists as having redeemed PHP to the point that the discussion should be about 'how to fix PHP' rather than 'how to discourage its propagation' as was originally put fourth in a fairly reasonable way by Atwood.
I realize why saying 'PHP apologists' is problematic, but I'm mostly seeing responses that are in themselves critical of PHP, while espousing its widespread use, quick-start capabilities, and developer intertia--and not espousing why the fundamentals of the language are better of the equals of ruby/python.
While I can't speak for others in the "Atwoodian camp," I for one think Atwood's article was that response, to a large degree: it pretty much said that his next big project is trying to bring those strengths to a platform built on another language.
Having said that, it seems to me that there's certainly a fair amount of work being done to make deploying apps in other languages pretty simple. With mod_passenger, for instance, setting up a Rails app under Apache isn't notably more difficult than setting up any other Apache virtual host. Deploying Python web applications isn't quite as simple yet (at least in my experience), but it's nothing that should be beyond the ken of someone who's figured out how to write a Python web application in the first place. And that, in turn, isn't really beyond the ken of anyone who's learned how to write reasonably good PHP MVC code.
Even if Cisco was running open source code they could still put ALL of this language into this agreement. The difference would be you could see the actual mechanism in work if they had open source code. The egregious part is the language, not the implementation.
Well, even though I'm pretty technically literate and know my way around a compiler, I probably couldn't do this, even with the source. There's so much knowledge that you need to accumulate. I could probably learn how to do it, but that would take me weeks, if not month. So first, somebody would have to do it. Second, he'd have to maintain it. Then, my less-computer-literate friends would need someone who makes them aware of the issue and points them to the firmware, probably even install it. Most won't bother, check the box and accept the TOS, maybe thinking "I'm not planning on doing anything illegal anyways." - that won't be solved with open source.
Open source protects the technical literate people, but it's not the silver bullet that solves this issue. Raising awareness and pushing back is at least as important and that's possible with closed source as well.
While I agree with your point Open-source is not a silver bullet. I don't see anything other than Open-source as a good enabler.
Yes, pushing back is possible with closed source as well.
The real question becomes, which is harder? and for who? To push back at closed source, you'd have to be a big consumer of them or atleast big enough to be able to sue the vendor. If you're an individual, you're in real trouble. Of course, there are people who play both roles.
And I see Open-source as the best enabler for technical individuals. As far as i can see, of course.
I think the main difference is that if these routers came from the factory with FLOSS software that I could recompile and reload onto the device then Cisco would have a much harder time actually enforcing their particular implementation.
I think you're right, and that actually worries me more. Amazon likes to sell books for under $10, many ebooks I've bought are $5 or $7.
Maybe it has something to do with the book it's self (i.e. they charge $0.07 per image), but do they mention how this is calculated anywhere?
If I sell an ebook for $2, they take $0.60 in general, and then they decide that it costs $0.80 to deliver... that means they're taking 70% of the cost of the book. So if I'm successful and have to pay taxes, I may be making like $0.12 per book.
I don't remember every seeing this cost mentioned before in the few articles I've seen about selling Kindle books. I'd love to know how it's calculated.
This may be ignorant and please correct if I am off base but given the same physical medium isn't sending 2k across the network the same cost whether you are at fastE or gigE? Given the network is not saturated?
fastE is 100Mbits/sec, gigE is 1000Mbits/sec, so given the same size packet, gigE is in theory 10x faster.
However, to make things work over copper I believe that gigE has a larger minimum packet size so it's not quite apples to apples on pings (latency).
For bandwidth, the max size (w/o non-standard jumbo grams), is the same, around 1500 bytes, and gigE is pretty much linear, you can do 120MB/sec over gigE (and I have many times) but only 12MB/sec over fastE.
Some day I need to do a post about what I learned from SGI's numa interconnect. I used to think big packets are good, that interconnect taught me that bigger is not better.
If I have 1000Mbits to send then gigE is 10 times faster. But in the article we are transferring only 2k across the network. Mixing latency and bandwidth here. The latency to send 2k across an empty network isn't 10 times greater on a fastE versus gigE network, right?
2K is going to be 2 packets, a full size and and a short packet, roughly 1.5K and .5K.
For any transfer there is the per packet overhead (running it through the software stack) plus the time to transfer the packet.
The first packet will, in practice, transfer very close to 10x faster, unless your software stack really sucks.
The second packet is a 1/3rd size packet so the overhead of the stack will be proportionally larger.
And it matters _a lot_ if you are counting the connect time for a TCP socket. If this is a hot potato type of test then the TCP connection is hot. If it is connect, send the data, disconnect, that's going to be a very different answer.
Not sure if I'm helping or not here, ask again if I'm not.
