I wonder what the thieve does with the car after stealing. Will you always need that Nokia to start it or is there some kind if aftermarket for counterfeit keys?
Once it's been started you get it out of the area, then connect onto the OBD/diagnostics and run the OEM "all keys lost" procedure with cracked dealer software, which lets you program brand new keys into the system.
Then they end up in a container ship bound for West Africa.
The cost of these devices is out of the 'simple criminal' pricerange, but is a minimal expense to a crime ring that can export a boatload of stolen cars at a significant profit as these cars go for significant price premiums overseas.
I believe many of the cars are disassembled for parts and scrapped, most of its value needlessly destroyed. Some are exported to third world countries. Most thefts are not value-adding or preserving operations, literally doesn't pay(well).
Yep. A person I know had his Mercedes A45 AMG stolen, thanks to the tracker he was able to find it in the middle of a forest somewhere, went there with a police officer to find two guys in the middle of taking apart his car to pieces, their excuse was "officer we just found it like that". I don't know if they were able to pin the theft on them or not in the end, but the insurer ended up scrapping the car and paying for a new one because the main wiring loom was cut and Mercedes wanted an absurd amount of money for replacing it.
Apparently quite common with Teslas as well, there is no way you can sell a whole functional car to anyone(well, not in any developed country anyway), but stripping them to pieces and selling them elsewhere is relatively common.
Volvo took really aggressive steps basically making sure that every component in the car that has any kind of electronic chip inside it has to authenticate with the car's VIN or it won't work at all - really annoying for the 2nd hand parts market but hopefully also annoying for thieves.
> the main wiring loom was cut and Mercedes wanted an absurd amount of money for replacing it
Modern cars can contain over a mile of wire and some of the important wires are all laid out during early stages of manufacturing, making it difficult to get at them for maintenance. Some cars have better access than others, but if they were carelessly tearing the car down, there's a good chance you need to take off, rewire, and test every ECU in the car.
As far as I can find online, most repair shops ask for about $1700-$2500 just to replace the main wiring harness, including the cost of parts and labour. A luxury Mercedes will have more wires and more automated systems, so you'll easily end up in the higher end of that range.
With a car in such bad shape, I wouldn't want my company to try to repair that car either, not without a "this is a bad idea" surcharge anyway. You just know it'll never run as well as it used to and if you make it a standard practice, you know at least a portion of your customers will blame you for it because you put the "repaired" sticker on that car.
The profitability of the second hand used components market is a real problem. I don't want a future where you can't reuse the parts in a broken down car because of some hard-coded encryption key, but the theft situation is seriously out of hand. Sadly, I think the Volvo approach will be the norm in the future.
The loom is sandwiched between the two sheets that make up the floor, it is amazing that they offered to replace it at all because as far as I know there is no way of doing this without serious damage to the vehicle.
Well I don't know if they quoted a specific number, but basically the insurer said that after consulting with Mercedes they established the repair would cost more than 50% of the value of the car so they are declaring it total loss. Maybe Mercedes just told them lol no, can't do this guys.
Yes, that's likely exactly what happened. Volvo pioneered that trick, it makes good sense as long as everything works but if it ever breaks you're done. The big plus is obviously that the loom is very well protected but insulation tends to lose its plasticity over time and in case it gets pinched anywhere you're in trouble. The only feasible option is probably to route an alternative loom through the cabin somehow and to leave the old one in place but non-functional. Even that would be a pretty tall order because there is simply no way to do this without fairly structural changes to the car in order to make room for the new loom in such a way that it is protected from mechanical wear.
On classic cars you can do this sort of thing easily enough, there the chassis was made first and then the wiring loom was put in place but on these modern vehicles you're sore out of luck. And EVs will likely be worse still, what with all the HV DC cabling to motors, batteries and charge ports.
It's counter intuitive but some vehicles are worth more as parts anyways. The market for used vehicles is only willing to pay so much for a vehicle. The market for people who happen to need a part and will pay for it is much larger.
>Ian’s sleuthing found that mostly these cars are destined for export, sent via shipping container to places in Africa
"These cars" might specifically mean things like the RAV4 and that other cars more reliant on good roads have less of a market in "places in Africa".
There must be a noticible flow of parts (eg headlights) to patch up damage caused by the theft. Likely the car manufacturers know, but it's not in their interests to talk about it.
I guess the idea is more not to attract attention in case of a random search, rather than plausible deniability. The phone couldn't operate as a phone... (nor the speaker, as far as I understand it).
For the sake of testing, I just downloaded youtube-dl from Github [1]. I then tried to run the program, but it failed with:
/usr/bin/env: ‘python’: No such file or directory
Okay, the script can't deal with "python" vs "python3", whatever - I'll change the script's first line and move on. Next attempt:
$ youtube-dl https://www.youtube.com/watch?v=5pV8WFvSNYE
[youtube] 5pV8WFvSNYE: Downloading webpage
ERROR: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
I knew I would get this error because I got it two weeks ago already. And considering that the version number is `2021.12.17` that looks suspiciously close to a dead project, or at least for a project whose very description is "download videos from youtube.com or other video platforms".
Edit: I went through the repo and found that this bug has been reported two months ago [2]. I understand that the project is not dead in the sense that they are still looking at bugs, but if a major feature is not working for two months now then I think it's reasonable for people's faith in the project's future to be shaken.
> /usr/bin/env: ‘python’: No such file or directory
Your install is not configured properly. This is a googleable fix. (One example is to use `which python3` as part of your command https://stackoverflow.com/a/73610228)
Now in the first week of this issue I half recall the line in the code was pointed out, (possibly it's the one that's now being claimed as not a good fix still listed in the above) in one of the many people reporting the bug, with that being all that needed to be changed ... I didn't feel like at the time, grabbing the source, finding the offending line, and then compile it and besides there would probably be a working binary fix available for download that might have resolved a few other issues. I'd been following along every few days to a week to see there were any links to working forks compatible with older gear ...
Now my problem is I'm not running Win 13 or the latest linux distro but still I have the best up to date browser I've yet to find that runs on my old system ... and that link does nothing ... if I put the link in another it simply opens back at the top of the parent.
I figure I could copy every recent file one by one from the git repo and play at fooling with my own, but since someone commenting on this topic actually compiled the given source - only to land some old 2021 problem - sigh.
Now I have flipped though what I see in the above ... no fix info ... fucked and bye bye time. The next option touted as the fix sadly does not run on my old system, it could work with the online server but ... how long until ...
It is of course easier for people like me who are no longer or were ever competent programmers, let alone being well versed in python, to pick some other program - I've been told such as IDM will handle youtube antics fine as well as being compatible with older systems, so it may well be worthwhile to purchase a copy.
I can't follow this post very well. yt-dlp I think has this fixed. There is also ways to fix this without having to download youtube-dl file by file as you mention. (see this: https://stackoverflow.com/a/55562973 as a single example) there are are many easy ways to get around this issue. You can do it! Good luck.
Thanks. Unless you're inferring it works in interactive mode, I'll take it as a guide to rebuilding youtube-dl. Is there a link with all the updates in one pack or do I have to create a github account to gain access? Other than that, as an outline of a fix, the stackoverflow link as a solution seems vague to me.
There's a reply made to the current thread here which, to me anyhow, means the listed full source code at github has not been updated.
There are updated individual components - however it's been in the order of 16 years I've decompiled and adjusted and recompiled. It might be worth the effort ... if only youtube-dl was going to keep on sailing onwards. The nah moving to something else commentary informs me that sooner or later updates will probably get slower until such point people won't bother reporting issues - better for my old system to make the move sooner rather than later.
yt -dlp is probably relevant to the cheap online server I use with the latest python installed. I generally didn't use youtube-dl on it, unless the download was going to take some time and better to let the server accumulate it over a few hours. yt-dlp supposedly fixes the trick youtube used to try and discourage cli downloaders.
That depends on who "you" are.
Linux distros these days tend to ship modern python package with a python3 executable, no python executable. Many distros still support a python2 package, some install that as a python exeutable, some as a python2 executable.
iirc. homebrew on OSX installs python as a python3 executable, no python exeutable.
Hopefully no-one should support python v2 in 2023 ?
Fedora does the same. Must have been 3 or 4 years ago Python 2 was removed as a dependency from the core system packages and "python" started resolving to a Python 3 release.
I expect this has filtered down to RHEL9 now.
Multiple version are supported with "python2.7", "python3.9" etc. if a version older than the current default is required.
Expecting python3 to be available as 'python' means that _your_ install is broken (until the time when python3 re-implements all the syntax and semantics and stdlib of Python 2.7 so that code may run unmodified).
The I can't believe it's not youtube-dl quasi unofficial fork yt-dlp has a most recent stable release 2023.03.04 (last month).
Of the two one is keeping up with the month by month twists and turns of websites altering their video embed methodologies to defeat CLI rippers .. and the other one isn't.
There is much much more to the code base than simply youtube ripping, both can (in theory) also rip from (say) ABC Australia's iView, from the Royal Institute Christmas Lecture series, from redtube, etc (hundreds and hundreds of variations of websites).
That shim layer between the core ripping engine(s) and the manifold ways of embedding access to a stream is what is being kept current in yt-dlp releases (and -U updates).
Original most recent official youtube-dl (December 2021 release) can no longer find its update service.
A while ago youtube-dl broke and wasn't fixed. yt-dlp fixed the problem.
Granted, I haven't kept up on whether original youtube-dl eventually got around to getting its primary functionality to work. The several-month interregnum that definitely occurred seems like a good reason to consider it "dead".
It's been fixed but the new maintainer refuses to release a new version until someone manages to help him figure out how to get automated builds running (which seems to have been the problem for the past year and he refuses to just do a manual build so that youtube-dl at least works with YouTube).
Have you tried yt-dlp? I remember what made me switch. YouTube downloading didn't break, but became extremely slow when compared to my actual network speeds. YouTube seems to do something to fuck with the speeds every so often. yt-dlp is quick to hop on those issues.
It stopped being able to download videos from youtube. That's not the only functionality, but -- given the name of the software -- I'd say it should have been fixed. All the repo activity in the world won't balance out the inability to do the only thing you advertise that you can do.
youtube-dl only works for some people around the globe, as youtube is apparently running A/B testing. Yeah there's a sort of fix ... that's been tucked away at github by way of go nowhere link, but there's the given idea it's time to ditch the cheap computer or online server and try and get something else to run instead. I read that sort of sentiment as that yup it's probably dead and maybe time to move onto more expensive toys that programmers really give a fuck, well that year ... or just ignore youtube for the time being. It's sad because what I generally viewed on youtube was of no interest to the music industry.
Org is also just a file format with extensions available in VS Code, vim, sublime, and Atom. I've personally used the VS Code extension, I think it works just as well as the Markdown extension.
That is a much more challenging task - even if they had planned it from the get go. One of the reasons people gravitate to Emacs is that it is much easier to build integrated systems like Org mode.
The other barrier, of course, is that it doesn't really benefit existing Org mode users/developers.
I think stuff like this really comes down to getting used to and accepting.
I had the same views on code prettiers. I thought, aligning your code by hand makes you think about the structure. That you'd invest more time in making your code readable and thus it would be more readable.
When I first got to use prettier on a team and accepted it's value, the benefits I perceived were so vast, that my arguments seemed irrelevant in comparison.
Sure! I want prettier for types. So I don't have to manually type the obvious things. The IDEs are smart, but I haven't found one that would be that smart.
I'm wondering what do you mean by obvious things, do you have any example? TypeScript can infer types[0] even through context, and it's even a good practice to let TypeScript do that for you.
That is cool. Will try that. But the type information the IDE provides to me is sufficient even without TypeScript. So, back again to the question — is TypeScript worth it?
I had the same question initially. TypeScript is the way you configure intellisense. Some types can be inferred, but not all, and most of the typing I do is to _restrict_ what data can be used. TS gives you feedback anywhere you ask for it, and paired with IntelliJ I feel like I have superpowers.
Another point: You can create types for your API client programatically, meaning your front-end can be aware of exactly what types your backend is returning. This cannot be accomplished with intellisense.
Hoenstly, for production code, TS makes me sleep better. No matter how many tests you write, that one undefined object will get you at some point. TS helps to eliminate a complete set at compile time (as you know) and that's great!
Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win.
> Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win.
I have the same feeling regarding Haskell, Elm and Swift, the latter I program in 99% of the time. I really don't feel like I get the same sense of security from Typescript, to be honest. Maybe I'm not using it correctly? I tend to lean more towards OP's opinion. I would probably prefer something like Rescript, but haven't looked much into it.
Rescript and its standard library Belt are great. I have been using BuckleScript/ReasonML/Rescript since 2018. It gives better guarantees than TypeScript and has a stronger focus on the functional approach to problems. The only drawback is it has less documentation than TypeScript, and you will likely have to write bindings for JS libraries you want to use.
I agree Typescript doesn't give "if it compiles it works" but it does give "if it compiles there aren't totally noddy errors like typos". And it gives you a codebase that is understandable and maintainable which JavaScript does not.
Main thing that comes out of it is "focus". Focus starts to dissipate the larger the team. I don't think focus will guarantee you success (you could be focused on the wrong thing) but I don't think you can be successful without it.
I am interested in potential future RSS capabilities. Would you mind a chat about that? If so, please drop me an email, see profile.