Forgot your password?

Comment: Re:Mass transit (Score 1) 389

by bmajik (#46817763) Attached to: Will the Nissan Leaf Take On the Tesla Model S At Half the Price?

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.

Comment: Re:de Raadt (Score 1) 304

by bmajik (#46761037) Attached to: OpenBSD Team Cleaning Up OpenSSL

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?)

Comment: Re:de Raadt (Score 1) 304

by bmajik (#46760367) Attached to: OpenBSD Team Cleaning Up OpenSSL

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?

Comment: Re:de Raadt (Score 5, Insightful) 304

by bmajik (#46759527) Attached to: OpenBSD Team Cleaning Up OpenSSL

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.

Comment: Re:Microsoft does not want kids coding... (Score 1) 226

by bmajik (#46686665) Attached to: Should Microsoft Give Kids Programmable Versions of Office?

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?


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.

Comment: Re:Microsoft does not want kids coding... (Score 1) 226

by bmajik (#46684479) Attached to: Should Microsoft Give Kids Programmable Versions of Office?

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 (

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.

Comment: Spacedocking? (Score 1) 392

by bmajik (#46664213) Attached to: How Many People Does It Take To Colonize Another Star System?

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


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

Comment: Re:60 minutes is not longer of value (Score 1) 544

by bmajik (#46651345) Attached to: 60 Minutes Dubbed Engines Noise Over Tesla Model S

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.

Comment: Re:Don't do it. period. (Score 0) 119

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.

Comment: Re:Very amusing but... (Score 2) 314

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.

Comment: Re:Not easy? (Score 1) 323

by bmajik (#46553557) Attached to: More On the Disposable Tech Worker

Of course.

I would say it is more of an exceptional case, but I've worked with folks who have non-technical degrees (Philosophy) and those who have no degree at all.

I think most of our listings say they require a 4 year degree in CS or a related field. So, that's a pretty harsh filter.

If you're the kind of person that doesn't match resume filters, your best bet is to know somebody already in the company, and get referred by them.

It's probably easier than ever to get noticed in the software industry though. There is a whole world o open source projects out there for you to contribute to, and all of that work is, by definition, public knowledge.

When I see someone has listed work they've done on OSS projects on their resume, that tells me way more than whatever they write about education or school projects.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]