Genetics plays a part. Diabetes in Asians is a different disease; the excess fat in Asian men is stored in the muscles rather than around the belly. 150 generations of eating rice will change things. By comparison, food like potato (now a stable) have only been around in northern Europe for 6-8 generations.
I have seen many projects fail in big companies because management are frightened of programming. The "risk mitigation" is using large teams of people with the right "skillset" who don't need to think very much because they are doing things according to the "industry best practice" using expensive third party software so that the in-house programmers don't have to make hard decisions.
If you work in an environment like that, and you're reading this, you are probably part of the problem because you are keeping the stupidity alive by struggling through the process and letting management get something delivered. Best to step away from the stupidity and let it fail.
> Single founder can get feedback from other sources too: customers, friends, etc.
> On the plus side that feedback can be less biased.
But the cycle time is so slow. Feedback with a co-founder happens very quickly, and both parties are deeply involved and working on the venture. This gives a level of detail and understanding that you can't really get from customers and friends. That is not to say that customers and friends should not provide feedback; they should. However, it is different.
This was the point of my last sentence: "While you can get some feedback, the nature of the conversations changes (at least for me), and there are some things you don't really talk about to others." This refers to the kind of feedback you are talking about, and while it has value, it is not the same thing.
>> When you are on your own it is much easier to go down the
>> wrong path because questions didn't get asked earlier on.
> It has little to do with a number of founders. Two or more can be asking questions, but those can be wrong questions.
You still have two people asking questions. And with a fast feedback loop you can get interesting questions quickly that actually make a difference.
I am not arguing that it is impossible for a single founder company to work, I am arguing that having two skilled and "compatible" founders gives a advantage over one.
>> It is much easier to become demoralised. It is much easier
>> to waste time.
> Why? I'd argue that more than single founder have even greater opportunity to
> waste time arguing if there is some disagreement; waste time trying things thad
> you don't think will work but your cofounder convinced you to try, etc.
Not my experience, yours might be different.
When I've had disagreements, the outcome has usually been that everyone has a clearer view and goes in the same direction (or call the whole thing off). Those disagreements are opportunities to get a better outcome for everyone.
There are multiple variables. If your co-founder spends all his time convincing you to do stupid things and you agree with him, then you have other issues.
Co-founders can create a feedback loop between themselves that a single founder cannot.
Comparing my "single founder" and "one of two" experiences, when there is another party the ability to talk and get feedback makes a huge difference. When you are on your own it is much easier to go down the wrong path because questions didn't get asked earlier on. It is much easier to become demoralised. It is much easier to waste time.
Having someone else around doesn't work as well as having a co-founder. While you can get some feedback, the nature of the conversations changes (at least for me), and there are some things you don't really talk about to others.
> Imagine if Microsoft had vetted every DOS and Windows app
We associate the BSOD with Microsoft software. However, in the majority of cases, the bug is in someone else's code or is a hardware problem. These days it drivers, but in early Windows (pre-NT), applications could cause the system to die.
I suspect that Apple are vetting to avoid bad apps from tainting the perception of the platform. The platform is what they care about, "like Google cares about search".
If an app is buggy and fixes or new features don't turn up the end-user blames the app vendor. If the device crashes, the end-user blames the platform vendor. Those things can stick; witness how the BSOD has influenced perception of the Microsoft platform.
Avoiding that is a reasonable thing for Apple to want to do. However, I agree that the way they are doing it is probably counterproductive.
I have a D630 and I agree; it is a laptop and does all the right laptop things. However: I got my wife a Dell E4300 and had many problems. Other colleagues have got other E series Dells have have had basic problems like not being able to suspend/resume under Windows and being forced to run a single core to get basic reliable operation.
I agree, and it's not just the MacBook Pros, it's also the keyboard that comes with the non-laptop Macs. My new Mac Pro came with a keyboard that was comparable with the keyboard on the Tandy Color Computer I had in the early 80s.
On the Mac Pro it is easy to change the keyboard; I replaced it with a Unicomp keyboard. However, that's not so simple on a laptop, and the keyboard is a big thing stopping me from getting an Apple laptop.
Transaction Processing: Concepts and Techniques (Jim Gray & Andreas Reuter) isn't just one of the best database textbooks, it is one of the best computer science textbooks. It is an Important Work.
On the other books, it depends on what you want. Alternatives to Date include Jeffrey Ullman, "Principles of Database and knowledge-base Systems" and "Foundations of Databases" by Abiteboul, Hull and Vianu.
As an introductory book, I like Database: Principles, Programming, Performance by Patrick O'Neil.
For more on transaction processing, as well as Jim Gray there is Philip Bernstein, eg "Principles of Transaction Processing".
Following the references is a lot of fun; see where you end up.
Yes, there will be many more cores, but I suspect that the cluster programming model will start applying to smaller and smaller systems.
I can imagine a system where each CPU die has multiple cores with on a chip with memory, and multi-CPU machines appear to software as a cluster rather than a single system image.
The difference between letting an exception bubble up and seeing a system call fail and aborting is pretty small. Either way, you need a higher level way of dealing with it.
One of the most interesting papers I read was "Why computers fail and what we can do about it" by Jim Gray while he was at Tandem. Transactions are essential, and most failures are transient. This can be applied at many levels, and can deal with many failures without the developer of the mainline code having to decide what to do for each given failure.
In some cases old, actively maintained code is more reliable. However, I have seen many cases where old, actively maintained code (depending highly on the quality of the maintainers) has lost reliability because the original principles of the codebase have been lost.
Device drivers (especially in multiprocessor systems) have very many unpredictable paths. In my experiences in writing devices drivers and GUI code code (as well as lots of code in the middle), device drivers are more likely to have the unforeseen codepath. With GUI code, you can constrain concurrency so that possible codepaths are also reduced.
Yes, this is true: A lot of embedded code is poorly tested. Even more is poorly designed and written by poor programmers (like most software.)
Some people have to deal with the machine, and C is a good model of the machine. Even reliable systems have some core in C (or an equivalent) that provides an abstraction where higher level abstractions can be expressed.
Testing isn't the ultimate solution; some people are just able to use the machine better and produce better code. Testing crappy code doesn't really help. A subset of developers produce tools where others can produce systems with less risk by providing appropriate abstractions.
> I use this on my mail server and with 200 users
> I've yet to ever get a false positive.
How do you know? I don't see how you would measure that; if you can figure out it is a false positive, you have discovered a better filter. You might get user complaints, but the absence of user complaints doesn't prove you have no false positives. (Although the presence of user complains could prove that you do.)
Also: The assertion that everything to do with viagra is spam makes it very difficult to have a discussion about viagra or spam. For example, this posting would be rejected.
For example: http://itc.conversationsnetwork.org/shows/detail4528.html