MixPanel tracking API down - <AUTHOR> http://status.mixpanel.com/ <comment><USER2> Hi everyone,

We believe we have figured out the problem and have already gone ahead with a solution. The issue, at this time, appears to be that the traffic we normally get to our API has increased substantially. Whether it's legitimate or not is unknown but we're unfortunately at the mercy of waiting for DNS to update. It's also possible we may see bottlenecks further down our infrastructure path but we're actively thinking through what's next - fortunately, we have more control there.

We'll have a full transparent write up once things are back to normal.

If you're using our JavaScript libraries, your website should not be greatly affected by our downtime other than the data that will be lost. We're deeply sorry and disappointed ourselves.

Our support team is happy to talk to you at status.mixpanel.com to give you updates as they get them.

Suhail

<comment><USER3> Suhail, with regard to impact on installed sites I agree that lost event data is not the end of the world. However, it's currently taking 20-30 seconds for requests (inserting the mixpanel js) to timeout. During the outage, it would be much less painful if the requests were failing more immediately.

I just sent this same message to support (at) mixpanel.com.

EDIT: just to reiterate -- the major problem isn't the API being down. It's the extreme timeouts being experienced trying to load a static JS file.

<comment><USER4> I completely agree. I woke up to some crazy long page rendering time on NewRelic and couldn't figure out what was going on... until I saw the huge backlog of mixpanel events on my db. Not only is it making page rendering slow, even worse, it's tying up my background workers for 30 seconds at a time, causing a huge backlog on ALL my background tasks.

<comment><USER5> Same here. I wish we had an MP widget that insulated us from downtime from the mixpanel API.

</comment></comment></comment></comment><comment><USER6> This is unfortunate. I was about to implement MixPanel on my startups site (it already laced in our development code), but their API being down completely locks our application ... actually shipping MixPanel in production not looking so hot right now.

EDIT: As others have voiced my issue was that it was taking up to 30 seconds for requests to timeout disrupting various things in my JS code (it is a Backbone app) -- it didn't actually "lock" it. I was using the JS API.

<comment><USER7> As somebody who consumes a few of these things, and got a pager about it prior to it being on HN, this is something that a) will inevitably happen and b) should not block the application. Think very, very carefully before you ever block the request/response cycle on an external API. (I'd say "Never do it" but I think I could come up with conceivable apps and APIs where that makes sense if I was fully awake.) Since analytics callbacks don't generate immediate customer value and can fail totally without discomfitting anyone, you should never block a request for them.

Instead, you deal with them asynchronously. There's a few ways to do it mechanically. I offload them to my job queue and set the priority to "lowest possible." When the job queue is otherwise empty, a worker process (that no actual human is waiting on) slurps up a few of the events and fires them off.

Only downside, which I never bothered fixing: I have an "OMG the queue is stuffed to overflowing... the queue worker must be non-responsive!" monitoring test which, since that symptom has featured in most of my customer-visible downtime, generates a red alert. (i.e. Immediate SMS followed by phone call escalation, as opposed to an "FYI check this" email.) Any downtime at Mixpanel or KissMetrics lasting longer than a few minutes reliably triggers this alert.

On the plus side, this means that when I tell you "Mixpanel really doesn't fail at 2 AM Japan time all that often" you should trust that I'd have noticed.

<comment><USER8> I (and I'm sure other HNers) would love it if you couldgo into a little bit more detail as to how your job queue is constructed.

<comment><USER7> Code-wise: Delayed::Job <https://github.com/collectiveidea/delayed_job>

Design-wise: Two queue worker processes independent of web server processes. Delayed::Job lets you assign tasks a priority and lets you assign queue workers to priority levels it is allowed to look at. By convention, priority 0 (highest) is interactive tasks in my applications (a user is at their keyboard waiting for an answer) and priority 10 (least priority) is, well, Mixpanel. Not because I don't love them, just because if Mixpanel blocks for an entire month my rent still gets paid and that isn't true of any other priority level.

Queue worker A only works on priorities 0 through 9. Queue worker B works on 0 through 10. This ensures that even if Mixpanel (or Kissmetrics, also on 10) perpetually times out the higher-priority levels will never be totally blocked.

Delayed::Job worker processes are monitored by god, which resets them if they fail, become bloated, etc. They're also separately monitored by Scout monitoring's DJ plugin, which fires a yellow alert if a job is ever older than an hour (shouldn't happen but can in event of e.g. an API outage) or a red alert if there's ever more than X jobs in the queue (high probability that this represents a crash god can't recover from).

Because even that setup was letting through about one outage every six months to a year, I have one other ace-in-the-hole: my ajax polling actions which check whether particular jobs are complete will, if they fail Y times in a row, a) instantiate a queue worker within the web server process (this degrades request processing but can't totally break the site) and b) fire off an independent-from-everything-else phone call to my cell phone saying "Your first, second, and third line of defense have failed. Get ye to an SSH terminal."

</comment></comment></comment></comment><comment><USER9> This is why I queue all my mixpanel requests on the server. I'll just re-run them once it's back up.

<comment><USER10> This is a great idea! Do you mind letting us know what your setup's like?

<comment><USER11> We just issue Celery jobs to track events in Mixpanel, so if their API is failing, the jobs fail and get retried later on.

If we get too many messages accumulated in the queue where these jobs go, we just purge it (better lose that data than let RabbitMQ die because of memory exhaustion). Although there have to be a whole damn lot of events there for us to actually notice

<comment><USER10> Really neat! I might be a newbie to this, but how do you get those client-side javascript function calls over to the serverside? I am assuming the client's browser is running the Mixpanel Javascript and that your events are serverside.

<comment><USER11> Yep, like rprime said, we're sending tracking events from the server (let me plug <http://libsaas.net> here).

So instead of using mixpanel.track from Javascript, you do an AJAX call to your own server and schedule a Celery job there.

There's an issue with passing Mixpanel's super properties to your server-side handler, but that's the general idea.

<comment><USER10> Gotcha, I'm going to have to try this, thanks for the insight!</comment></comment></comment></comment></comment></comment>


Don't Just Sit There: How bathroom posture affects your health (2010) - <AUTHOR> http://www.slate.com/articles/health_and_science/science/2010/08/dont_just_sit_there.html

<comment><USER2> I have no idea why I feel the need to share this.

Squatting is the best way to crap. At work, I can't squat. Trust me, I feel it.

I have a lot of friends that can easily spend up to 5 ot 10 minutes at the toilet. Let me simply say that this never happens to me.

I won't say any more.

<comment><USER3> You are right. At my house I place one of those gym steps in front of my toilet and actually feel my body out of wack when I have to use other restrooms.</comment></comment>


Oracle Announces an In-Memory Technology, At an Ungodly Speed And Cost - <AUTHOR> http://blog.memsql.com/oracle-announces-an-in-memory-technology-at-an-ungodly-speed-and-cost/

<comment><USER2> "Just like mainframes, appliances don't fit in the new world where customers think in terms of nodes in data centers, availability zones, and geographically distributed storage and compute. The new world is being built on distributed systems."

Oh yes...mainframes that have been developed over decades catering specifically to enterprise needs are far less superior than what a group of 20-something engineers at a social media company came up with.

Excuse the sarcasm, there are certainly places where distributed in-memory data stores on commodity hardware are a fine solution. That does not mean its taking over mainframe computing because that solves a completely different class of problems.

<comment><USER3> I think that mainframes are the solution to the problem that some applications run well only on a single machine. Most software has been cluster-fied, but there's one big one that is left: databases.

Mainframes are more expensive per-CPU-unit or per-IOPS. Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket. (The tradeoff is that your software is more complicated and likely introduces new failure scenarios).

So, although mainframes are indeed optimal for today's database, the NewSQL hypothesis is that different database software will be able to run on multiple machines, and so the mainframe will no longer be the optimal solution. This (hypothesized) database would run on a cluster of commodity machines, and should therefore be cheaper and hopefully more reliable. Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.

Of course, this relies on a new breed of database.

<comment><USER2> Very interesting points.

'Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket.'

'Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.'

My one comment on those points is that distributed computing solved Google's problem, and of course applies to what many software companies are trying to do (amazon, yahoo, etc.) But do they have an answer for the set of problems where 100% ACID compliance and high-availability is a requirement?

<comment><USER4> ACID compliance is not ever a strict requirement, it's an abstraction guarantee. If you have a fully ACID compliant database with a sufficiently expressive query interface, then the complexity of the datastore is a perfect abstraction.

The ATM machines people use every day to exchange money are not fully ACID compliant, and they do not use "transactions". It's a calculated choice on the design of the system to account for the guarantees in different ways and balance discrepancies that occur after the fact.

If you need full ACID compliance and need to operate at "Google scale", you reorganize the problem so that you don't need the compliance.

</comment></comment></comment></comment><comment><USER5> I've been told that Terradata runs $1M/TB. So Larry is kind of right about the cost relative to his peers.

The columnar store I use are in the $10K/TB range running on $10-25K servers.

I think Oracle is going to have trouble with this space.

<comment><USER6> Which columnar store do you use?

<comment><USER5> Some HP Vertica and some Actian Vectorwise. Vertica scales to multiple nodes better and HP is a much more accepted vendor. I've got friends who are doing a lot of Redshift (which is repackaged ParAccel). Start with Redshift if you are new to columnar.

If you can afford it, Microsoft's new PDW looks like a much richer functionality columnar store.

</comment></comment></comment><comment><USER7> Does anyone remember their acquisition of TimesTen? I've used it in production (HF trading) but it didn't seem to gain that much broad traction. Is this just TimesTen in a SPARC-packaged bundle? Perhaps IBM's plan to sell / phase out its POWER server business has something to do with the re-branding of TimesTen to this. [1]

[http://www.oracle.com/technetwork/products/timesten/overview...](http://www.oracle.com/technetwork/products/timesten/overview/index.html)

<comment><USER8> IBM are not selling or phasing out Power. They are investing $1bn in Linux on Power and opening up the platform.

</comment></comment><comment><USER9> Looks like it is designed to compete with the likes of SAP HANA.

And remember that you go with Oracle for more than just technology.

<comment><USER10> > And remember that you go with Oracle for more than just technology.

Can you explain this? In my experience, you used to go with Oracle for technology but that was about 15 years ago.

<comment><USER11> Industry acceptance too.

In the heath care industry, it doesn't matter what you make, it doesn't matter how good it is, and it doesn't matter how proven it is.

If you don't say the word "Oracle", you don't get the contract.

<comment><USER12> Source?

Talk to Judy at Epic and you get a different opinion. Actually, talk to almost anybody I've ever met in my 10 years in healthcare and you'd get a different opinion.

</comment></comment></comment></comment><comment><USER13> The article mentions Fusion IO drives for $2k/TB; any idea who sells them at that price? If I check [1], it's a lot more expencive. At $2k/TB, it would be worth it to buy and compare it to our Netezza. If it can compete, awesome, if not, I can beef up one of our normal SQL servers.

[1] [http://www.solidstateworks.com/ioDrive- Octal.asp](http://www.solidstateworks.com/ioDrive-Octal.asp)

<comment><AUTHOR> [http://www.storagepricing.org/fusion-io-pricing-at-ces- with-...](http://www.storagepricing.org/fusion-io-pricing-at-ces-with- ioscale/)

And $1/Gb is coming soon

<comment><USER13> But that's still more for resellers or large quantity buyers. I wasn't planning on getting 100TB; I was just looking for 1-2TB to load a demo set and compare to some of the stuff we do on our netezza. It's too bad there is no Microsoft Technology Center near where I could take this for a test drive...

</comment></comment></comment><comment><USER14> As per [http://www.dbms2.com/2013/09/23/thoughts-on-in-memory- column...](http://www.dbms2.com/2013/09/23/thoughts-on-in-memory-columnar-add- ons/), this new technology makes a lot of sense if you're committed to Oracle, and have the huge IT budgets to make such a commitment possible.

If you're just starting out, however, Oracle is rarely close to being cost- effective.

</comment><comment><USER15> What is the good use for a this vs a standard key value store like DynamoDB or a document db like MongoDB?

<comment><USER9> Lots of reasons. It supports SQL, you can gradually move data to the in-memory stores, DBAs/Operations teams already know how to manage it and it is well supported. Plus it would destroy both DynamoDB and MongoDB in certain use cases.</comment></comment>


Show HN: Geek Canteen, Healthy Food for Developers - <AUTHOR> http://www.geekcanteen.com/ <comment> git-pull Ideas:

\- Low-carb and Keto

\- Meals with Shirataki noodles

Monetization:

\- Link to ingredients on Amazon affiliates

\- Link to cooking supplies used in videos on Amazon affiliates

\- Make an app that stores your recipes

\- In the app, make a random button to switch through recipe ideas quickly

\- Charge 2.99 for packs of 30 recipes

\- Allow faceting through recipes by nutritional concerns, carbs, macros, etc.

\- [https://developers.google.com/search/docs/data- types/recipes](https://developers.google.com/search/docs/data-types/recipes)

\- Get into supplements

\- Feeds > Email lists. I'd even say email lists are an antipattern. Offer ways for users to stay in touch without giving an email, that's a bit of a one sided deal. Go for Twitter, Facebook, YouTube etc. That way you can have your cake and eat it too, not annoying users, and letting them stay up to date with your content.

<comment><USER2> Hey! Thanks so much for your response! Love the ideas, will definitely keep them in mind.

Regarding monetization, that's exactly the strategy I was planning to go for. Probably even more integrated as in, that you can simply click on add to cart in the shopping list and then you have all the necessary ingredients together without opening Amazon separately.

Actually for the start, email lists have a very good conversion. At least to get the word out. But I totally see your point. I will move up the current social buttons more to the top so that it's easier to get in touch also via other channels.

</comment></comment><comment><USER2> Hi everyone! I'm the original founder of geek canteen! I'm happy to answer any questions you might have or discuss feedback. This was posted by my husband who encouraged me to act on this idea in order to make healthy food more approachable to busy developers like himself.

</comment><comment><USER3> Just curious--why did you make this a phone app I have to install, rather than just a web app? Making the first step of the onboarding process having to install the app makes it more difficult for users just to give it a try.

<comment><USER2> Thanks for that feedback! That's an interesting perspective. I'll keep that in mind.

</comment></comment><comment><USER4> If you don't mind me asking, what is the monetization strategy here?

I don't see any privacy policies, or just what you will be doing with my information that you are asking users to submit.

I like the idea, but want to know about any service before interacting with it.

<comment><USER2> Hi Meph! Monetization will be two-fold: Amazon affiliate & a subscription model based on the amount of recipes one wants to receive.

You're absolutely right about the privacy policies. I'm already getting it prepared by a lawyer, I'll update the page as soon as I have the final version. But that much I can say, the email addresses are stored on a Mailchimp server and will only be used to send a weekly newsletter with new video recipes until the actual app is developed.</comment></comment>


3 things you can learn from Rock Stars - <AUTHOR>

<comment><AUTHOR> 1- DEMO EVERYWHERE When rock stars have nothing more than a a beat-up old van, they sing for everyone for free or money. DO the same thing. Any chance you have Demo your app.

2- FORGET INVESTORS (just for a little while ) Have you ever heard of Bing Jong? No!! You know why? Becasue he made only 3 songs and went around every record label on earth trying to get a million dollar deal. Forget it. Launch it. Investors will find you faster than you can spell FAST if you are good.

3-RECORD SONG EVERY DAY AND RELEASE THEM Rock stars always record and release. Why would your audience want the same features? Improve them, Give them something new whenever possible.

Bonus: And always remember this one, if you paid a starving rock star all the money in the world to throw his guitar over the bridge, You would probably end up in the water. Never Quit.</comment>


This is the real reason the Tesla Model X has a Bioweapon Defense Mode - <AUTHOR> https://innovately.wordpress.com/2015/11/20/this-is-the-real-reason-the-tesla-model-x-has-a-bioweapon-defense-mode/ <comment><USER2> HEPA stands for "high-efficiency particulate arrestance", not "high-energy particulate arresting"</comment>


Former Yahoo COO Who Almost Bought Facebook Shows Up on IPO Day - <AUTHOR> http://mashable.com/2012/05/18/rosenwig-facebook/

<comment><USER2> It seems like Yahoo is synonymous with Failure.</comment>


Famous Laws of Software Development (2017) - <AUTHOR> https://www.timsommer.be/famous-laws-of-software-development/ <comment><USER2> Regarding Conway's Law:

We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure.

\- Inverse Conway Law or just Roy's Law ;-)

Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams.

But after we switched to microservices the teams became responsible for just a part of the system, their microservice(s). Whenever we had an outage, one team was left to fix it, the others just went home. They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices.

<comment><USER3> > They stopped talking to each other because they didn't share any code, no > issues... they stopped having lunch together, some things got way worse in > the organisation, all sparked by a 'simple' architectural change, moving to > microservices.

Honestly, this sounds like an improvement.

<comment><USER4> How is people not talking to each other an improvement?

<comment><USER3> Oh, it is definitely a problem from a social/cultural standpoint. But from the point of software architecture (and, therefore, development organisation), too much (or even any) communication between teams working on discreet, separate units can become detrimental.

It is perfectly fine that the people communicate, and even helping each other to improve tech skill should be encouraged; however, decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation.

<comment><USER4> > decisions about their respective products should be contained within each > team, with clearly defined interfaces and usage documentation.

In order to make those decisions and define the interfaces, you need to know a lot about how your software is going to be used. That will be much easier if you have good communication with the other teams and understand their goals and motivations.

<comment><USER3> I disagree. In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line.

The main advantage of distributed system, and particularly microservices, is the ability to have each system completely independent: individual components can be written in different languages, running on different platforms and use completely independent internal components. Basically, it is just like using an external library, component or service: the authors provide documentation and interfaces, and you should be able to expect it to behave as advertised.

<comment><USER4> > In my experience, direct coordination on interfaces tends to create > unnecessary special cases (hey, can you add this field to your API, just for > us?) which add complexity and make maintenance more difficult down the line.

If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: take the time to understand _why_ your partner teams/engineers are requesting certain changes and figure out the right interface to address their problems.

<comment><USER3> Oh absolutely, but direct communication between teams is not the right method for that. Which is why every product, no matter how "micro" a service, needs to have a dedicated product owner/manager who is responsible for defining functional requirements.

Edit: I just noticed that "PM" in parent comment. Basically, product managers are not just for UI and customer-facing products.

<comment><USER5> The idea that "functional requirements" can be decided independently from "technical architecture", as opposed to in interplay with each other, is exactly the opposite of what I've learned from good experiences with "agility", although some people seem to somehow take it that the opposite.

But yes, you can never just do what "the users" ask for. The best way to understand what they need is to be in conversation with them. Silo'ing everyone up isn't going to make the overall product -- which has to be composed of all these sub-components working well with each other -- any better.

<comment><USER3> > The idea that "functional requirements" can be decided independently from > "technical architecture"

Oh it absolutely can; it's just that it usually is not a good idea. But I'm not talking about the _process_ of reaching that decision, I'm talking about the _responsibility_ to reach them. Functional and technical decisions are separate, but in most cases should be defined in conjunction.

> Silo'ing everyone up isn't going to make the overall product

This is true for certain types of product, and less so for others; you need to clearly understand what type of product you're building, and be ready to adapt as it changes (or you have a better understanding of it). In a nutshell, the more compartmentalised a product is, the isolation between the teams becomes more beneficial. Which brings us full circle back to Conway's Law.

<comment><USER5> > But I'm not talking about the process of reaching that decision, I'm talking > about the responsibility to reach them

Of course you're talking about the process. Your claims that "direct communication between teams is not the right method for that," and "communication between teams working on discreet, separate units can become detrimental," for instance, are about process.

I don't think this conversation is going anywhere, but from my experience, lack of communication between teams working on discrete, separate units (that are expected to be composed to provide business value), can become detrimental. And that's about process.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Hyrum's law is highly relevant to anyone who makes software libraries.

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."

I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Windows.

Http://www.hyrumslaw.com

<comment><USER7> They might become part of the API in a superficial sense, but if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk and won't have a valid complaint if they want the not-covered-by-the-contractual-API preserved or become surprised by a change.

<comment><USER4> > if you broadcast clearly that undocumented behaviors are subject to change, > then users can decide if they want to accept that risk

That sounds nice in theory, but doesn't really work in practice. If you're building infra and a core piece of your company's product relies on these undocumented behaviors, you can't just change the behavior and shrug your shoulders when the whole product breaks. Similar if you're providing an external API to users/customers, you can't just break their stuff without worrying about it.

<comment><USER8> I'd add, if the API is meant to implement a protocol but doesn't implement it quite correctly, you may object to the misimplementation, but if your code has to work with the implementation, you have to adapt to their bug. It's not even a matter of undocumented behavior.

Experienced recently as a consumer of an API when letsencrypt made a breaking change to implement the protocol correctly. Broke my code which relied on their original incorrect implementation.

</comment></comment></comment></comment><comment><USER9> There are some better lists for laws of Software Development:

[1] [http://www.globalnerdy.com/2007/07/18/laws-of-software- devel...](http://www.globalnerdy.com/2007/07/18/laws-of-software-development/)

[2] [https://exceptionnotfound.net/fundamental-laws-of- software-d...](https://exceptionnotfound.net/fundamental-laws-of-software- development/) (not so good but with solid discussions from HN [https://news.ycombinator.com/item?id=11574715](https://news.ycombinator.com/item?id=11574715) )

And more:

[3] [https://embeddedartistry.com/blog/2018/8/13/timeless-laws- so...](https://embeddedartistry.com/blog/2018/8/13/timeless-laws-software- development) (a whole book titled _Timeless Laws of Software Development_ )

[4] [https://www.red-gate.com/simple-talk/opinion/opinion- pieces/...](https://www.red-gate.com/simple-talk/opinion/opinion-pieces/some- laws-of-software-development/)

[5] [https://www.netobjectives.com/blogs/some-laws-software- devel...](https://www.netobjectives.com/blogs/some-laws-software-development)

[6] [http://www.methodsandtools.com/archive/softwarelaws.php](http://www.methodsandtools.com/archive/softwarelaws.php)

</comment><comment><USER10> It's very common for Conway's law to be regarded as some kind of warning, as if it's something to be "defended" against. It's not. Conway's law is the most basic and important principle to creating software at scale. A better way of stating Conway's law is that if you want to design a large, sophisticated system, the first step is to design the organization that will implement the system.

Organizations that are too isolated will tend to create monoliths. Organizations that are too connected and too flat will tend to create sprawling spaghetti systems. These two cases are not mutually exclusive. You can have sprawling spaghetti monoliths. This is also one of the dangers to having one team work on several microservices; those microservices will tend to intermingle in inappropriately complex ways. Boundaries are critical to system health, and boundaries can be tuned by organizing people. Don't worry about Conway's law, leverage it.

</comment><comment><USER3> There is an error in the ninety-ninety rule, which should be stated as:

        The first 90% of the code takes the first 90% of the time. The remaining 10% takes the other 90% of the time.

<comment><USER11> A personal rule of thumb I derived from the ninety-ninety rule is this: "Before starting a project, ask yourself if you would still do it if you knew it would cost twice as much and take twice as long as you expect. Because it probably will."

<comment><USER12> Twice is a (reasonable) minimum.

<comment><USER13> I see the 90% rule as a recursive function: First we get 90% of the whole work in the first iteration, then 90% of the remaining code (now we are 99% complete), then 99.9% and so on.

The iteration is stopped when the software has enough features and an acceptable level of bugs to be considered complete. What complete is depends entirely on the field of the software. For a proof of concept software we can stop after the first iteration, but for a safety critical software we might need 3, 4, or even more itarions.

<comment><USER14> I like this, it rings true in my experience.

</comment></comment></comment></comment></comment><comment><USER15> Murphy's Law has electrical engineering roots. I have a fun anecdote.[0] My wife is electromechanical and I'm computer science so we would work on projects together since we make a good team. I remember in college I was working with my wife on one of her projects and we were using force transducers. The damn things kept breaking at the worst times so we kept calling it Murphy's Law. After a while we looked it up. Turns out Murphy was working with transducers when he coined the phrase [1]. So I have this little back pocket anecdote about the time I got to use Murphy's Law in the original context. Which I can bring out in times just like this.

[0] I think it is fun. Your milage may vary.

[1] [https://en.wikipedia.org/wiki/Murphy%27s_law](https://en.wikipedia.org/wiki/Murphy%27s_law)

</comment><comment><USER16> Everyone always conveniently forgets Price's Law (derived from Lotka's Law) It states that 50% of work is done by the square root of the number of employees.

Interestingly, Price's law seems to indicate 10x developers exist because if you have 100 employees, then 10 of them do half of all the work.

This idea is particularly critical when it comes to things like layoffs. If they get scared and leave or they are let go for whatever reason, the business disproportionately suffers. Some economists believe that this brain drain has been a primary cause in the death spiral of some large companies.

<comment><USER17> > Interestingly, Price's law seems to indicate 10x developers exist because if > you have 100 employees, then 10 of them do half of all the work.

Or 0.1x developers exist...

<comment><USER16> You have to completely abandon reality to get rid of the idea. If 60 of the remaining 90 devs did NOTHING, those 10 devs would still be 2.5x better than the rest.

To take things further, make a bell curve chart. Put 50% of the area under the top 10%. Now, divide up the rest however you'd like. The only way to make this happen is for a huge percent to not only contribute zero, but to be actively hurting development to an extreme degree.

I have never found a 100 person company where 60% or more of the company was contributing absolutely nothing. I have never seen a company where a large number of people were actively harming the company and the company survived.

<comment><USER17> My understanding of your model must be inaccurate somehow. Here's what I think I'm hearing:

\- the distribution of productivity of devs in an organization of N * N devs can be approximated as: N devs who are "Nx", and the rest of the devs are "1x" (Price's Law, assuming a binary distribution for simplicity)

\- the value of "x" is constant for all sizes of organization (if it were relative "some are 0.1x" would be a change of units, not an abandonment of reality)

This would yield the extremely surprising result that the total dev production of an organization scales quadratically with the number of devs, so what am I misunderstanding?

<comment><USER16> It actually looks more like an exponential curve with 50% of the area under the curve fitting in the last few devs. If we normalized the "flat" side of the curve to be a 1x dev, the we probably have 80 1x devs, 5 2-3x devs, 5 4-6x devs and 10 8-9x devs.

Rather than quadratic scaling, we're dealing with scaling by root. This actually meshes very well with the "mythical man month"

If we almost double from 100 devs to 196 devs, we only go from 10 to 14 devs doing half the work.

We've already accepted that 10 devs were doing half the work of 100 devs. We've also accepted that those devs must be giving it their all. So, doubling the devs, but only getting 4 new people to fill the doubled top 50%. Either we have some new 20x devs or the actual amount of work hasn't increased at the same rate.

I would still say that is probably incorrect though. The "mythic man month" doesn't apply to total work done -- only to total _useful_ work done. As the social complexities increase, the ratio of other work decreases, but the those top developers will still have to carry both increases (to at least some degree) in order to still be doing half the work.

I suspect that as the social overhead increases, you should see three interesting cases. Those who can deal with the social overhead more quickly, so they have more real work time to compensate for being slower at it (potentially bumping a 5x dev with better social strategies higher). You could see the opposite where a 10x dev simply loses all their time in meetings. You could also see where a 1x dev with better social strategies handles most of a 10x devs social workload so that dev can instead focus on coding (it's rare, but I've worked on teams with 1-2 devs who did little except keep the team productive by fending off the bureaucracy).

</comment></comment></comment></comment></comment><comment><USER18> I have always liked Postel's law (and Jon -- what a great human being he was) but I no longer like it as I used to.

The reason it's a really great idea is that it says you should engineer in favor of resilience, which is an important form of robustness. And at the same time, "strict in what you send" means "don't cause trouble for others.

However there are cases where "fail early" is more likely to be the right thing. Here are a few:

1 - Backward compatibility can bite you in the leg. For example, USB Type C (which I love!) can support very high transfer rates but when it can't it will silently fall back. So you could have a 40 Gbps drive connected to a 40 Gbps port on a computer via a cable that only supports USB 2 speeds. It will "work" but maybe not as intended. Is this good, or should it have failed to work (or alerted the user to make a choice) so that the user can go find a better cable?

2 - DWIM is inherently unstable. For users that might not be bad (they can see the result and retry) or terrible ("crap, I didn't mean to destroy the whole filesystem").

I see these problems all the time in our own code base where someone generates some invalidly-formatted traffic which is interpreted one way by their code and a different way by someone else's. Our system is written in at least four languages. We'd be better off being more strict, but some of the languages (Python, Javascript) are liberal in both what they accept _and_ generate.

This aphorism/law was written for the network back when we wrote all the protocol handlers by hand. Now we have so many structured tools and layered protocols this is much less necessary.

<comment><USER19> "The Harmful Consequences of the Robustness Principle" is a good read: [https://tools.ietf.org/html/draft-iab-protocol- maintenance-0...](https://tools.ietf.org/html/draft-iab-protocol- maintenance-01)

</comment></comment><comment><USER20> I feel like Fonzie's Law would be a worthwhile inclusion: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."

<comment><USER21> I refuse to fall for that bait.

<comment><USER20> Remember that all is opinion. For what was said by the Cynic Monimus is manifest: and manifest too is the use of what was said, if a man receives what may be got out of it as far as it is true.

</comment></comment></comment><comment><USER22> Zawinski's law of software envelopment:

 _Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can._

<comment><USER23> The modern angle on this rule is that "Every program eventually adds text chat, and they're all incompatible with each other."

<comment><USER6> Isn't mail just another form of text chat?

<comment><USER24> Yes. That makes it the more general form of the original law.

<comment><USER23> The _incompatibility_ is the key feature that differentiates modern text chat from those inferior mail applications.

</comment></comment></comment></comment></comment><comment><USER25>
      Some people, when confronted with a problem,
      think "I know, I'll use regular expressions."
      Now they have two problems.

(Originally with "sed" instead of "regular expressions")

<comment><USER26>
        Some programmers, when confronted with a problem, think
        "I know, I'll solve it with threads!"
        have Now problems. two they

<comment><USER3> There are only two hard problems in distributed systems:

        2. Exactly-once delivery
        1. Guaranteed order of messages
        2. Exactly-once delivery

Source: [https://twitter.com/mathiasverraes/status/632260618599403520](https://twitter.com/mathiasverraes/status/632260618599403520)

<comment><USER27> I like.

> There are only two problems in computer science, naming things, cache > invalidation and off by one errors.

I've got to say modern languages with foreach() have been amazing (makes me feel old when I consider a 20 year old widely used language 'modern').

</comment></comment></comment></comment><comment><USER28> Don't forget Atwood's law:

"Any application that can be written in JavaScript, will eventually be written in JavaScript."

<comment><USER3> Or _Greenspun 's Tenth Rule of Programming_:

        Any sufficiently complicated C or Fortran program contains an ad-hoc,
        informally-specified, bug-ridden, slow implementation of half of CommonLisp.

<comment><USER29> I encountered a literal version of this the other day.

I've been looking at some disused AI systems, which were all written in Lisp back in the day.

In an attempt to remain relevant, at one point in the early 2000s someone tried porting one of them to Java. By first writing a Lisp interpreter in early 2000s Java. So the system had all the old dynamic Lisp programs as giant strings, embedded in a fugly static class hierarchy.

</comment></comment></comment><comment><USER30> This is a list of rather, generic catch phrases. I think the article isn't worth the time, surprised to find it at the top of HN.

<comment><USER31> Yes, this doesn't strike me as good quality content at all. But it's a large list which lets everyone pick something and chip in which drives engagement.

If this sort of content is the sort that this community increasingly selects for then it is perhaps time to look for fresh pastures. ( I don't however know if this indicative of HN's current community or just an 'accident' \- I'm sure there have always been examples of poor quality near the top at times).

<comment><USER30> I think not just this one, a few of the top ones are of similar vein at the moment. Seems a bit off-colour, as usually the quality of content was rather consistent.

</comment></comment></comment><comment><USER32> There is an entire poster of funny 'laws of computing' that was created in 1980 by Kenneth Grooms. It's pretty amazing how many of these are completely relevant 40 years later...

It's hard to find the original piece of art, but my uncle had this hanging in his office for a long time, and now it's hanging in mine.

I transcribed it in a gist so I had access to them for copy/paste.

[https://gist.github.com/sorahn/905f67acf00d6f2aa69e74a39de65...](https://gist.github.com/sorahn/905f67acf00d6f2aa69e74a39de65941)

(Those pictures were from an ebay auction before I got the actual piece)

<comment><USER33> > program complexity grows until it exceeds the capability of the programmer > to maintain it.

... then it grows even faster.

</comment></comment><comment><USER5> Postel's law, "be conservative in what you send, be liberal in what you accept"is definitely not "a uniter"!

[https://tools.ietf.org/html/draft-thomson-postel-was- wrong-0...](https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00)

<comment><USER34> Yes, especially when you consider Hyrum's law.

</comment></comment><comment><USER35> Quick and dirty is rarely quick and always dirty.

(Don't know if it has a name)

<comment><USER36> You can have quick-and-dirty for initial release, but it's rarely practical from a maintenance perspective.

A related rule: Design software for maintenance, not initial roll-out, because maintenance is where most of the cost will likely be.

An exception may be a start-up where being first to market is of utmost importance.

Other rules:

Don't repeat yourself: factor out redundancy. However, redundancy is usually better than the wrong abstraction, which often happens because the future is harder to predict than most realize.

And Yagni: You Ain't Gonna Need It: Don't add features you don't yet need. However, make the design with an eye on likely needs. For example, if there's an 80% probability of a need for Feature X, make your code "friendly" to X if it's not much change versus no preparation. Maybe there's a more succinct way to say this.

</comment></comment><comment><USER37> 1\. All software can be simplified. 2\. All software has bugs. Therefore, all software can ultimately be simplified down to a single line that doesn't work.

</comment><comment><USER38> Page author, if you read this: Fred Brooks last name has an s. (Brooks, not Brook.) It should be Brooks' law.

<comment><USER39> Wouldn't it be "Brooks's" rather than "Brooks'"?

From what I know, the "*s'" thing works mostly for plural nouns. For singular, it only applies to classical & religious names ending with "s" ("Jesus'", "Archimedes'" etc).

I am not an English native so I may be completely off. Feel free to rage :)

<comment><USER40> Brooks' ?

<comment><USER39> This is exactly what I am trying to establish to improve my bumpy English. My best guess is that the correct form is "Brooks's" because (1) "Brooks" is a singular noun ending with an "s" and (2) it is not a classic neither religious name. If you claim it should be "Brooks'" I am ok with this as long as you give me a sensible explanation.

<comment><USER41> There's not exactly a consensus these days on what is correct. Either is valid, but I generally prefer _Brooks' Law_ to _Brooks's Law_ since it looks more clean. Of course, Brook's Law is incorrect, as there is no "Brook"

Here's an example of the lack of consensus:

Either is acceptable: [https://data.grammarbook.com/blog/apostrophes/apostrophes- wi...](https://data.grammarbook.com/blog/apostrophes/apostrophes-with-names- ending-in-s-ch-or-z/) [https://owl.purdue.edu/owl/general_writing/punctuation/apost...](https://owl.purdue.edu/owl/general_writing/punctuation/apostrophe_introduction.html)

Chicago vs AP style: [https://apvschicago.com/2011/06/apostrophe-s-vs- apostrophe-f...](https://apvschicago.com/2011/06/apostrophe-s-vs-apostrophe- forming.html)

APA style suggests appending the extra 's': [https://blog.apastyle.org/apastyle/2013/06/forming- possessiv...](https://blog.apastyle.org/apastyle/2013/06/forming-possessives- with-singular-names.html)

<comment><USER39> So, the usual clusterf*k of opinions instead of a clear spec. People should be speaking SQL.

Thanks for the links. Plenty of educational value there!

<comment><USER33> > So, the usual clusterf*k of opinions instead of a clear spec. People should > be speaking SQL.

Because that would be an improvement, or not much of a change?

<comment><USER39> Sorry, forgot to set the Sarcasm New Roman font again!

<comment><USER33> Honestly, it's more amusing for the ambiguity :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> I like Wiggin's Law (found in [My Heroku Values]([https://gist.github.com/adamwiggins/5687294)](https://gist.github.com/adamwiggins/5687294\))): If it's hard, cut scope. I'm working on a compiler for my new language and sometimes I get caught up in the sheer amount of work involved in implementing a new language. I mean, I have to write a typechecker, a code generator, a runtime (including GC), a stdlib, etc. But instead of just getting overwhelmed, I'm trying to cut scope and just focus on getting a small part working. Even if the code is terrible, even if it's limited in functionality, I just need to get something working.

</comment><comment><USER43> I'm not sure who they should be named after, but I'd like to suggest two more:

> Redundancy is bad, but dependencies are worse.

[https://yosefk.com/blog/redundancy-vs-dependencies-which- is-...](https://yosefk.com/blog/redundancy-vs-dependencies-which-is- worse.html)

> Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live.

[https://stackoverflow.com/questions/876089/who-wrote-this- pr...](https://stackoverflow.com/questions/876089/who-wrote-this-programing- saying-always-code-as-if-the-guy-who-ends-up-maintai)

</comment><comment><USER35> ______ is like violence, if it's not solving your problem, you're not using enough of it.

(I first heard that for XML, and since have heard it for others. Was very funny for XML though. I also know its not really a law.)

<comment><USER44> Communication?

</comment></comment><comment><USER45> ReRe's Law of _Re_ petition and _Re_ dundancy [2] seems appropriate here:

      A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet,

      A programmer's job is to automate the repeated and the redundant. Thus,

      A programmer delivering to an estimated or predictable schedule is...

      Not doing their job (or is redundant).

[2] [https://news.ycombinator.com/item?id=12150889](https://news.ycombinator.com/item?id=12150889)

</comment><comment><USER46> Last week I was trying to remember a term for when a programmer designs a system so generic that it becomes a prototype of itself. For the life of me, I can't remember - anyone here on HN know?

<comment><USER31> That's the inner platform effect [https://en.wikipedia.org/wiki/Inner- platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

</comment></comment><comment><USER47> Postel's law is lately considered harmful, and Linus' law has been disproven a lot of times (eg goto fail, but also in the linux kernel).

</comment><comment><USER48> Biggest one that is missing from the list in my opinion is Vogels Law:

"Everything breaks, all the time" \- Dr. Werner Vogels CTO Amazon.com

<comment><USER3> Or, alternatively, Norton's law: "Everything is broken." [https://medium.com/message/everything-is- broken-81e5f33a24e1](https://medium.com/message/everything-is- broken-81e5f33a24e1)

</comment></comment><comment> Const-me Am I the only person here thinking that many of them are just anecdotes, or are deprecated?

> Given enough eyeballs, all bugs are shallow.

Just count of viewers doesn't help. The owners of these eyeballs need both motivation to look for these bugs, and expertise to find them.

> The power of computers per unit cost doubles every 24 month.

Slowed down years ago.

> Software gets slower faster than hardware gets faster.

It doesn't. If you'll benchmark new software on new PCs versus old software on old PCs processing same amount of data, you'll find out the new one is faster by orders of magnitude.

Input to screen latency might be 1-2 frames slower, because USB, GPU, HDMI, LCD indeed have more latency compared to COM ports, VGA, and CRT. But throughput is way better.

> Premature optimization is the root of all evil.

Was probably true while the power of computers doubled every 24 month. It doesn't any more.

</comment><comment><USER49> Joy's Law: most of the smartest people work for someone else.

<comment><USER50> If your company doesn't hire more than 50% of all developers in the world at random, then this is probably true.

</comment></comment><comment><USER51> I would say Postel's Law, "Be conservative in what you send, be liberal in what you accept," should be tempered a bit. Sometimes it makes sense to be a bit more liberal with what you send (to make sure that consumers can handle errors) and more strict with what you accept (to make sure that consumers aren't relying too much on undocumented behavior).

For example, if you have a service with near 100% uptime, any other service which relies on it may not be able to handle errors or unavailability. Introducing errors in a controlled way can help make the dependencies more reliable.

As another example, being liberal about what you accept can sometimes result in security flaws, since different systems might be interpreting a message differently. Rejecting malformed input can be a beautiful thing.

<comment><USER52> Postel's Law is about handling standard protocols.

If you control all the clients and servers using a protocol, it does not apply to you. You're better being as strict as possible.

<comment><USER51> I know what Postel's law is about, the argument stands. Postel said that in 1989 and our thinking about protocols has changed a bit since then. If you're implementing a standard protocol like HTTP or TLS, and you are liberal in what you accept, this can cause security problems or other unintended behavior. For example, consider a proxy or gateway that interprets a request differently from an authoritative server. Suppose a nonstandard request is handled differently by each component. Ideally, one of the responses is, "this request is malformed, reject it". If each component handles the same request differently but without rejecting the request, you are quite possibly in a world of hurt.

More concrete example: suppose that an incoming HTTP request contains CRLFLF. To the proxy, "liberal in what you accept" might mean that this is interpreted as CRLF CRLF, which is the end of the request header. To the authoritative server, perhaps the second LF is silently discarded and ignored. Voilà: instant cache poisoning attack.

</comment></comment></comment><comment><USER53> Murphy's Law:

[https://en.wikipedia.org/wiki/Murphy%27s_law](https://en.wikipedia.org/wiki/Murphy%27s_law)

and

Muphry's Law:

[https://en.wikipedia.org/wiki/Muphry%27s_law](https://en.wikipedia.org/wiki/Muphry%27s_law)

</comment><comment><USER54> I would add Greenspun's tenth rule (law)[1]:

 _Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp._

And Beneford's law of controversy [2], which I see around monorepo vs polyrepo, language choices, tabs vs spaces, etc:

 _Passion is inversely proportional to the amount of real information available._

[1] [https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) [2] [https://en.wikipedia.org/wiki/Gregory_Benford](https://en.wikipedia.org/wiki/Gregory_Benford)

</comment><comment><USER55> Finagle's law: "Anything that can go wrong, will- _at the worst possible moment_."

[https://en.wikipedia.org/wiki/Finagle%27s_law](https://en.wikipedia.org/wiki/Finagle%27s_law)

</comment><comment><USER56> Oh please, not the Knuth's "principle" again. Optimization is a skill, it's not evil. A skilled engineer can build sufficiently good systems without wasting much extra time on optimizations.

<comment><USER57> His full quote is a little less prone to abuse

> Programmers waste enormous amounts of time thinking about, or worrying > about, the speed of noncritical parts of their programs, and these attempts > at efficiency actually have a strong negative impact when debugging and > maintenance are considered. We should forget about small efficiencies, say > about 97% of the time: premature optimization is the root of all evil. Yet > we should not pass up our opportunities in that critical 3%.

Premature optimization isn't bad, premature micro optimization is bad. You should also be thinking about optimization that results in better architecture and architectural decisions that make it easier to optimize in the future.

<comment><USER58> Yeah, I get frustrated that few people actually post the full quote, because, with the context, it means something completely different to young ears.

The full quote makes me think: "You should identify the critical paths of your system early." The shortened quote makes me think: "Deal with performance later."

Pretty big difference in meaning.

<comment><USER59> Personally, I think it's more about balancing trade offs. You need to have some semblance of target performance needs. Bad architecture can be hard to overcome later.

Most decisions are small, but can lead to compounding effects. Personally, I think one should also avoid premature pessimissation as well. No one in their right mind would use bubble sort over quick sort, for instance (not saying quick sort is the best algorithm, but it's better than bubble sort). One pet peeve I have in C++ is when I see people initializing a std::string with a literal empty string instead of using the default constructor. The default constructor is usually a memset or initializing 3 pointers. Initializing with an empty literal involves a call to strlen, malloc and strcpy. I've yet to see a compiler optimize this. May not seem like a big deal, but considering one of the most frequently used data types is a string, it adds up a lot. Most of the applications I've worked on show std::string methods and constructors as hotspots when profiled (back office financial systems).

I agree one should avoid premature micro-optimization, but that you can also avoid premature pessimissation.

</comment></comment></comment></comment><comment><USER60> DevOps Borat is a wonderful, if hardly understandable, account of related 'rules' and aphorisms. Sadly, it is no longer updated: [https://twitter.com/devops_borat?lang=en](https://twitter.com/devops_borat?lang=en)

Some choice tweets:

Cloud is not ready for enterprise if is not integrate with single server running Active Directory.

Fact of useless: 90% of data is not exist 2 year ago. Fact of use: 90% of data is useless.

In devops we have best minds of generation are deal with flaky VPN client.

For increase revenue we are introduce paywall between dev team and ops team.

</comment><comment><USER61> Kind of unrelated to the article, but does the Moore's law joke about the cat constant make any sense? The `-C` constant should be on both sides of the equation (since the formula is future computation _relative to_ current computation), and thus cancel out. As it stands, the equation doesn't make sense when 'Number of years' is zero, and is inconsistent between calculating twice in 2-year intervals and calculating once with a 4-year interval (as an example).

</comment><comment><USER62> Wouldn't the following be an embrace of Conway's Law rather than a defense against it?

> It is much better, and more and more implemented as such, to deploy teams > around a bounded context. Architectures such as microservices structure > their teams around service boundaries rather than siloed technical > architecture partitions.

> So, structure teams to look like your target architecture, and it will be > easier to achieve it. That's how you defend against Conways's law.

</comment><comment><USER63> Interesting read, although at this point the "Given enough eyeballs, all bugs are shallow" should be regardes as afallacy, not a law, because:

\- noone reads open source code

\- those who read do not understand it

\- those who understand don't file bug reports.

\- those who file bug reports file them for their own issues coming from misunderstanding/misapplication of the software, not actual bugs.

</comment><comment><USER64> I expected to see Lehman's laws[0] in there too, but maybe they are not famous enough. Maybe they don't deserve to be, but I think they are relevant observations.

[0]: [http://wiki.c2.com/?LehmansLaws](http://wiki.c2.com/?LehmansLaws)

</comment><comment><USER65> * A organisation's requirements for data processing is a function of the organisations data processing capabilities and always greater

* All software has bugs, no software is inefficient

* A programmer's work is never done

</comment><comment><USER66> Moore's law is dead!

Also, I think Murphy's law should be removed, it's less true than the other laws here.

I read a fantastic article many years ago in the Atlantic where the author was analyzing and deconstructing an airplane crash, and in it was a paragraph about how Murphy's law is completely backwards, and in reality if things can go right, then they will. Things will almost always go right unless there's no possible way they can, in other words only the extremely rare alignment of multiple mistakes causes catastrophes. Can't remember if the author had a name for the alternative Murphy's law, but I believe it, especially in software. We get away with crappy software and bugs & mistakes all over the place.

<comment><USER67> I think people interpret Murphy's law incorrectly most of the time.

We can extrapolate from "Anything bad that can, happen will happen", and get the statement: "If something can physically happen, given enough time, it _will_ eventually happen."

I like to think its sort of a very tangential sister idea of the mediocrity theory.

<comment><USER66> I'm not sure I understand what you think is incorrect; your explanation seems to align with the common interpretation.

Here's the article I was thinking of. Totally worth the read, aside from discussion of Murphy's Law...

[https://www.theatlantic.com/magazine/archive/1998/03/the- les...](https://www.theatlantic.com/magazine/archive/1998/03/the-lessons-of- valujet-592/306534/)

"Keep in mind that it is also competitive, and that if one of its purposes is to make money, the other is to move the public through thin air cheaply and at high speed. Safety is never first, and it never will be, but for obvious reasons it is a necessary part of the venture. Risk is a part too, but on the everyday level of practical compromises and small decisions—the building blocks of this ambitious enterprise—the view of risk is usually obscured. The people involved do not consciously trade safety for money or convenience, but they inevitably make a lot of bad little choices. They get away with those choices because, as Perrow says, Murphy's Law is wrong—what can go wrong usually goes right. But then one day a few of the bad little choices come together, and circumstances take an airplane down. Who, then, is really to blame?"

Of course, regardless of which way you interpret Murphy's law, the law itself and this alternative are both hyperbolic exaggerations. The main question is more of which way of looking at it is more useful.

In terms of thinking about safety, it seems like both points of view have something important to say about why paying attention to unlikely events is critical.

<comment><USER67> I suppose what I generally mean is that most of the people that I've talked to only consider it within the scope of "what can go _wrong_ ", and seem to never consider the more general statement. I'm certainly not claiming to be the first person to think such a way, if that's the impression I gave off.

Murphy's law is a favorite of mine because it's the perfect driving board for conversations about infinite probabilities and aliens and simulation stuff.

<comment><USER66> I guess I still don't know exactly what the more general statement is you're referring to. Do you mean just that a non-zero probability of a single event happening equals 100% probability given a large enough sample of events (which may take a large amount of time)?

I feel like Murphy's law as stated captures that idea adequately. And it's certainly true if the event probability really is non-zero. Sometimes, though, we can calculate event probabilities that are apparently non-zero based on known information, but are zero in reality.

One example in my head is quantum tunneling. Maybe this is along the lines you're talking about? And this is the way my physics TA described it many years ago, but caveat I'm not a physicist and I suspect there are some problems with this analogy. He said you can calculate the probability of an atom spontaneously appearing on the other side of a solid wall, and you can calculate the same (less likely) probability of two atoms going together, therefore there is a non-zero probability that a human can teleport whole through the wall. The odds are too small to expect to ever see it, but on the other hand, with the amount of matter in the universe we should expect to see small scale examples somewhat often, and we don't. There may be unknown reasons that the probability of an event is zero.

<comment><USER67> It looks like we agree on all points, yes

</comment></comment></comment></comment></comment></comment><comment><USER68> does it work for you? The site only shows a beating gray circle.

<comment><USER69> As is often the case with these kinds of abuses of JavaScript, Firefox's Reader View solves the problem.

<comment><USER68> It seems to be a strange interaction between css and javascript. Using umatrix, I can read the text with both css and javascript disabled, but not with only javascript disabled. This is the first time I encounter this curious behavior.

</comment></comment></comment><comment><USER70> My law: convenience topples correctness. Evidence -programmers have been proven incapable of quoting Knuth's optimization principle correctly and in full

</comment><comment><USER71> Could someone explain the last one, Norvig's Law:

"Any technology that surpasses 50% penetration will never double again (in any number of months)."

<comment><USER72> Double 50% is 100%, so assuming your market doesn't significantly grow, it's impossible to double your market share again.

</comment></comment><comment><USER73> "Any programmer can be replaced with a finite number of interns" \- Janusz Filipiak, the biggest shareholder of Comarch, Poland.

</comment><comment><USER74> My personal law from working in software consulting is "triple the estimate."

</comment><comment><USER75> The Peter Principle is also referred to as Putt's Law ([https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Success...](https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)) and phrased slightly differently.

<comment><USER76> Putt's Law seems totally different.

* Putt's Law: "Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand."

* Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion." with incompetence being "flushed out of the lower levels" of a technocratic hierarchy, ensuring that technically competent people remain directly in charge of the actual technology while those without technical competence move into management.

In the Peter model, everyone gets (or tends to get) promoted until they reach a job they can't do, and they stay there. Thus everyone will (tend to) be incompetent. In Putt's model, the technically incompetent get promoted, and those at lower levels are competent.

Putt's does sound more like the way the world works...maybe. Peter's has always sounding convincing to me, yet the world evidently isn't so bad as that.

</comment></comment><comment><USER77> Missing: Goodhearts Law

</comment><comment><USER78> Is there a law about the probability that an article about programming will reference XKCD?

</comment><comment><USER79> A partner to the Peter Principle, particularly with respect to managers, is the Dunning-Kruger effect: "In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is."</comment>


Tenacious C: Cool C IDE - <AUTHOR> http://tenaciousc.com <comment><USER2> Good top post on the blog page, made me lol:

 _'I like C, but I have to admit that, sometimes, "The Old Man of Programming" can be a bit of a killjoy. This is one of the most exciting eras in computer history, but lately, C's acting like he doesn't even want to have a good time. While the cool kids like Ruby and Haskell are living it up, C's over in the corner obsessing over bits and bytes and memory alignment and pointers and the stack and machine architecture and unreachable allocations and multiple indirections…and it's…kind of a buzzkill. You want to tell him, "Dude! Lighten up! This is supposed to be fun!"

But of course C can't relax. He's holding the entire computing universe on his shoulders, after all. It's not turtles all the way down — it's turtles all the way down, _____then C__ __. _Not a lot of room for fun underneath that, is there?

Is there?

Well. Here's the secret: C does let loose sometimes. And after being bottled up for so long, when the release finally does come, it's pretty much an F5 of crazy.'_

<comment><USER3> The blog post is excellent. It led me to this:

<http://www.lysator.liu.se/c/duffs-device.html>

I've programmed in C a fair amount, but I am incapable of understanding the construct contained therein. Specifically, the interaction of the switch and the loop and all those fall-through cases. I would absolutely love it if some C-guru hn-er could describe it in layman's terms?

<comment><USER4> The other two comments are right, but the context you might be missing is _why_ you would unroll a loop. Due to cache behavior (and other low-level details), doing something eight times and then checking if it needs to be done _another eight times_ has less overhead than checking after each loop iteration. Why eight? It was probably a sweet spot in time vs. code size, at some point. (Processor caches are larger now.)

Duff's device just gets the (remainder of N/8) steps out of the way the first time through, then drops down to looping eight at a time. If it seems more complicated than that, you're probably overthinking it. It's "just" a creative abuse of C syntax, a bunch of offsets and gotos.

Sometimes low-level optimization like this makes a huge difference, but make sure it's a hotspot first, and that the compiler isn't _already_ doing those things for you. Measurements will keep you objective.

Also, if you're doing a lot with C, check out Lua!

<comment><USER3> Thanks. Lua is on "my list" actually, Fortunately I am only forced to work in C for one particular project (sorry if that sounds negative, C-heads, I'm just a messy enough person to require garbage collection to stop me from messing up too bad).

<comment><USER4> Lua is, IMHO, "Javascript done right". It's nice to have the option of writing C code but letting Lua do garbage-collection on common userdata.

Lua replaced Python for me - it's a great language on its own. TCO and pattern matching (<http://github.com/silentbicycle/tamale>) go a long way.

</comment></comment></comment></comment></comment><comment><USER5> I've been waiting for _something_ to implement at least _something_ DDD has done for years... and less fugly is nice. Any idea how it handles circular references?

<http://www.gnu.org/software/ddd/all.png>

<comment><USER6> What would be interesting is if someone made a web-based GUI wrapper around such apps. I am sure it would be possible, considering that curses-based wrappers have been around: <http://zemljanka.sourceforge.net/cursed/>.

<comment><USER7> > a web-based GUI wrapper

...why would you want to do that for a C debugger?

<comment><USER6> It's just that you write it once and it can run anywhere without "installing" many dependencies other than a browser. No fugly GUIs, no inconsistencies, etc.

By web-based I didn't mean it to be on the Internet.

<comment><USER4> So basically, "web-based" is the new portable GUI library.

<comment><USER8> Absolutely — you just open a high port on localhost and open the URL in a browser. I've used this technique before on consulting projects with great success.

<comment><USER9> That's not really web-based then, more HTML-based.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Just from the screenshots it looks like it might be a good tool for teaching students learning about pointers.

<comment><USER11> This is probably one of the best things that's happened for programming education in years! (In addition to a lot of other uses.)

</comment></comment><comment><USER12> What a joke. Things like this – and the rhetoric on his site – make systems programming look like more of a dark art than it actually is.

If you're a programmer, should know how your computer works; if pointers are too "hard" for you, you're in the wrong business. You're settling for mediocrity and belittling your own intelligence by assuming you're not capable of tackling this stuff the same way everyone else has.

<comment><USER13> I dunno, I have a lot respect for people who take difficult concepts and try to make them easier to grasp.

Teachers are more valuable than belittlers. "This isn't hard" is not a lesson plan or a path to enlightenment.

<comment><USER12> I also have a lot of respect for people who are willing to teach. But I don't respect teachers that speak of these concepts like they're magic that no mere mortal can understand. This is stuff that everyone can know -- and should know -- and needs to be treated like learning arithmetic, not tensor calculus.

</comment></comment></comment><comment><USER14> Neat, but I question the Windows only choice here. A lot of C programmers are developing on a *nix platform. But I see this as being more useful for students learning C and memory management. It's a neat project and might recommend it to students but I'll stick to vim, myself.

<comment><USER15> They seem to be targeting the embedded market, which is mostly Windows based.

</comment></comment><comment><USER16> Now I know what Walter Bright should have named his software development toolchain...

</comment><comment><USER17> Of course, if you learned assembly first instead of Java or somesuch, pointers make 100% intuitive sense, and if you didn't grok them completely you wouldn't have been able to write your first program.

</comment><comment><USER18> Is this a port of <http://en.wikipedia.org/wiki/Tenacious_D> ? ;-)

<comment><USER19> yes</comment></comment>


Net Neutrality: Toward a Stupid Internet - <AUTHOR> http://www.theobjectivestandard.com/issues/2008-winter/net-neutrality.asp <comment><USER2> There is one critical flaw with the reasoning of all these opponents of Net Neutrality. They claim the ISPs should have the right to regulate traffic to remain 'competitive', and that users who aren't happy with the regulation can simply choose another ISP. That's how the free market works.

Except this isn't really a free market. In most locations, consumers only have a single choice for broadband access (or two at most). Most ISPs have a regional monopoly. So if your local cable provider decides to charge you extra to access wikipedia, you're SOL.

You can't appeal to the 'free market' when there really isn't one. Your only choice is to create one, which is exactly what net neutrality aims to do.

<comment><USER3> Since the lack of broadband competition may be caused by government regulation, the author would prefer total deregulation rather than Net Neutrality or the status quo: "The key to competition in the Internet is less regulation, not the added regulation entailed by net neutrality. ... We must undo the relatively few controls already placed on the Internet..."

<comment><USER4> Except that it's not created by government regulation, tt just doesn't make economic sense. Broadband is very much a natural monopoly, like electricity or water. In a free market, the first few incumbents (usually the phone provider and the cable provider) who have already built out their infrastructure for old services (phone and cable TV) have a huge advantage over any other company, which would have to spend billions to lay their own wires. Thus market forces prevent any other company from entering the market.

Furthermore, it's not really clear that the socially desirable outcome is to promote competition at the line level. Because each producer has to spend billions on infrastructure to serve fewer people (because the more providers there are, the fewer customers for each), costs will be higher and profits lower the more companies enter the market.

The best solution is in fact government regulation. Instead of promoting competition at the line-level, governments should (and most OECD countries do, with the exception of Mexico, the Slovak Republic and...the US) require local- loop unbundling, whereby the incumbent telco is given a monopoly on laying lines to houses but is required to lease their lines to competitors at a set price.

For more information, read the Berkman Center's Broadband report, which was commissioned by the FCC and is presently the more thorough empirical look at these topics. It's available here: <http://cyber.law.harvard.edu/pubrelease/broadband/>.

<comment><USER5> _Broadband is very much a natural monopoly, like electricity or water._

ATT used to say that the phone network was "a natural monopoly". Today we'd laugh at that. Really, this example is so glaring that I'm surprised you'd offer this argument. And in fact you acknowledge that the local loop is separate from the actual network. But the difference in the US is that this _is_ a free market -- I can choose to use Embarq (the traditional copper-wire circuit-switched carrier), or I can (and do) use Vonage, or scads of other IP- based carriers, or I could do like many people do and just use cellular. We the consumers are getting to choose just how this unbundling happens.

If, for some reason, you think that there's something sacred about telephone, while data is different (or vice versa), there are other counterexamples as well.

In New York, while electrical _transmission_ remains a monopoly, _generation_ has many choices. It works just like the phones: where the infrastructure demands a single source, that's what we get, but that doesn't mean that the people that provide the wires can be the only one involved in the business. (I pay more for electricity that's generated in part by windmills)

And most obviously, it seems to me that most people have access to two broadband carriers, albeit their capacity varies widely (but that's what markets are all about, right?). Virtually everyone I know has a choice of a DSL provider or a Cable provider.

<comment><USER4> You're missing the point, but not for the reason given below. The pipe is the natural monopoly, not the services provided over it. This is so obvious that it hardly bears repeating, but again: it makes no more economic sense for multiple companies to run fiber to each house than it does for multiple companies to run electric wires to each house.

Sure you can use Vonage for phone instead of AT&T (or whatever), but you can only do that because you have a pipe to the internet. VoIP services are means of getting phone over a different pipe, but you still need a pipe.

You also seem to miss the point of my comment: governments should have policies like mandatory local-loop unbundling (also called line-sharing) which produce competition where it makes sense (providing backbone) instead of where it makes little sense (providing the "last-mile" connection).

Finally, a duopoly is better than a monopoly, but not by much. It still gives the players far too much control of the market.

</comment></comment></comment></comment></comment><comment><USER6> Just because someone owns property does not mean that they have unending rights to do with that property what they wish. Go buy a piece of land in the middle of the city, build a giant bonfire, and see what happens. Due to state "regulation," your landlord can't just barge in on his/her property whenever he/she wishes. Laws like this have existed to protect the weak or meek for ages.

In a sense, "property" does not exist. Property only exists because laws exist to protect it. If the country you live in is invaded by a more powerful nation, how much do you think your "property" matters at that time? It's just a set of limited rights granted to you by the government, not unlimited license to do whatever you wish.

<comment><USER7> What you are suggesting depends entirely on the source of rights. If rights are granted by men and can be removed then you're right. If your rights are inherent or granted by God then you are incorrect.

If my rights are granted by God (and included in those rights is the right to private ownership) then if someone invades my land they are violating God's law.

Private property is the basic requirement of wealth. It is defined by law to codify what existed for the protection and benefit of everyone. I'm basically quoting Aristotle here.

<comment><USER8> If God has laws to protect our rights, then He really should be way more vigilant about enforcing them.

Rights aren't granted by men, they're asserted by men. We have the right to free speech because we assert that we have the right to free speech, and the collective will of those who wish to assert the right to free speech is (currently, in this country, for the most part) greater than the will of those who wish to restrict it. This is why it's so important that we all agree on what rights we do have, and that we all spend a lot of time vigourously asserting them.

<comment><USER6> ^^^ This is mostly exactly what I'm getting at, but said in a much more eloquent way. Thank you.

</comment></comment></comment></comment><comment><USER3> TLDR: This is exactly what you'd expect ultracapitalist Objectivists to say: ISPs should be allowed to do whatever they want because their networks are private property.

<comment><USER9> ISPs networks are not (totally) private property though. They are in many cases publicly subsidized, and they operate with a state-backed grant of monopoly or oligopoly within each region.

IMHO, regardless of what you think of Objectivism or libertarianism, the standard libertarian critique of government interference does not apply to net neutrality. It would apply if telecom were actually a free market and if telcos did not receive large amounts of state support.

Conservatives and most libertarians usually fail the see the distinction between actual private businesses that operate in a free market (e.g. Google, Apple, etc.) and state-backed quasi-private enterprises like telcos. The latter are aptly called "Soviet bureaus."

<comment><USER10> I don't think they fail to see the distinction, but instead of further cementing government control they in fact argue that telcos should lose their government privileges and be left to compete in the market. Sure at first they will have significant advantages but as time goes on competition should be able to function.

<comment><USER11> Yeah, because if I have a problem with my ISP, I'll just head to the bank, borrow a few hundred billion and build my own backbone.

<comment><USER12> This is sort of funny, but despite receiving many more upvotes than its parent, it displays a startling lack of understanding of the capitalist system.

More likely than you borrowing a few "hundred billion," large, midsize, and even small corporations would invest a "few million" in a city or neighborhood somewhere and use the profits to continue investing in other profitable areas. They might even collaborate and start connecting entire cities together (oh look, a backbone). I find this a much more desirable outcome than a government-run or (the current) psuedo-government run scenario.

<comment><USER11> Well, ok Mr. Capitalist, why hasn't that happened yet? It's certainly not because the existing cable companies' sterling customer service leaves no room for improvement.

<comment><USER10> It hasn't happened because most communities grant a monopoly to their cable provider so their can only be one legal cable company in a given area.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The problem with a lack of net neutrality is not how ISPs relate to their paying customers, it's how they relate to content providers. That's not to say that I agree with the arguments in the article; I find them extremely distasteful, although there is some reasoning behind them, based on ideas of morality that I disagree with but don't find completely invalid.

I'll outline the scenario that worries me. Comcast sends all internet data as second-tier data, unless the content provider pays Comcast to provide it as first-tier data. The difference between the two is small, say one or two tenths of a second in delivery time. The end user doesn't notice a difference. But, as Google has found, the extra tenth of a second has huge impacts on conversion for websites. So, Comcast effectively offers the same experience to users, but now also holds a huge sword over the head of content provides. Effectively, it is in an excellent position to leverage its ISP monopoly to create a massive extortion racket to content providers. And the magical free market isn't going to push back against Comcast, because the experience for the end-user has not noticeably suffered.

It's quite possible that under such a system the internet could actually be free, because it's subsidized by corporate content provider partners, and charging the content consumers becomes obsolete, although I doubt Comcast would suddenly drop a revenue source. However, it also raises the barrier to entry for small content providers, because they don't have the spare cash to pay Comcast for non-sub-standard conversion rates. In a (weasel) word, it's less democratic. Not to mention, Comcast can sustain its monopoly on ISPs by giving even shittier third-tier access to its competitors. The end result is a less-free internet, Comcast enriching themselves by abusing a monopoly, and all of this done without Comcast delivering a higher-quality internet to users. I think I'll take my stupid pipes, please.

I agree with the author insofar as I accept that his conclusion is consistent with Objectivism, although it's still debatable if owning the wires means owning the data that goes through the wires. Fortunately for me, I'm a pragmatist, not an Objectivist, and I think the loss of property rights (if any!) is perfectly acceptable for the benefits to expression and communication.

<comment><USER12> > Effectively, it is in an excellent position to leverage its ISP monopoly to > create a massive extortion racket to content providers. And the magical free > market isn't going to push back against Comcast, because the experience for > the end-user has not noticeably suffered.

So in the end, being an internet provider is massively profitable, and maybe another company decides to jump into the space to take a share of the highly profitable market. Maybe two companies, maybe three. Suddenly there are choices, these companies are competing on price, service, bandwidth, etc. for customers and everyone wins, all at the price of Mom's free blog being served 1/10th of a second slower in the interim.

Sounds good to me.

</comment></comment><comment><USER14> > _Were it not for net neutrality, a start-up ISP might compete against > Comcast by configuring its fledgling network to favor Bit Torrent's peer-to- > peer data packets, thereby earning it the business of serious movie > downloaders without having to match or exceed Comcast in expensive > infrastructure._

Really? If someone advertised their ISP as 'BitTorrent-friendly' they would have to contend with the MPAA, RIAA, BSA, etc trying to sue their company back into the stone-age.

> _If an ISP were left alone to manage the transmission of data packets across > its property, it could profitably improve the speed of its network, it could > profit from charging more for more bandwidth consumption, and it could > profit from providing special services to certain customers, such as > smoothly streaming high-definition video feeds. But because none of these > things is possible under net neutrality's rules, the property of Internet > service providers is worth considerably less to them in terms of its profit > potential. Accordingly, their incentive to expand and improve the > infrastructure on which the Internet relies is greatly diminished._

The government poured billions into the country's major ISPs to 'upgrade infrastructure' and there was little to no return on that investment. Infrastructure was _not_ upgraded and we are now at a point where ISPs are trying to claim that their networks can no longer handle capacity, so they are _forced_ to do filtering and 'QoS.' Where did all of that money go? Shouldn't the free market have allowed the ISPs to use that money to improve their networks so that they could reap larger rewards from those better built networks?

The problem with trying to treat Internet Service Providers as some sort of 'free market' is that it isn't. There are _huge_ barriers to entry in the market, and well-established incumbents. Most places in the USA only have 1 or 2 choices for internet service. How is this in any way a 'free market' that the government should say out of? In fact, the governments created this mess in the first place by creating phone company and cable company monopolies. Now these telcos preach about how 'the market should be free' just because they have a huge advantage (i.e. established customers and deep-pockets) against any possible competitors. Which is a hypocritical stance seeing as they are where they are today due to government-granted monopolies.

tl;dr The ISP business model:

      1. Get the government to give you a lead in the market through a monopoly
      2. Grow your business by leaps and bounds during this monopoly period
      3. Government opens market
      4. Complain that government intervention in the market is evil and lobby
         against the government helping out any potential competitors

<comment><USER10> So it seems your problem is with the initial government intervention? So in order to fix that we need more?

<comment><USER14> I'm not really offering solutions. I'm pointing out the lack of a decent evaluation of how we got here and how we can fix it. Almost all net neutrality discussions are people that want to prevent large ISPs from enacting draconian restrictions on their networks vs the people that don't want any government regulation of anything. There doesn't seem to be much constructive discussion. Just people taking traditional 'liberal-vs-conservative' positions and digging in to duke it out on the canned talking points that traditionally follow.

The people that say "networks are private property and I don't want no government in my private property" are forgetting that most of those networks were built during periods of guaranteed profits (AT&T) or just regional monopolies (cable companies). It's not like these companies were little mom-n- pop shops that were built from nothing with no help from anyone, and now the 'big bad government' is coming in to kill them off by helping their competitors. These companies where weened off the government's teat.

The people that want to bring in the government to restrict the internet are forgetting that there is a whole can of worms that will be opened if the government starts getting their hands into the internet. Sure it could be just 'net neutrality' regulation now, but what you picture as what 'net neutrality' should be will _not_ be what it looks like once an actual bill gets passed. Not to mention all the attempts to tack on 'child porn' filtering and crap (possibly creating some 'Internet Filter Czar' position in the Executive Branch).

Even solutions like: "the internet should be like the highways; built and run with tax-payer money." So the government now runs the major backbones of the internet in the US. This means:

      1. Companies can easily become ISPs by hooking into
         the backbone at reasonable rates
      2. Congress will be salivating to pass bills to put filters
         on these backbones to 'protect the children.'
      3. The networks will be less secure as routers, servers,
         etc are administered by incompetent administrators that
         only have their positions because they know how to play
         the government bureaucracy politicking games better than
         more technically skilled colleagues.

The average consumer is stuck between a rock (the government) and a hard place (large corporations with vested interests). Neither solution is particularly palatable, and it's naive to say that one solution or the other will save us from all the evil in the world.

<comment><USER12> I'll take large corporations with vested interests over the government. At least those interests are maintaining a profit and answering to the market. I can pick between a few different COMPETING mega-corps (if they are a monopoly, break them up via anti-trust). With the government I will have no choices and I can see them chomping at the bit to take away liberty "for the children."

<comment><USER14> The thing is that you're buying into the false dichotomy of the Net Neutrality debate. It's not an all-or-nothing prospect. Rather than framing the question in terms of, "who should control our internet," we should be asking, "how can we fix the current situation." In your post, you make an excellent suggestion, anti-trust. The only issue with that, is that we've proven in recent years that the power of the corporation extends well into the government, and most anti-trust attempts end up as not much more than slaps on the wrist.

</comment></comment></comment></comment></comment><comment><USER15> Government control of private property - this is how some public utilities operate. Private industry builds the infrastructure, but the government aims to bring stability through regulation to what a large part of the general population sees as an essential service.

This article makes the analogy to the printing press; that the Internet is changing our worldwide society dramatically. Those who are for net neutrality (myself included) would likely agree - that this transformation is a positive thing and should move towards becoming an essential service.

How this is accomplished - either through private industry or government ownership - is really just a matter of culture. Many countries have significant government ownership of network infrastructure.

<comment><USER16> Many countries gradually cannibalize themselves in the name of the "public good" as well.

USA has been the only experiment in capitalism so far (and a raving success until the income tax was instituted)... why re-model on failed socialist principles?

</comment></comment><comment><USER17> I wonder if there's a simile to make with electric utilities.

A "smart grid" could potentially distinguish between surcharge-able electrons, just as a "smart internet" (one without net neurtrality) could distinguish between good and bad packets. Would you want an electric utility to be able to charge you more because you bought the wrong brand of refrigerator? Or were charging an imported electric car?

Of course utilities will charge more for peak hour usage right now, but at least every electron is charged the same at that time.

What do you think?

</comment><comment><USER18> Bittorrent invented P2P... Stopped reading when I hit that.

\--edit-- Read it again and he says "developed p2p" which could be construed as further developed I suppose. Benefit of the doubt.</comment>


Startup Quote: Matt Mullenweg, founder, Automattic - <AUTHOR> http://startupquote.com/post/6366256796

<comment><AUTHOR> Do what you love and don't focus on money - life's too short.

\- Matt Mullenweg (@photomatt)

<http://startupquote.com/post/6366256796></comment>


Learn How to make a Single Element Macbook Pro in CSS3 - <AUTHOR> http://cssdeck.com/labs/codecast-single-element-pure-css-macbook-pro

<comment><USER2> Part of me would be more impressed if somebody did this in MS Paint, instead.

<comment><USER3> +1

</comment></comment><comment><USER4> I'm pretty sure that's wizardry, not css.

<comment><USER5> Haha, it's pure css, come on and see what is the power of css/css3 !

</comment></comment><comment><USER6> MFin CSS3.

</comment><comment><USER7> repost!</comment>


[mfetch] Make your fetch api become more powerful - <AUTHOR> https://github.com/janryWang/mfetch <comment><AUTHOR> mfetch will provide you with a strong ability to request resource management, at the same time, you can use it very simply</comment>