Hacker News new | past | comments | ask | show | jobs | submit | kj4ips's comments login

The starters used in start/stop vehicles are far more robust than normal ones, and start/stop in hybrids often don't even use the normal starter to turn the engine over. Because vehicles are often kept for quite some time, most start-stop systems will autodisable after a certain number of cycles, so that they only use a given portion of the starter's expected life. (disables the start/stop system, not the starter itself)


Theoretically yes, however: Currently Honda has a recall for ~40K vehicles as their start stop ends with stall.

Kia & Hyundai : 92,000 vehicles because the electronic controller for the Idle Stop & Go oil pump assembly may contain damaged electrical components that can cause the pump controller to overheat.

Chrysler (FCA US LLC) is recalling certain 2017-2019 Pacifica vehicles equipped with engine stop/start systems. A loose battery ground connection may result in an intermittent loss of power steering assist and/or a stall.

You add more complexity and there is more chance for things to break.

Also consider "Value" engineering, I can't find any data but I would be interested to see if the warranty periods for auto idle starters are longer or shorter than for the old style.

We saw this play out with the DEF system for engines, the systems were supposed to be robust and instead you end up with systems that break, harder to diagnose due to lockdown, and premature failure of components. I personal know of one manufacturer where the DEF tanks started failing after 6 months, the ammonia in the DEF was ingress into the sensors. This only started 2 years ago, so well after the systems were introduced.


> Honda has a recall for ~40K vehicles as their start stop ends with stall

Not a Honda, but one time, I accelerated aggressively from engine-off stop and stalled in a way that wouldn't have happened if the engine were idling.


There is, it's a few days old, and it's a non-enforcement from the Biden administration, according to the man himself and his staffers, he intends to let it be the next administration's problem. Whatever the next administration does when it takes power is yet to be seen.

The restrict act was written really strangely, and I assume Oracle required some assurance from someone to not just delete Bytedance's accounts and resources.


That wasn't an executive order, as far as I'm aware it was just a statement. It had no legal value, which was why TikTok asked for more assurance.

The fine to each company (Apple, Google, Oracle, TikTok) was in the order of around $5bn each if they kept the lights on, so I would be hesitant to keep it running too without something in writing.


If TikTok was concerned that Biden’s statement wouldn’t be honored, they wouldn’t have turned service back on today while Biden is still president. They’ve had months to work out some sort of deal with Trump, this whole show they’ve put on the past couple days is propaganda.


I have to agree with this. If they'd waited until Monday it would have been different, but legally nothing changed overnight except more puffery.


Right. The Legal teams at Apple and Google will follow the existing law as written.

No EO from Trump will change that.


The title was changed, it used to be "Trump's executive order..." something.


There's a few cases where this makes sense:

* The laptop supports one or more power supplies, but with different current ratings, and the laptop needs to know how much it can safely draw. (This can be done with passives)

* The charger has dynamic power availability, possibly because it charges multiple devices, and the amount of power available varies with other factors, such as temperature.

* The charger has various output modes available, only some of which align with the device to be charged. Therefore, the two devices must negotiate a common set of parameters.

On the note of USB Condoms, they only interrupt the data lines, USB's power negotiation (nowadays) mostly happens on the power line itself. Though usually, the device's OS (if it has one) has limited/no visiblity to this, and a dedicated port controller handles this interaction, possibly passing higher-level information to the rest of the device.

There are some things that can be done to reduce the threat surface:

* Build the protocol parser as a FSM.

* Formal methods for critical systems.

* Severely restrict the expressiveness of the protocol, particularly any variable-length fields.


I've heard a ton of stories about .io, IMO, they play fast and loose in a space where that isn't okay, and they get away with it mostly because they are a ccTLD.

The last time someone I knew had an issue, they had to get a senator to make waves to get anything resolved.


I regret going with .io for my personal domain name. At the time I thought it was cool, but they've since raised prices and hearing things like this doesn't instill confidence...


That, and the Indian Ocean territory will cease to exist in the (very) near future, so the .io domains might be going the way of the dodo. I won't be registering any new ones at least, and recommending everyone to stay away from them.


And isn't .io on borrowed time, since the country will soon no longer exist?


Do they get rid of TLDs once the country they are assigned to goes away? I assumed they'd sell them to someone or something.


Nobody really knows. There are only a few precedents, i.e. the old Soviet Union .su tld being kept around, or the 2 letter country code that I can't recall which was reassigned to a new country after the old one went out of existence.

There isn't really a precedent for a tld with as many domains under it as .io, it's a very strong possibility it will be kept around and given to a private entity or even to GB.


.cs for Czechoslovakia lasted from 1990 to 1995.

.yu for Yugoslavia ran from 1989 to 2010.

Wikipedia has comprehensive articles on both of those ccTLDs, if you're interested in learning more


They might not have much of a choice but to shut down all .io domains. This video explains a little: https://www.youtube.com/watch?v=1yJ6AZsUlpc


Who is "they".


Yes, it will be deleted; see: https://www.iana.org/help/cctld-retirement


.su is still around.


That's why they are shutting .io to not make the same mistake again


TBH, my biggest gripe is that systemd doesn't play nice with musl or ulibc, I would like to not have to ship a cron, a supervisor, a xinetd equivelant, and a binary just to react to inotify/dnotify events. Though openrc how has a supervisor.


I have a vehicle w/o AM radio, and our local traffic authority uses an AM station for traffic and other civil alerts. It's really annoying that it is absent.

The FM is also an afterthought, the antenna system under-performs horribly, and appears to actually be //inside// the cabin.


I suspect this mostly refers to "Code Protect" or similar functions, that are designed to stop the user for extracting the firmware from a device in the field. Typically, when this is enabled, large parts of the debug interface stop working, and turning it off requires a "secure" erase, that clears the loaded firmware.

While many CP implementations are flawed, or can be bypassed by a skilled attacker (power glitching, &c), I wouldn't say they are purely theater, as they raise the required investment from a <$10 ISP to $$$+ for something like a chipwhisperer.


Consider that in other fields of computer security we treat a device where attackers have physical access to be de facto compromised.


Even with chip security features this is still the case (if an attacker gets their hands on it it can be compromised). There's no chip that exists that I'm aware of that can't be compromised to have its firmware dumped.

It's like locks: Every time a manufacture claims to have made an unpickable lock someone goes and picks it. It's the same for chip security features.

Microcontroller "security" features really are security theater and not actual security. The only real reason they exist is because certain vendors/"big buyers" will require it as part of their parts checklists (which is silly) and it provides a way for chip manufacturers to wriggle more money out of each sale.


I was taught to listen to the sound the water made in the sink to tell when the hot was ready. I had always assumed this was something most folks already knew about.


I run it in my homelab, because gitlab is really reasource intensive by comparison, and I need it to work when the network is out. The annoying part is that means outside contributions that support enterprise-y features are probably not going to be accepted. Gitea does not appear to use a CLA, so they at least shouldn't be able to re-license existing OSS, but the base license is MIT, so no virality.


> NHTSA instead focuses its resources on forcing a draconian “recall” on Tesla to increase the font size of the brake icon.

An update that probably took an engineer less than a day, and CI mere hours to build? The recall terminology is a little silly with an agile-ish developed product, but they really should have done it right the first time. It's not like the standard is hard to read. It probably only bubbled up to the top when someone who has designed these kinds of things in the past noticed it was out of spec, and complained.


It was in every vehicle back to 2012... And was seen by every driver every day.

Hard to argue that this rule breaking is a problem when literally millions of people saw the rule breaking on literally billions of occasions before the violation was noticed.


Generally the way that laws and rules work is that it doesn’t matter how long you’ve been breaking the rule or law, but when you get caught, you have to remedy the problem otherwise what’s the point?


Completely fair, but the fact that this “problem” was so ubiquitous for so long should be factored into the decision of whether or not to issue a recall. Recalls aren’t without negative consequences - huge effort and actual cost, opportunity cost of other things regulators could focus on, and the impact to what it means to the term “recall”.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: