dsuth

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.

I'm surprised that the EFF would suggest going to the level of having companies publish their code. A huge number of manhours goes into developing the software that runs a car, and a significant amount of IP is tied up in it.

Forcing vendors to release software would allow competitors to steal it outright, and open up the entire industry to a massive set of lawsuits. I don't think that's a very beneficial outcome.

As someone who works in a technical safety auditing role, I strongly doubt that NDAs would preclude the widespread release of this software. I have a hard enough time convincing vendors that the lifecycle documentation they are already mandated by law to provide, should be provided. This is just unrealistic.

You would have to assume that by 'automatically failing', the test would involve checking the software version, and if it's not updated, the car instantly fails the test.

I can't imagine a test centre knowingly passing a car which has been shown to cheat on tests.

Not sure why you are equivocating in this instance. It's clearly an intentional breach of regulations, which the CEO has fessed up to. NOx emissions are a serious concern, whether they 'are' 40x too high, or 'up to' 40x too high is not a valid point of contention. Anything over the mandated limit is a health risk, and equivocating over how much is like asking whether you'd want 3 years, or 10 years shaved off your life expectancy.

That's not how pollution works. Exposure limits are based on relatively safe values; exceeding those values can seriously affect people in the area. 40x legal limits is a serious issue, not a case of 'a bit more of a bad thing'.

Students at my sons school (Australia) use the school computers to research topics, and create PowerPoint presentations. It seems like a reasonable way to introduce early school kids to computer skills, as well as some of the better uses for them.

Thanks for that comment. I have some more reading to do on CAN bus, and admittedly I come from an industry where the default is generally to turn things off in unsafe or uncertain conditions, which simplifies the protocol significantly. That doesn't help when your car is doing 100km/hr on a freeway though...

I disagree; it's not necessary to throw everything away, but an improvement should, and must be made. Existing protocols can be extended to include security (and have, see Safety CIP for an example).

Any form of engineered design is unlikely to go backwards in terms of the functionality and flexibility that things like bus communications bring, but awareness of these new attack vectors needs to be included in the base design.

This is the path that industrial control systems are taking in light of attacks such as Stuxnet, I expect that the automotive guys (who are usually ahead of the game in terms of systems engineering) will follow suit.

Edit: The problem I have with people proposing air gaps and read-only circuitry, is that they just don't work in real applications. If there is a business case against it, such as the service these jeeps were offering, then air gaps and hardwired circuitry solutions will be overridden by that business case. Further than that, as can be seen with things like the Lenovo hardware fiasco, manufacturers cannot be trusted to abide by the rules (such as: air gaps are now mandatory), when there is a benefit for them to act otherwise. As Chrysler now has the ability to remote into their cars, they are very unlikely to remove this ability 'merely' due to safety concerns.

It's far safer on the whole to offer secure methods of achieving the existing or proposed functionality, than to try and walk backwards and make things harder and more costly to implement, for lesser functionality.

Thanks for this description (and others below). In that case it's not reasonable to use this for safety critical applications, IMO. Any element on the bus becomes a potential point of entry, and there's no defence in depth once on the bus. Kinda scary from an architectural point of view.

Regardless of the firmware question with the V850 module, I'm surprised that other modules on the CAN bus would accept commands from an entity that 'should' only have read access, without validation.

I'm not up to speed on CAN bus, but if it's not possible to secure it in this manner, then it cannot be considered an appropriate communications bus for safety-critical applications. Even the industrial guys are getting their heads around this with encrypted & validated signalling over ethernet.

This appears to be offering a fundamentally different experience from Starbucks, whose business model, as I understand it, is to offer a bunch of weird, vaguely coffee-related drinks, but more importantly, space to sit down and drink them. With Wifi.

There are several variations of these running around Australian cities, however they still don't compete directly with cafes, as they provide a different service.