> OrcaSlicer-bambulab: if the goal of this fork-of-a-fork is to bypass Bambu's cloud servers, why would it still need to "impersonate" the UA and communicate with Bambu's servers (as Bambu claimed)? Wouldn't the whole point be to avoid doing that in the first place?
I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system.
The alternative is to run the printer in LAN mode (which OrcaSlicer has always supported) where the client connects natively over MQTT, but after Bambu added their cloud authentication, this requires putting the printer in Developer mode and severing the Cloud features.
My understanding is that right now, you can run your printer in LAN or USB mode without Bambu's cloud, and this is supported natively by OrcaSlicer (or any slicer using USB), but you lose some of the Cloud monitoring features.
You can also use Bambu's cloud with their Cloud Connect app and gain those monitoring features while using a third-party slicer, but at the expense that you send your prints through their cloud.
Or, you can use Bambu Studio and get the "fully integrated" experience.
My understanding is that this plugin just replicated their Bambu Studio communication with the Cloud, and that it _enabled_ you to send your prints to their cloud, not _disabled_ it. Is there something I'm missing that made this valuable? (ie - did it do some hybrid where it could hack in the Cloud monitoring without sending the prints through the Cloud?) Otherwise, I think what Bambu are doing are distasteful but I don't understand all of the Chinese espionage hand-wringing or "stealing our files" commentary around this.
EDIT: I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system. This makes more sense. I wish the commentary on this subject would actually explain this.
I'm actually really confused about the language used in the recall; I looked at the Cybertruck manual and the brakes look like a "conventional" design where the studs are set into the hub and go through the rotor, so this failure seems somewhat unrelated to the brake rotors, and the "brake rotor stud" is also the wheel stud: https://service.tesla.com/docs/Cybertruck/ServiceManual/en-u...
I'm assuming it's a misphrasing or typo and the issue is that the stud holes in the wheel hub rotor can elongate, leading to the studs coming out. This can and likely would absolutely cascade into a wheel falling off; I've seen it many times in cheapo endurance racing series - once one stud is loose, the adjacent studs gradually loosen and eventually the wheel separates. If the issue is longitudinal (slotting) it's even more likely to lead to a rapid separation event.
Modern gas crate powertrain swaps which include engine management usually have the same restrictions; GM Connect and Cruise, Hellcrate, Ford Performance, etc. What you’re describing with LS swaps is unique to kits that come with no engine management; it would be as though this kit were sold with no inverter and motor controller. Of course, reverse engineered aftermarket tuning is more readily available for gas ECUs, but that’s just a matter of market forces, not the OEMs.
> Haskell gives you tools to encode these incantations in types so they cannot be forgotten. This is, for my money, the single most valuable thing the language offers a production engineering organization.
Haskell is admittedly, probably the most powerful widely (or even somewhat widely) used language for doing this, but this general pattern works really well in Rust and TypeScript too and is one of my very favorite tools for writing better code.
I also really like doing things like User -> LoggedInUser -> AccessControlledLoggedInUser to prevent the kind of really obvious AuthZ bugs people make in web applications time and time again.
I've found this pattern to be massively underutilized in industry.
This isn't specific to Rust or Typescript. You can do this in basically any language.
Imagine you have to distinguish between unescaped and escaped strings for security purposes. Even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods). There's a performance cost to this, so that's a tradeoff you have to weigh, but it is possible.
Another way of doing this is Application Hungarian[1], though that relies on the programmer more than it does on the compiler.
> This isn't specific to Rust or Typescript. You can do this in basically any language.
This just isn't true.
In any dynamic language you would not get these guarantees at compile time. You'd get random failures at runtime. That's not safety of any kind.
Also, part of the goal of languages like Haskell is that they help you think about your code before it runs. All of that is lost.
> Imagine you have to distinguish between unescaped and escaped strings for security purposes
That would be a nightmare in many languages. You'd have to rewrite large parts of the code to be compatible with one or both. And in many languages you'd have to duplicate your code entirely.
In other languages, the result would so ugly, you would never want to touch that code. Imagine doing this with say, templates in C++.
>There's a performance cost to this
There is no performance cost in Haskell! This is entirely undone by the compiler.
Also, because the compiler understands what's going on at a much higher level, you can do things like deriving code. You can say that your classified strings behave like your regular strings in most contexts, like say, they're the same for the purpose of printing but not for the purpose of equality, in one line.
That part is (de facto) required for dynamically typed languages, but not for statically typed ones where the newtype constructor/deconstructor can be elided at compile time. Rust and C++ especially both do the latter by having true value types available for wrappers that evaporate into zero extra machine code.
But then just this moment I wondered: do any major runtimes using models with no static type info manage to do full newtype elision in the JIT and only box on the deopt path? What about for models with some static type info but no value types, like Java? (Java's model would imply trickiness around mutability, but it might be possible to detect the easy cases still.) I don't remember any, but it could've shown up when I wasn't looking.
> [Performance cost] is (de facto) required for dynamically typed languages, but not for statically typed ones where the newtype constructor/deconstructor can be elided at compile time.
For a single value, it should reliably be free in any reasonable statically typed language that meet your other criteria.
For a collection, it may still be de facto required. Unwrapping a set of addresses into a set of strings takes unnecessary cycles, an unsafe coercion, sufficiently sophisticated affordances around coercion that it can be safe, or a smart enough optimiser. At least some static languages have at least one of these; I'm not sure all do, and certainly not all have always had.
Well, java can do escape analysis, so a wrapper with a single field may end up as a local variable of the embedded field.
As for other JVM languages like Kotlin and Scala, they have basically what "newtype" is, but it can only be completely erased in the byte code when they have a single field.
Escape analysis that sinks a local allocation is great in itself, but for newtypes for things like “trusted HTML vs plain text”, I feel like the primary benefits are deeply interprocedural. The type constraint is encoding a promise that can be carried from one end of the code base to the other, and where you can know for sure when you're writing a module whether you're on one side of a barrier or the other. I would tend to expect this to result in patterns that aren't well-handled by escape analysis.
What I'm imagining for my curiosity about the dynamic case would look more like “JS/Lua/whatever engine detects that in frob(x) calls, x is always shaped like { foo: ‹string› } and its object identity is unused, so it replaces the calling convention for frob internally, then propagates that to any further callers”, and it might do the same thing when storing one of those in fields of other objects of known shapes, etc. until eventually it hits a boundary where the constraint isn't known to hold and has to be ready to materialize the wrapper object there.
Kotlin and Scala sound like they're doing the Rust/C++ thing at the bytecode level, if it's being “erased”, so just the static case again but with different concrete levels for machine vs language.
What you cannot do is compile-time safety guarantees, and in languages like Rust type system isn't strong enough to do some advanced compile-time guarantees (via types). So no, you cannot do this in basically any language (unless you turn it into Haskell).
Rust (and Scala) type systems are somewhat stronger and more expressive in some areas than Haskell. Weaker in some other. But it’s not a clear cut that Haskell type system offers more safety guarantees.
> But it’s not a clear cut that Haskell type system offers more safety guarantees.
You can log operands in your implementation of Rust's Add trait, or compute running sum of one of the operands. In Haskell it is not possible unless you use unsafePerformIO from System.IO.Unsafe.
Haskell's type system controls effects available to the code. This can be used to implement programs adhering to specific formulas of Linear Temporal Logic or implementing a protocol specification, where operations on any given phase and side are restricted by type system.
I used Haskell's type system to prevent crossing of clock domains in the hardware description eDSL. Also, it was of great help in the CPU simulator description, fixing available commands and resources for different CPU models.
Even the logic of Rust's borrow checker was expressible in Haskell as early as February 2009 - there was HList, there was ParameterizedMonad and that's about what one needs for implementation of borrow checker.
Caveat emptor, I'm not a Haskeller, just an admirer. But Haskell let's you run functions over the type system itself very elegantly, so you can have a type that is derived from a type that composes three types that are derived from several functions' declared runtime behavior. This kind of type inference can provide arbitrarily rich information about anything in the entire program, letting you encode more than just range-types etc at compile time.
This comes with some design drawbacks. I think Rust's borrow checker would be implementable but unreasonable in Haskell: Haskell already does lazy-evaluation on types to enable its arbitrary depth of type expressivity. But the borrow checker also wouldn't really make sense for Haskell because the default programming model uses a GC. I think Linear Haskell might be a kind of Rust-in-Haskell, though.
I've spent long time writing Haskell and now write Rust professionally, so let me tell you something. The stuff where you really want to "program in types" lives beyond Haskell, in languages like Agda, Idris, some HoTT stuff etc. anyways.
In principle the more developed the type system is – the closer it to not distinct between types and values. Caviat is that its "type inference" gets worse.
So, in those more developed languages, you could have type-level proofs (guarantees) that your calculator produces correct results, as a proof, as theorems. That 2+3 will be 5, not as runtime test assertion, but as a theorem, that no other result is possible no matter what happens. Or that your parser will never fail on valid JSON etc. but nobody guarantees it's going to be a pleasant thing to write, maintain, and debug. And compile times will probably be terrible.
> The rank-2 type (that is, the type s is scoped within the parenthesis and can't escape) of runST ensures that the mutable references created inside the computation cannot escape due to being tagged with the type s. Internally, all sorts of imperative nonsense may occur. Externally, the function is pure. The world outside the boundary gets none of the mutation, only the result.
C does not have parametric polymorphism, nor rank-2 quantifications, so no, this cannot be done in C.
This was not the original claim in the thread I responded to which as "even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods)." so this was about abstract data types and not polymorphism.
Regardless, you can also have some limited parametric polymorphism in C with macros. This is very poor, but parametric polymorphism in Rust is based on monomorphization so it is also quite poor. You can also have higher-order polymorphism in C but then you need to use subtype polymorphism.
Tell me you haven't understood what a type system does without...
A type system mathematically proves, at compile time, what a program can and cannot do. No, you can't "do this in basically any language".
It's ironic that "shift left" is generally considered a good thing', but when you point out that you can shift a significant majority of checks left all the way to compile time, they say "no, not like that!"
And categorically: the issue isn’t what “I’d” do, my habits often match my habits, it’s what other project members will be doing (including future degenerate versions of myself assumed to be some combination of busy, tired, stressed and drunk).
The Confucian philosophy that people act like water coming down a mountain, seeking the path of least resistance comes to play.
Haskell, OCaml, F#, and their ilk can yield beautiful natural domain languages where using the types wrong is cost prohibitive. In languages without those guarantees every developer needs discipline to avoid shortcuts, and review needs increase, and time-pressure discussions rehashed.
You demonstrate well the problem: yes anything that is computable can be than in any computation system. That's not what discussions about tooling are about.
If a tool can help enforce some ways of doing things, or if it doesn't constrain people much, that has consequences for the type of work that gets done with them and the systems you encounter running out there that you might be invited or find the need to work with.
"I can do it" is exactly the wrong answer. "How can I guarantee that others will do it" is the point being made.
Some people, teams and orgs can benefit from it. "I don't need it" is missing the point. "Not everybody needs it" is missing the same point from a different direction.
And of course Rust and TypeScript were heavily influenced by Haskell... they just don't mention it and call things differently, to avoid the "monads are scary, I need to write a tutorial" effect. Though it's less about monads and more about things like type classes.
Rust's influence was OCaml, not Haskell. Its first compiler was written in OCaml. Its syntax directly looks like OCaml and C++ had a baby. It's got ML smells all over it. Haskell is not the sum of Hindley Milner-esque languages.
Personally, never enjoyed Haskell's syntax (or lack of it) and tendency to overthinking. But I did enjoy SML/NJ and OCaml to some extent.
Haskell type classes are not classes (like Java or PHP classes); they are comparable to Rust traits -- which are different from PHP traits which are comparable to Java/C# interfaces (with default impls; if you just want contracts you have... PHP interfaces).
A fundamental difference is that you can instantiate/implement a type class (or Rust trait) for any* type, compared to interfaces where each class declares the interfaces it implements. You can therefore create generic (forall) instances, higher kinded type classes, etc.
> Actually in modern Java you can simulate type classes approach with a mix of interfaces and default methods implementations.
Can you? The beauty of traits/type classes is that you can attach them to any type - in a world where 90% of the functionality of any piece of software is supplied by dependencies - external types which you cannot change - this is a vital feature.
Failing that, there are always Clojure, Kotlin and Scala on the JVM, which expose language features to achieve the same, which you naturally can mix and match with plain old Java.
Why the reference to “modern Java” then? Writing adaptor classes is not “modern Java” nor does it involve using “a mix of interfaces and default methods implementations”.
I was responding to your original claim and I’m well aware of such facilities in both Kotlin and Scala - having used both extensively. I was genuinely curious if the latest Java was in the process of adding support for trait/typeclasses - so I don’t understand why you’d bother to reply with something that completely changes your original claim.
This is more of a question of Affordances than type systems as per se e.g. you can do this quite happily in C# or something it's just that the amount of visual clutter is more than the actual type definition.
I think that's getting better in C# with record types (and primary constructors in general). Real Discriminated Unions should help a lot, and that's finally in Language Preview now.
I'm not convinced it really works well in typescript. the lack of nominal types requires you to remember some pretty hacky incantations if you want something like a newtype wrapping a primitive type
my experience is that ocaml is more powerful than rust for enforcing this sort of type safety, because you have gadts that give you more expressive power, and polymorphic variants and object types (record row types) that give you more convenience. and the module system and functors of course.
you also avoid some abstraction limitations/difficulties that come from the rust borrow checker for places where garbage collection is just fine
It really feels like we’re solving the wrong problem sometimes. If a bad type can crash your application, sure, type safety is one answer but I have to admit I like the erlang approach; if something unexpected happens crash the process (not os process, erlang process) which has a very small blast radius on a well architected system (maybe doesn’t even fail the individual request that caused it). I wish more languages had this let it crash philosophy, it really allows for writing code exclusively for the happy path, safe in the knowledge that a -1 where a “string” should be isn’t going to take down production.
Somehow, it feels like a better solution than these complicated type systems. Does any other language do this outside BEAM?
When working on large, important software, crashing is not the worst thing that can happen; corrupting user data and/or allowing unauthorized access is.
The point of using the type system to do something like distinguish between sanitized and unsanitized strings is specifically to prevent these kinds of security breaches.
Erlang was designed for traditional telecom, where reliability of connections was the biggest factor, not security. I fail to see how Erlang’s approach can deal with the issue of security breaches or corrupted user data.
In a way I agree with you, and I'm not sure that what popular languages embrace or make it easy to follow this philosophy. My sense is that Erlang is still the leader.
But I did want to add something the article also touches on: types can be not only about ensuring safety or correctness at runtime, but also about representing knowledge by encoding the theory of how the code is supposed to work as far as is practical, in a way that is durable as contributors come and go from a codebase.
Admittedly this can come at the cost of making it slower to experiment on or evolve the code, so you have to think about how strongly you want to enforce something to avoid the rigidity being more painful than valuable. But it's generally a win for helping someone new to a codebase understand it before they change it.
Edit: another thought I had is that type mistakes do not always causes crashes. Silent corruption can be much more insidious, e.g. from confusing types which mean something different but are the same at the primitive level (e.g. a string, number or uuid)
For me this has been a life saver being the only back end developer at the company. I don’t have the energy nor time to think about every possible scenario, especially not the mobile client sending random strings to something that should be parsed as an uuid (has happened more than once).
By letting it crash I can have a look at the traces at my own leisure and a lot of them I never fix, because I don’t have to.
The amount of silencing (implementer error, but quite prevalent) of errors I’ve seen in typescript codebases are horrifying. Essentially ”try happy path, catch everything else and return generic error”, the result is is mostly the same for the user, but night and day for me who is trying to fix it.
Or have a static type system and something like BEAM. I'm not sure why this is a one or other approach, both are useful and unfortunately it doesn't seem like any languages include both. Gleam exists but doesn't really integrate with BEAM, it seems to have its own way of doing things that are more akin to Haskell, given its origins.
>if something unexpected happens crash the process
There are some expectations where that's a reasonable response to a violation, but there are many expectations where the violation implies a bug elsewhere and crashing the process will do nothing to address that that wouldn’t have been better accomplished with stronger compile time checking.
EDIT: previously the example in the parent comment was:
type NewType<T> = T & { __brand__ : Symbol }
---
This seems wrong; the type spelled `Symbol` refers to the boxed interface for symbols[0]. I suspect you meant to write `unique symbol` there, but it can't be used in that position.
I'm not sure if `NewType` in your comment is supposed to stand in for a specific newtype (in which case it probably doesn't need to be generic[1]) or if it's supposed to be a general-purpose type constructor for any newtype (in which case it should take a second type parameter to let me distinguish e.g. `EmailAddress` from `Password`[2]). The use of `unique symbol`s is also only really necessary if you want to keep the brand private to force users to go through a validation function or whatnot, otherwise you can just use string literal types.
I agree these incantations aren't big problems (it all falls out naturally from knowledge of TypeScript's type system, and can be abstracted away as per my comment in [2]), but the fact that you goofed in the very comment where you were trying to make that point is causing me to second-guess myself.
Right. Besides getting this incantation right, as gp did only after editing their comment, you also have to cast to create values of NewType. But generally you want to avoid casting in typescript if you care about type safety, so now everybody has to remember the rule that in this particular circumstance it's the right thing to do.
There are helper libraries to ease this (zod supports branded types, I think?), but I guess my general point is that while typescript might give you the ingredients you need to implement type safety in cases like this if you try really hard and remember all your rules everywhere, it doesn't come naturally so it's hard to maintain at scale.
I was on the Tube and wanted to get my reply in before entering a tunnel. I already corrected it whilst I was underground.
I think the point still stands - is this really a big problem? I guess I couldn't recite the syntax from memory, because I usually use a utility type for this
Agreed. Clojure gets this with Mali and Spec. That said, types are such a productivity boost over time that I think they should only be discarded for very good reasons.
I think you csn also goa long way with C++ and templates to represent sny kind of restricted type in the type system. Variants are somewhat clumsy without pattern matching but most tools you can make use of are already there I would say.
In my backend system I represent users with different variant states to avoid a lot of unrepresentable states.
As for underutilization, I think only functional languages, Rust and C++ support variants and that might be one reason: people just make blobs of state and choose which fields to use instead of encoding states and make some combinations unrepresentable. Javascript, Java, C# or Python do not have Variant types to the best of my knowledge.In Ocaml and Haskell and with pattern matching they are very natural. In Rust with enums, same. In C++, they are so so but still usable compared to the others that do not have.
In my load tests I even went, since I launch thousands of clients, with a boos.MSM to drive the test behavior. One state machine per user.
You can't in Haskell either! For example, any function could secretly call `unsafePerformIO` to cause a side effect (and that's not the only example).
I believe `const` functions in Rust are actually be guaranteed to be pure, though I haven't followed that feature closely and there may be nuances.
In most languages purity is a norm rather than enforced by static analysis. I definitely agree that it's much safer to assume that an arbitrary Haskell function is pure than it is to assume that of an arbitrary TypeScript function.
You can compile Haskell code with the -XSafe flag, and this is communicated in the package, so something like backpack can be told to load only safe modules. Still, there's probably plenty of code that's safe but not pure, but that's as good as we're likely to get.
It had hot code editing and a hot code editing debugger. To me, these were the main features that were interesting about VB6 vs. Delphi. Delphi won in basically every other axis (databinding, real OO, visual inheritance, etc.).
Also, while it certainly had some sharp edges, the ActiveX / COM component system (ActiveX Controls) was pretty good; you could make reusable UI blocks as a first-class citizen in the IDE. You'd just pick an ActiveX Control as your product and the thing it produced was an OCX you could just drag onto another project, where it would spring forth as a full first-class item on your form (unless the initialization failed, which in fairness it frequently did). There was a good commercial ecosystem for buying stuff, too; charts, graphs, insanely complicated data tables, it was all there for some moderate price. This culture carried over to .NET to a good extent, but it never really reached the peak it did with Visual Studio 6.
What's funny is that we have all of these capabilities today, still, we haven't "forgotten" about "how to VB6," we've just decided we can't use them because:
* Screen sizes and DPI ratios are highly variable and so there is a high demand for dynamic layout, which is difficult to express in a visual editor.
* Source control is more popular than it was.
* More front-end code is built collaboratively, so not only do artifacts need to be controllable, they need to be diffable. Nobody has really managed a diffing solution that humans like that's not lines-of-code (and trust me, they've tried, I have years worth of Thoughts about this!), so this really means "the UI designer needs to decompose to human readable line oriented statements" - which is where we went from VB6 (and Interface Builder NIBs, and so on and so forth) to newer generation UI technologies or a preference towards layout-in-code like SwiftUI.
* Cross-platform compatibility is more important than it was, and every cross-platform non-web UI framework got extinguished in the early 2000s by a combination of security becoming a real concern and Steve Jobs, to be replaced by web-based frameworks today.
Windows Form Designer in Visual Studio still works in that same way? This was one of the least differentiated things, really; while XCode’s interface building tools have always been clunkier they also offer the same functionality too.
SkySafe (https://skysafe.io) | Wireless Engineer (SDR) | San Diego, CA | REMOTE or HYBRID
At SkySafe we build drone detection and tracking at scale.
I am looking for a Wireless Communications Engineer with SDR expertise to join my team; I'm the hiring manager.
What I'm looking for:
* Background in wireless communications / signal processing theory and math.
* Experience building software-based wireless modems.
* Experience writing and optimizing software-defined radio code in C++ directly.
What you'd do:
* Implement all components of software defined modem systems from specifications and alongside our reverse engineering team (no RE experience necessary!)
* Optimize existing software defined modem systems from both a theory and practice perspective - that is, make both conceptual improvements to algorithmic approaches as well as practical improvements to implemented code.
* Architect and implement high-level improvements to SDR systems (scheduling, compute offload, etc.).
We have a strong system in place for remote SDR work and are open to remote candidates for this role. If you're in San Diego and want access to an office with nice equipment, that's even better. This position requires access to technology which is controlled by US Export laws, so you also need to be an eligible US Person.
What we have to offer: $145-200k. Fun, small team dynamic. Work with experts in adjacent fields. Startup environment with good work-life balance and limited red tape. Rapid iteration and feedback in the wild - make a change, deploy it, and see telemetry come back in the same day. Good equipment at the office.
Apply: brian@ for a direct line, https://jobs.lever.co/skysafe for the formal route (we have some other roles I'm not the HM for listed there, too, if you're interested in the company!)
> limit or disable certain functionality in the vehicle: ... over-the-air updates, which provide new ... safety enhancements ...
I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
This is a huge unresolved issue with EVs IMO; ICE cars are required to provide emissions-relevant updates over software which can operate using a J2534 passthrough device, which effectively means powertrain modules have to allow (potentially signed) updates over CAN using software that can be obtained by an end user (a lot of people don't know this; for almost any ICE car in the US, you can buy a 3-day or 1-week subscription to the dealership level diagnostic software for a somewhat reasonable fee and use it with a J2534 device).
But for EVs, there's no such rule and as far as I can tell it's entirely a gray area in the US now; the NHTSA require a "remedy" for recalls but nobody seems to have pushed back to determine whether OTA is truly a remedy. The traditional autos all offer dealerships as a backup option, but Tesla and Rivian have several recalls with only OTA remedies already. This seems sketchy.
> I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
I would assume so. Even on older cars, service techs can typically manually push firmware updates over the OBD-II / J2534 port. Rivian's OBD-II port actually hides an Ethernet signal inside of it - so the interface is certainly there.
> Rivian's OBD-II port actually hides an Ethernet signal inside of it - so the interface is certainly there.
Nice. This is really normal now, for what it's worth - all of the European makes have moved this direction as well (DoIP over ENET). There's shockingly little documentation about Rivian online, though, probably because emissions regulation doesn't mandate it.
I don't see anything suspicious, but I browse with scripts and ads blocked, so it's possible that you encountered something that never reached me. Thanks for the warning. Unfortunately, it's too late to edit my comment.
Yep! Depending on the vintage, BMWs have "real" DoIP or a BMW-ized version (sort of like how KWP2000 was the predecessor to UDS). For emissions modules, they still also have to support updates over UDS as well as ENET, though, for the above mentioned J2534 reasons (Ethernet wasn't added to J2534 until 2022).
Actually almost any fuel injected vehicle can accept flash updates through the port to at least the ECU and PCM, frequently the BCU is also write enabled.
If there is a BCM. My previous 1995 GMC C1500 had a PCM and the automatic transmission was controlled by mechanical linkage to a hydraulic computer in the transmission along with shift solenoids from the PCM. It also had "throttle-body injection" with two injectors replacing the carburetor. The OBD 1 system would switch to "open loop control" with preprogrammed injection in the event of a malfunction which would make the thing challenging to drive until you fixed the problem. So very simple compared to the multitude of computers and control systems in use today.
A nice feature on that system was that you could put a paperclip between two pins on the diagnostic port and it would blink out the trouble codes on the SES light.
You can adjust the ECU for these 80s and 90s cars and “flash” them like anything else. There’s just a lot less settings! Not sure about the 70s but I’m sure some resto-mods also allow for this.
Even more tangential: Kia declined to cover an engine failure, under warranty that was extended by recall because I change my own oil.
Kia's engines are known to fail predictably even within first 100K miles. They extended their warranty because of it. But then they weasel out of it unless you hire an attorney and go to war.
This doesn't require research. Just reject by default and concede if a lawyer shows up. It doesn't cost any money to have a default denial policy and saves millions.
Yeah, because you allegedly consented to them being able to update your ECUs via the mobile link in the cars when you bought the car.
As if I needed another reason to keep my 2014 skoda.
If i ever have to get a new car, i will disable telemetry, and i will buy it either without telemetry, or with the agreement that i do not consent to telemetry.
(read the fine print before getting a new car. the shit they can do that can go wrong and you have to pay for.. no wonder old cars cost as much as new ones.)
I assure you that “old cars costing as much as new ones” isn’t the result of the market force of people reading contractual fine print and/or freaking out about telemetry. Concentric circles of echo chambers over here.
The main reason is more tangible to people. It is more reliability and simplicity. For instance the Toyota Tundra used to have a V8 that was pretty bomb proof. But over the years, manufacturers put in more efficient but more prone to problems turbocharged smaller engines. The bearing clearances went down, thinner oil then can be used which is also more efficient. But the margin for error when you are putting what used to be a performance engine in a car is much smaller and there have been issues. As car prices have gone up, people value a time tested drivetrain. There have been a lot of problematic CVT transmissions too.
The Chinese government banned Tesla vehicles from entering (Chinese) military bases. This is due to the prolific number of cameras streaming live video to a hostile (to China) organization/government. One can find blogposts by analysts who show that the upload stream from Tesla vehicles includes cabin audio.
I’m not worried even a lick about what cars cost electronics or otherwise. My primary factor in selecting a vehicle is my physical safety; after that it’s electronic surveillance.
> I have never met anyone in real life that's concerned about telemetry on their car
You mean you've never had a conversation about it. You can't know if you've met somebody that has that concern unless you've broached the subject explicitly.
1. get a _real_, unabridged service manual. that takes some darkweb experience nowadays.
2. identify anything that looks like capable of housing a cell modem. that takes some understanding of contemporary car electronics
3. deny RF interface to units identified. that takes some understanding what RF = radio frequency interface is and also getting rid of fear of disassembling significant portions of your car.
That is the least of your troubles. SOS is the telemetry you wanted to get rid of in the first place.
And chances are you would have to get rid of 2/3 or more of oem electronics.
It'll end up a prototype vehicle or something, with custom ECU and stuff. On the bright side it will belong to you and not to the some mckinsey guys running those insurances and whatnot. It has been done too, although I personally prefer to just use vehicles that do not require this level of effort.
The other day there was a thread on unclouded tractors what I missed and I must tell I love my Universal 445 made in Romania in 1989. For all its quirks, it just gets the job done, no connectivity, no nothing, it's an unbreakable 3-cylinder diesel that just works.
It works depending on the manufacturer. Honda places the TPU in the dash behind the head unit. Use some spudgers and you can disconnect and remove the TPU. Takes 15 minutes at most.
Nice, thanks for the reply; this is surprisingly undocumented online. Presumably if they got cornered and the module under repair was updatable via this mechanism they'd have some ability to use that system, then. I wonder how charitable they will be about using it for non-recall updates for customers who have solely chosen to opt out.
Rivian are probably the only major manufacturer I've never had a chance to look at in any RE capacity and I'm getting more curious by the second. The reaction their vehicles had to the infamous bricked-infotainment update actually represented a pretty good adherence to safety guidelines (the drivetrain as well as the speedometer and warning lights on the cluster still worked in a degraded format even when the infotainment was bricked) IMO, so they do seem to apply a reasonable degree of care.
I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
Yes.
You get a letter in the mail asking you to take your car to the dealer so they can install the update.
Interesting, I reviewed every Rivian software update recall letter I could find before I posted this and they all said something like "If you have not already updated to software version 2025.18.30 or later, please do so to remedy this issue at no cost to you," with no mention of the dealership as a remedy - for example, https://static.nhtsa.gov/odi/rcl/2025/RCLRPT-25V585-0759.pdf . This is different from other manufacturers who explicitly mention the dealer, like this Ford EV recall: https://static.nhtsa.gov/odi/rcl/2025/RCAK-25V863-3736.pdf
Of course they don't mention it. They don't want you to bring it in and have to pay a tech to do the update for you. It doesn't mean the dealership can't do it.
I'm sure they are, but I live in rural MN and Teslas are fairly common here, including the (barf!) Cybertruck. I'm seeing an increasing number of Rivian SUV's now.
In the US, a vehicle with an outstanding recall technically isn't roadworthy, though consumer level enforcement of this is non-existent in practice. It's mostly enforced on dealers, who can't sell a vehicle with active recalls. The only way I can imagine it mattering to a consumer is if they sold it.
Doesn't being legally non roadworthy only apply to NHTSA safety recalls while there are other types of recalls for non compliance or manufacturer voluntary recalls?
Having worked (on the vehicle registration system) for a state agency that is a combination "department of motor vehicles" plus "highway department", there could be a case made that since your vehicle does not meet NTSB/DOT standards, that it isn't roadworthy and the best you could get would be a SALVAGE title. Which would require expensive inspections if you try to sell it or register it.
In Europe, car manufacturers have to show that their cars meet safety standards. In the US, car manufacturers only have to say/certify that their cars meet safety standards. This is the huge sticking point for Trump's attempt to force EU countries to accept cars that have not been proved to meet safety standards (it is portrayed as "unfair/uneven trade barriers" in the US media).
Not disagreeing with you in general, but as another datapoint, in MN a vehicle only needs a theft inspection (no charge) to clear a Salvage title. DMV explicitly states that it's not a safety inspection. They really only care that you didn't repair it with stolen parts. IME you show them receipts for parts you bought, and the inspection is over in less than 5 minutes.
...do dealers have any way to update control modules besides OTA?
Of course they do. It would be absolutely silly not to. And in the case of safety recalls, their duty to inform you would entail a more traditional and substantiated disclosure i.e. a letter.
"a lot of people don't know this; for almost any ICE car in the US, you can buy a 3-day or 1-week subscription to the dealership level diagnostic software for a somewhat reasonable fee and use it with a J2534 device"
Whoa, didn't know that. Well the caveat is finding a decent J2534 device, right? There are a lot of cheapo knockoffs. Then actually knowing how to use the software with it.
No, but I'm not a good person to ask. My two cars are on opposite extremes, one is simple and doesn't need anything beyond OBD2, and the other is too scary to mess with digitally.
My experience is J2534 support is sketchy and if you want to do the things you actually want to do you need a manufacturer approved device with an insane markup. Also the subscriptions are insanely expensive, not even close to reasonable and you need to be a company (at least you used to be with Ford last time I checked, but they accept the UK or Dutch royal residence as a valid company location so there is that...)
I agree that J2534 is sketchy. The standard isn't very good to start with, there's usually no matrix (ie x systems * y devices) conformance testing but instead just a brief QA step done at some compliance stage in a release process, and most manufacturers don't really want to support it (preferring their in-house dongles). So, a lot of dealer tools do non-standard stuff and a "conforming" J2534 cable doesn't actually work.
Many subscriptions are painful, yes - VW brands / ODIS for example are awful to try to get as an individual and annoying as an independent shop; I'm sure the fraction of independent shops who pirate it are quite high. It's funny you mention Ford though, as they are incredibly easy to buy from in my experience, although the login/licensing backend is frequently broken.
However, there's a good cottage industry of companies reverse engineering the compatibility issues back out, and for better or worse these companies are cloned almost immediately too. I recently did key programming on a newer Ford (where Forscan can't) using a $125 VXDiag cable which I could have bought cloned for $30 and a short-term FDRS subscription that cost $50.
What about using ForSCAN? It allows anyone with the software and a dongle to monitor and to update modules in the ECU AFAIK. I paid under $100 (can't remember) for a dongle and downloaded the free software and it is extremely handy working on one of my vehicles. The other two Fords I own are both pre-OBDII so there is less bullshit on them to begin with. Ford forums are full of owners who use ForSCAN to modify their vehicle's operation. Lots of hacks available.
Just do as /u/bigfatkitten suggests and get the service manuals when you purchase the vehicle.
ForSCAN is awesome but it's an orthogonal conversation since it's a reverse engineered diagnostic tool rather than a first-party one. If we expand the conversation to that space there are tons of options with varying capabilities depending on manufacturer, including also pirating the OEM tools directly. Also worth noting that ForSCAN also doesn't _quite_ support all common operations, for example Remote Keyless Entry enrollment on newer BCMs with push-to-start needs FDRS still.
Thanks for this explanation. I knew that ForSCAN was a RE tool (Russian guy?) and that there were others out there for multiple purposes on various product lines. I also knew that ForSCAN did not support customizing all OEM functions. I just wasn't bright enough to make the connection between this being a first party versus anybody's tool type of mods that one might make. I do most of my own auto maintenance so I use the tools that best facilitate the process and since I am only mechanically experienced and not an accredited tech I lean towards using third party tools, custom tools I cobble together, OEM manuals, etc. to guide all the work I do here in my driveway or shop.
What ever happened to take it to a dealer or authorized repair place to have it done? While I may be willing to take certain things apart that, the one thing in life I have resisted is any kind of monkeying with my car. There are certain things where I'm willing to accept that I took it apart and it no longer works because I bricked it, shorted something, or otherwise damaged it beyond my skill set to undo. My car is not one of them. However, I also do not want my car to be under the direct control of someone else that can decide I can no longer operate my car. If there's an update, I'll bring it in to have someone trained/responsible for that update.
My car needed another key. The stealership quoted me >$400 for it. I took it as a personal insult and did the research and ordered an OBD device and also discovered you can order replacement keys on aliexpress, and they'll even cut them for you with a good picture of your existing key. It was actually a fun project and very satisfying when I was able to successfully program and link the RFID chip to the ECU to start the engine.
May not be feasible with more locked-down modern cars which I wouldn't touch with a ten-foot pole, but I was able to fix it for about $150, not including my time of course. But I have the OBD device to use next time now as well.
I bought a kit off of amazon "simple key" that included a programmer and a key with rfid chip. I think about $80.
You plugged the standalone dongle in the OBD2 port, did a procedure and it would take a few minutes and you would get an "original" key.
(The programmer said it was then locked to that VIN)
They key blank provided needed to get cut (did it at home depot).
I could then get additional rfid blanks for $7 and cut and program them.
Once you had two original keys, you could do the "DIY programming" method to make keys 3 and up.
The DIY method was something like "insert key 1, wait 3 seconds, remove, insert key 2 wait 3 seconds remove, insert new key, wait for something, remove" and you would get key 3, 4 ...
There were similar but separate ford procedures for programming the buttons on fobs to lock/unlock doors, etc
My plan for the future is a trailbike, a tent and a shotgun.
But with regard to a car, I don't know. I'll just do the best I can when the time comes. I'm hopeful there'll be options available or where I can cut antennas or whatever.
Which I read this a month ago. Mazda dealer charged me $450 for mine. I figures the entire system is propietiary, so they can charge whatever they want.
Some people like messing with cars. They take the time to understand what's happening and learn the process and pitfalls. Hobbyists wiil never be as good as trained professionally but we can still get the job done. I went through the trouble to diagnose and replace a bad alternator on my civic after the battery started dying too fast. I did it cause it was fun.
The other reason i did it is because the dealership and other shops quoted me over 10 times the cost of parts, and I literally did not have the money to take them up should i have wanted to. Car maintenance is expensive, _especially_ at the dealership.
Some how, we've changed the direction of the conversation to something you lost vs a software update to the brains of the car. I'm guessing just to make the obvious point the dealership is not the cheapest place for repair.??? This isn't change the tire or get an oil change. This is something a consumer has deliberately done to prevent the manufacture from making an OTA software update. These are the kinds of changes that I want someone available right then and there to be responsible if the update borked the car.
Sure, but you have to realize that everyone isn't you. Many people are quite comfortable messing with the deep internals of their vehicle, to the point of changing code in the ECU. Others won't even change an air filter. Takes all kinds.
There's really no reason to be scared working on your car. I have no formal training and I have never paid a shop to fix my car in my 20 years of car ownership.
The mechanical parts of a car haven't changed much in the last 25 years, and are easy to understand just by watching a few YouTube videos.
The electronics have certainly gotten more complex, but if you can understand basic computer networking and low voltage electronics it's still quite simple.
If you are interested in learning how to fix your own car, there is a great guy who runs an auto repair business on YouTube and his tagline is: "Remember folks If I can do it, you can do it."
I'm pretty sure that the only diagnostic codes that an ECU is required to output are emissions-related codes. Since EVs have no emissions, I'm gonna guess they can force all diagnostics through the dealer if they really want to.
WiFi is, err, still OTA, although it does answer the eSIM question. I assume the truly concerned/paranoid wouldn't want to connect to WiFi either, since presumably telemetry / tracking metadata could be uploaded at that time too.
Anyone concerned about preventing telemetry from being uploaded would probably also be concerned about taking it to the dealer for an update, though. Because how do you know the dealer won't just do an update by turning the car's e-SIM back on, then turning it off before giving the car back to you? Which would then allow the car to upload all the stored telemetry you're concerned about. (Note: generic "you" meaning "the person concerned about telemetry", not bri3d in particular). Or, as long as they've connected a device to the car that can upload data, how do you know that that device won't also download stored data, which the dealership can then upload over their own WiFi?
I believe the truly concerned/paranoid will not want to take their car to the dealership for updates at all. Which would, IMHO, be a mistake: having known security holes in your car's software is more likely to lead to a privacy invasion (via getting your car hacked at some point) than letting the dealership get their hands on it for a few hours.
(I should note that all of this is theoretical for me: I drive a car that's old enough it doesn't have any software).
EDIT to add this P.S.: Actually, I can think of one category of people who would be concerned enough to turn off the car's ability to connect to the Internet, but feel fine about taking it to a dealer for updates. That would be people who want to turn off the car's Internet connectivity not because of privacy concerns, but because they don't want anyone to be able to disable the car (either via hacking or via "legitimate" means, i.e. the manufacturer does it) while they're driving. Such a person would care a lot about the car's Internet access being completely off while they are driving, but not care about it being turned on while it is at the dealership.
I read an article recently where there was a satellite outage and all porsche cars in the area would not start. They have some satellite based anti-theft system. (wonder what happens if your garage is shielded)
Personally, I wouldn't want this intrusive system (or telemetry).
This is the exact mindset that has amused me for years with computers. People use an OS with which they have a seriously hostile relationship. Why would you continue to pay a lot of money for a product you consider to be your adversary?
I kinda assume the dealer does this as part of any service they do. Either that, or they update some other way. My software notices went away when I had my service done, even though I’ve opted out of everything (and verified again after).
I believe the "advanced" LKAS on Rivian only works on highways and relies on an "up to date" geofencing database, so that's the first-order technical reason. And I'm sure they don't exactly prioritize fixing or altering that behavior for the other reason.
This is a safety issue. I don’t think there is a “fix” for offline lane assistance that they are sitting on do avoid people from disabling telemetry
The gen 1 system uses cameras primarily. It’s not awesome lidar or AI. It needs up to date road information.
I’ve been driving down I-5, a major interstate and had it turn off on me, presumably because I hit a dead spot, as conditions were fine and I5 is one of the most popular routes there is.
I’m fine with all of this. I prefer that it hand back control to me rather than make me another statistic like Tesla’s system.
I just can't imagine relying on something like that for my safety. I have worked on GPS and IoT solutions in related spaces and the comms networks aren't reliable, and actual control of a consumer vehicle is about the last thing I would ever want relying on it.
I think if I might be critical, the idea that the car graciously hands over control to you at a moment you are capable of catching might be a bit of a blind spot. The car could lose one of the signals it needs at an inopportune time and you would need a split second and correct emergency reaction to not spear off the road or collide with something. The physics of cars at highway speeds is awe inspiring, problems happen really, really fast.
Sure; I think that's a reasonable take too. I have no idea what their TTL requirements are or how frequently they update the ADAS database; if they're on the order of real-time, this seems like a complete technical constraint, if they're on a longer time horizon they might be able to offer manual offline databases.
I'm very curious at what level the restrictions operate. With every other manufacturer I've looked at, they're extremely coarse-grained; it's more like "is there a known long-time-horizon hazard in this area that is known to impair the system" than a "we mapped every lane and you need a database." I wonder if your I5 issue was a weeks or months-old construction area, for example. I haven't looked at Rivian much, though, and it could be totally different or extremely fine grained, there's no reason to suggest otherwise either.
I think it's a coarse-grained "this highway has been deemed non-anomalous enough to allow the vision systems to engage," not a fine-grained "we mapped every lane marking."
I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system.
The alternative is to run the printer in LAN mode (which OrcaSlicer has always supported) where the client connects natively over MQTT, but after Bambu added their cloud authentication, this requires putting the printer in Developer mode and severing the Cloud features.
reply