HN user

jgibson

241 karma
Posts0
Comments46
View on HN
No posts found.

I've been thinking about this more and more, and it just makes so much sense. No one cares what shape a beer bottle is, the label is enough to tell them apart. Marketing people will complain if they can't differentiate on packaging, but less of them isn't something to worry about either

It's not just ram that we care about, its all the other CPU caches that are significantly smaller that a larger binary will take up more space in

Another side of the organizational improvements that batteries have: redeployable.

Underprovision? Pour some more concrete, truck a couple more batteries in.

Overprovision? Load em up again and resell them to someone who wants them. Can't quite do that with a gas plant.

Sure there will be some overhead lost, but it just make soooo much sense to go with battiers from a risk perspective.

The article claims: "In the cities of New Zealand and Australia, the convenience store is known as a milk bar"

As a native kiwi, I've never ever heard it called a "milk bar". Dairy is the more common term. What say you aussies?

Tesla Inc, USA | INTERNS (Fall 2019) | Vehicle Integration, Simulation or Automation Infrastructure | Palo Alto, CA | ONSITE

Chassis Controls Software (the smarts behind track mode [1], stability control [2] and more) is looking for an intern in the fall. We've got plenty of work to do in a number of roles:

- vehicle integration (systems engineering of multiple different ECUs in the car, interface design, a fair bit of in-vehicle work)

- simulation of ECU code in combination with physical models (C, C++, Rust, ODEs, high performance computing)

- automation and test infrastructure work (general CS, docker, python experience will help)

If you think your skills overlap with one or more of the above postings, email my hn username + company domain name if you think you fit the criteria.

[1] https://www.motortrend.com/cars/tesla/model-3/2019/tesla-mod... [2] https://www.instagram.com/p/Br5XllOH6rK/

Think about it from a supply/configuration/logistics point of view. It might be cheaper to make 500k cars with 100% heated seats rather than 250k w/ heated and 250k w/o heated. Even if BOM cost is lower, the additional complexity due to the logistics and supply chain probably means it's more expensive to have both variants in production. That way people who want heated seats are subsidising the lower overall cost for those who don't. It also allows the next owner of the car to pay for that option at a later date if they want to. Almost every industry does this (there was a good case about oscilloscopes a while back, where the cheaper, lower bandwidth models just had a low-pass filter circuit installed).

Tesla | Interns | ONSITE | Palo Alto, CA, USA| VISA?

We're always hiring for pretty much any SW related roles (see the main website), but I'm after a bunch of self-starter interns to work on some projects we have coming up.

You'll get a single big-impact project over the course of your internship, working a lot with the low-level vehicle software, which is a great hands-on experience. Internships usually last 3-12 months, and can happen any time during the year.

Its stuff I'd like to be working on myself but don't have the time.

Skills I'm looking for include Docker/k8s, python, rust, c, sql/postgres, web services, maybe some front end (JS) work. You can email me directly at <HN_username>@<company_name>.com, and I'll forward you on to recruiting.

They are manual in the sense that there is a physical connection: the steering wheel is usually mechanically coupled with the steering rack, brakes usually through through hydraulics.

That said there are probably 5-20 systems in a car that can completely control these systems without any human input. Think of automatic emergency braking, traction control, vehicle stability control for the brakes, and autopark + powered steering for the steering.

Most of these systems have multiple redundancy and isolated monitors (eg, if autopark is on and the vehicle speed is > 10mph, the monitor will intervene) but there are still probably some theoretical situations where this could occur

dictates how to start a note (lacking the English term here)

Intonation perhaps? I often used the word "attack" to indicate the style of start of the note when I used to play flute, but I'd say thats far from proper terminology

Maybe. The battery chemistry for a car vs stationary storage differs greatly. Stationary storage they optimised for ability to hold charge for long periods of time, and not loose capacity over time. Car batteries optimised for weight and charging speed. If you cycled your car battery every night with the grid it wouldn't last all that long. Maybe it won't make a difference in the long run with how many EVs we have though.

While I agree the lack of repair documentation and available spare parts is a concern, Isn't the whole point of integration (at least on a chip/board level) to increase reliability?

I'm a mechanical engineer masquerading as a software developer so I could be talking out my ass, but I'm fairly sure that board failure rate is proportional to the amount of discrete components on said board.

What parts would require more fancy equipment? Induction motors are pretty dead simple and probably built to lower tolerances than the average ICE. An EV has more reliance on fancy electronics, which would be hard to replicate, but that applies to any modern day car too. Think of the engine ECU that controls fuel flow, spark timing, etc. You aren't going to pick one of those up at sparkfun.

From an engineering standpoint, Apples devices became hard to repair because they optimized for weight and size over maintainability. Would Tesla do the same? Size isn't going to be something they care about because cars are all the same size and thats what people want. From a business standpoint it doesn't make much sense either. Tesla offers very long warranties (I believe is 4/8 years for vehicle/drivetrain), so making things hard to repair would likely be costing them money. For the next 10-20 years, assuming they survive, there will be more new Teslas under warranty than older models as the production rate keeps increasing.

Electric cars are so much easier to repair in my opinion because of their simplicity, with the exception of the high voltage stuff, which I won't touch. Replacing the drive unit in most electric cars is like 2 sets of wires and 4-8 bolts. Ever tried replacing the camshaft in an internal combustion vehicle? I'd say the difference is, the aftermarket car parts business is very good at making camshafts, bearings and pistons, but not so good at making high power inverters and charging systems. But that'll change as electric vehicles become more common.

Is it just me, or are a lot of people here conflating source control management and dependency management? The two don't have to be combined. For example, if you have Python Project X that depends on Python Project Y, you can either have them A) in different scm repos, with a requirements.txt link to a server that hosts the wheel artifact, B) have them in the same repo and refer to each other from source, or C) have them in the same repository, but still have Project X list its dependency of project Y in a requirements.txt file at a particular version. With the last option, you get the benefit of mono-repo tooling (easier search, versioning, etc) but you can control your own dependencies if you want.

edit: I do have one question though, does googles internal tool handle permissions on a granular basis?

Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code