I use smartphones with prepaid sims and no data plans. I'm usually at home or at the office where there is ample wifi. Smartphones are quite usable without "persistent" internet connections.

Not everyone has or wants a smartphone with a network connection. Of course, even feature phones get their time from the cell network, which is reasonably accurate.

That said, I started wearing a watch again a few years ago when I became a father to twins. I found that I was often getting up in the middle of the night, running a bottle warmer, etc. I found that it was critical to have something with a countdown timer and basic alarm functionality that was physically attached to my body. Also, I needed to be able to see what time it was when I was laying in bed, so a good lighting source was critical.

A smartphone doesn't meet these requirements. A basic Casio digital watch does.

I wore the casio until the battery started to wear out. I took it to a watch repair place and they ruined it. In the interim, I purchased a $10 timex analog watch with an extremely thin case, because the casio (it was a g-shock mudman -- I recall being hard on watches when I was a kid) doesn't fit under the cuff of a dress shirt.

Right now I'm wearing a newer casio digital watch -- one that uses solar charging and reads the radio atomic time signal from Colorado. I hope to never have to open the case to replace the battery, and I don't ever think about setting it. It is cheaper than my phone, more durable, and it is always attached to my arm when I need it.

I think there is a market for a smart watch. I'm sitting at my desk right now with my phone in my pants pocket. It buzzes every now and then with meeting reminders. Which I don't look at.

If my wrist watch buzzed because it knew about my calendar appointments, that's something I would use and appreciate. But, I wouldn't wear such a watch unless it was durable and inexpensive.

once they HAVE a car, they will use it because it is simply faster and more convenient than mass transit can ever be.

It's interesting that you believe that mass transit necessarily is slower and less convenient for people, yet still want it any way.

Why do you hate people?

I understand that time is the one asset that is truly finite for all of us, and indeed, we never know how much of it we have left.

Who will say, on their deathbed, "I'm glad I spent an hour a day riding a bus" ?

Busses are a poor form of mass transit because they usually take the same roads that private cars do. A bus will never be faster than a private car unless you factor in the car's time to find a parking spot, and the city in question is terribly congested.

Subways, or any other transit system that is disjoint from the road system, can be MUCH faster than a private car. And I've chosen to use them even when I had a private car available to me.

People will and should use mass transit when it makes their life better -- when it saves them time and lets them do more fulfilling things with their life.

In places like Munich, Germany, it is possible to get most places in the city via very fast u-bahn lines. We lived there for about 2 weeks and didn't have a car. When we did have to go somewhere that u-bahn didn't reach, dealing with the bus system was jarringly bad in comparison. Suddenly we had to become aware of times, schedules, etc.

The Ubahn system is great because it's difficult to get on the wrong train, and you don't need to memorize a schedule... the next train will always be coming in a few moments.

When we toured Germany outside of Munich later on, we had a hired car, but we did not take it into urban core areas (like Berlin). We would park at a free park and-ride on the outside of town -- which were ajoined to s-bahn lines. Then we would take the s-bahn line to the hauptbanhof (centrail rail station) at the city core, and from there we'd take ubahn lines as appropriate to our various destinations.

For areas with high urban density, disjoint mass transit (like subways) is a great option, and having a personal car in the city core is usually a liability because parking it is so frustrating, and ultimately, expensive in terms of dollars and human time.

I love driving and have many days of race track time to my credit. I also built my own RV out of an old school bus and we take long family trips in it. In my family, we like driving and private cars.

However, when there is advantageous public transit available to me, I use it.

It is possible to build transit systems that work with the reality of how people live instead of some central planners idea of how she wishes people lived. Good systems can and will prosper.

Systems that don't improve the lives of their users should simply disappear so that better choices can come about.

Ok, I actually think you, me, and Theo all agree :)

1) We don't think a specific technical change would have _prevented_ the issue.

2) We all agree that better software engineering practices would have found this bug sooner. Maybe even prevented it from ever getting checked in (e.g. suppose the codebase was using malloc primitives that that static analysis tools could "see across", and that the code was analysis clean. Could this bug have existed?)

Who has claimed that using the system allocator, all else being equal, would have prevented heartbleed?

Who has claimed that heartbleed was an allocation bug?

I understand what freelists are and do.

The point here is that rigorous software engineering practices -- including the use of evil allocators or static analyzers that could actually understand they were looking at heap routines -- would have pointed out that the code implicated in heartbleed was unreliable and incorrect.

If you read the link you pointed at, after making a modification to OpenSSL such that coverity could understand that the custom allocator was really just doing memory allocation, Coverity reported 173 additional "use after free" bugs.

There are bugs from years ago showing that openSSL fails with a system allocator.

Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?

Actually, it is you who are wrong.

Theo's point from the beginning is that a custom allocator was used here, which removed any beneficial effects of both good platform allocators AND "evil" allocator tools.

His response was a specific circumstance of the poor software engineering practices behind openSSL.

Furthermore, at some point, openSSL became behaviorally dependant on its own allocator -- that is, when you tried to use a system allocator, it broke -- because it wasn't handing you back unmodified memory contents you had just freed.

This dependency was known and documented. And not fixed.

IMO, using a custom allocator is a bit like doing your own crypto. "Normal people" shouldn't do it.

If you look at what open SSL is

1) crypto software
2) that is on by default
3) that listens to the public internet
4) that accepts data under the control of attackers ... you should already be squarely in the land of "doing every possible software engineering best practice possible". This is software that needs to be written differently than "normal" software; held to a higher standard, and correct for correctness sake.

I would say that, "taking a hard dependence on my own custom allocator" and not investigating _why_ the platform allocator can no longer be used to give correct behavior is a _worst practice_. And its especially damning given how critical and predisposed to exploitability something like openSSL is.

Yet that is what the openSSL team did. And they knew it. And they didn't care. And it caught up with them.

The point of Theo's remarks is not to say "using a system allocator would have prevented bad code from being exploitable". The point is "having an engineering culture that ran tests using a system allocator and a debugging allocator would have prevented this bad code from staying around as long as it did"

Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.

Not liking someone isn't a good enough reason to put them in jail.

Usually. For now.

Suppose it has a security vuln?
Suppose it depends on a certain version of a legacy DLL we need to service for other callers?
Suppose it was never localized beyond English?
Suppose admins want to enable/disable it via group policy?

(etc)

For better or for worse, it is incredibly expensive to put something in the Windows Box.

We give away VS for free, in a variety of different versions/avenues. By not putting it in the windows box, we avoid a huge # of headaches.

Your conclusion is entirely wrong.

Because Microsoft doesn't do the things YOU think Microsoft should do, you can ascertain the motivations and goals of Microsoft?

How interesting. Suppose we hire you to lead our CS education strategy. Can you promise results? Are you willing to bet your career on your prophecies coming true?

Let me tell you what IS true.

Microsoft lets me -- and many other MS employees -- volunteer to teach CS in public K-12 schools, 1 hour a day, before heading into the office for our "real jobs".

MS spends money to make this happen (volunteer matching hours), and gets less of my productive time (without docking my pay). There are full-time employees dedicated to this project. They have no other MS business function.

The program I am referring to is called TEALS (www.tealsk12.org)

It is just one of the ways that MS puts time, money, and people, into trying to build a better pipeline of students who can do CS.

I don't think stuffing GWBASIC back into windows is going to take us from where we are to where we need to be.

Relevant:

http://everythingfunny.org/wp-...

Luckily, tens of thousands of pioneers wouldn't have to be housed all in one starship. Spreading people out among multiple ships also spreads out the risk. Modular ships could dock together for trade and social gatherings

Hrmm.

http://www.urbandictionary.com...

I don't think this will contribute to genetic diversity....

60 minutes has had credibility problems for a long time.

They _destroyed_ Audi in the 1980s. They fabricated the "tests" and the results. They modified the cars and rigged them to fail in the way 60 minutes wanted them to.

Nothing 60 minutes says about cars should be considered accurate.

If there was any justice in the world, the show and the people behind it would have been in prison 30 years ago.

Funny you mention that.

Early in my Microsoft career, I built a system that provisioned thousands of windows machines on an as needed basis, differing by SKU level, language type, windows version, etc.

I'm was proficient in scripting the installs of windows machines -- even back when windows didn't natively support that sort of thing very well(e.g. NT4)

To be honest, Windows looks pretty good compared to any Linux distro I've worked with when it comes to automated provisioning and post configuration. That's a subjective comparison, of course, so I'll just say: I don't think windows was your problem.

It sounds like your management wasn't especially visionary nor technical, and that you failed to make an adequate business case to them regarding how much productivity the team would gain in the long run if you worked to automate these repetitive tasks.

That's a shame. I'm glad you moved on to greener pastures.

Why didn't you script all of the activities you just described?

2 is an exponent :)

I apologize for misspeaking. I remembered that drag increased with velocity according to some power, but didn't remember which one. Thus, my sloppy language.

Most German cars (which is who Tesla competes with) have undercarriage engineering for reasons of sound and high-speed aero concerns. They are expected to sustain 200kmh, and the relevance of drag rises exponentially with speed, but also, controlling airflow is important so that the car doesn't have too much high speed lift. What you do NOT want is a vehicle that loses significant grip as speed rises, yet most cars are shaped like (poor) airfoils so this is a concern.

You may recall that the first gen Audi TT did not have a rear deck spoiler, but real world driving showed that there were many high speed loss-of-control accidents with the vehicle, so a rear spoiler was fitted later.