dsuth's comments

Honestly updates seems to be a more or less solved problem in Win10, for general use at least.

> We can have magsafe back too. :)

Yes please. Honestly the new format is such a clusterfuck of unwanted features, poor hardware implementation, and removal of wanted features that it makes you wonder how it got out the door.

Hanging onto my circa 2013 MBP until they come up with a more appealing offer, or going elsewhere.

This. I gave up after several rounds of dist-upgrades broke, then fixed, then re-broke things. If you’re making fundamental architectural changes on a regular (monthly) basis, it’s pretty clear you’re not interested in being taken seriously in the business user world.

This is similar to me, but for engineering. Getting jobs via networking is much, much easier than cold-calling an interview.

Talk to your friends and workmates, ex-managers etc. If you've done good work in the past, people will be happy to get you in on the fast track. Companies hate doing interviews, so anything they can do to streamline that process they will generally do.

I'd broaden that to networking in general. Tech presentations also raise your profile, especially with manager types who attend.

> 1. Snapchat's design is remarkable for its hidden features that you discover by social-networking

Honest question: isn't this just bad UI design?

Are there any good breakdowns for laymen you could point to about this behaviour? It sounds fascinating.

I don't believe the tech industry is necessarily worse than other male-dominated industries, but that's not really an excuse not to try and do better, is it? I like to think that geeks are slightly more enlightened than our business, law, and finance brethren, who all have a bad rap when it comes to sexism.

There will always be sexual differences, and that's fine and healthy, but we should be aiming to treat women as people first in a professional setting.

No, it's an implication that the OP is dressed like a prostitute. That's not cool.

It is difficult to teach tech to women when there is a perceived bias against women in the tech industry. That is the point of this article, and others like it.

There are many efforts going into positive reinforcement for women entering the tech industry, but this is a problem that can and should be attacked from multiple angles. One of those angles is educating men about the effects of their actions toward the few women who do brave the tech community.

Also, creating assumptions based on gender, race, and other physical qualities has a name: prejudice. While there may be more women in sales roles than technical, assuming that every woman in the tech community is in a sales role until proven (vociferously) otherwise, is sexist.

There's nothing wrong with asking what a persons role is, but there are very simple ways to do that without causing offence. For example "What does your role at company XYZ encompass?" Is much nicer than "Are you actually technical?".

Men and women in tech need to be sensitive to this issue, because it is an issue which detriments the community as a whole. Better acceptance of women, and their diverse skills and opinions, will strengthen the community as a whole, and this is a goal we should work towards.

That's kinda the whole point of the article - to raise awareness of an issue that women face. This is not about taking sensitivity classes, it's about accepting that there is a problem, and doing something about it as part of a community that wants to be more accepting towards women.

About the same time they move away from the Imperial measurement system.

So you don't know what's in the standard, but you make assertions and continue to support them? That's a fairly disappointing level of discourse for HN. It requires a very similar software development process to all other functional safety standards, in which verification and validation are key steps.

Here is a paper from Mathworks describing verification and validation according to ISO 26262:

http://www.mathworks.com/tagteam/71300_1D-4.pdf

Because this completely dis-incentivises companies to spend money developing features in the first place, and makes it impossible for them to recoup the sunk cost of development over car sales, since they're competing against companies who did not pay those costs.

It's completely unsustainable.

European car manufacturers are required to develop safety critical software under ISO 26262, which is a derivation of IEC 61508, which absolutely does require formal verification and validation activities.

If you change the code outside of the development process, you could unwittingly compromise the safety of the vehicle. The manufacturer is required to use access controls to prohibit people from changing the software for exactly this reason.

Don't get me wrong, I'm the last person to defend the overuse of software patents. Where people are genuinely creating extremely complex functionality in software however, I think they deserve some protection for their outlay.

On your point about historically owning vehicles, as a software developer you will understand that there is a very wide gap in competence between being able to tune a standard motor, and being able to inspect and modify software that controls a car safely. Currently this is protected so that only the vendor can change it, precisely because that's how we wrote the standards - vendors are responsible for their code, and responsible for the safety outcomes on the road.

If we moved to an open model where anyone could modify the software in their car - what do you think would happen to the safety and reliability of that software? I don't think any of us could imagine that it would improve.

Don't worry, I'm just as furious as you are! I want realistic solutions though, and I don't think forcing vendors to open their source will fly.

For one, you will never force all vendors to comply, as some are completely outside of the jurisdiction, like China. Secondly, even if you did force vendors to comply, you've just given any new startup a massive leg-up on R&D, which the existing vendors discounted for them.

I don't think it's realistic, and there are already methods by which the code has to be reviewed externally, at least in principle. I want to improve the existing processes, not move to a new model.

Are you serious? Absolutely not. Unless you can show that you are competent to modify safety critical software, and have a certified process in place to do that, it would be illegal for you to modify the code, and you would be personally liable for any accidents caused by such a modification.

You would also require the full lifecycle documentation to allow you to understand the impact of any modifications you make, and be required to do a full impact analysis to prove that any modifications you make do not reduce the integrity of the existing safety functions.

That's completely ignoring the vendor's configuration management requirements (which you can't do).

This the whole point - devices run by software systems are too complex to be modified by a layman. There are very detailed, statutory processes and requirements around the development and modification of software in safety critical applications, and you absolutely cannot modify it just because you bought it.

By purchasing a car, you purchase an end product, which is designed to be suitable for your purposes. You don't purchase rights to a million manhours of software, free to do what you will with. If companies had to amortise the cost of code development over the cars they sold, you would end up paying a lot more for 'your' car.

> But the idea that code applying to the primary control functions of an automobile cannot be known (is not published and cannot legally be reverse engineered) is just a bad idea.

Why is it a bad idea? Do we know the code base of airplanes? Critical infrastructure, like power and water plants? How about military software that controls missile guidance?

The answer isn't to open source everything and let programmers sort it out. We have regulatory and safety boards specifically to counter the issues around public safety that software in critical applications causes. A huge amount of time and money is spent developing standards, and verifying and monitoring compliance with them.

Obviously these processes are not always perfect. In this case, it will be interesting to see how far the corruption necessary to include a pollution-defeat spreads. But throwing out the whole process and just publishing code in its place is not a reasonable solution. More stringent black box testing by experts could have caught this issue far sooner.

A random sample of each make and model of car should be periodically put through far more stringent testing than normal, in an effort to catch this kind of thing. Allowing this cheat to go undetected for so long speaks to the failure of the testing regime.