That is true. Rust makes it easy to overuse monomorphisation. There are tools like `cargo-bloat` that find these.
However, most complaints are about size of “Hello World”, which in Rust is due to libstd always having debug info (to be fixed soon), and panic handling code that includes backtrace printing (because print to stdout can fail).
Printing of backtrace is very bloaty, because it parses and decompresses debug info.
The homescreen engine has always been dodgy — it has different bugs than Safari app, so it seems to be a different version/fork of WebKit. It was always against their interest to support this feature too well, so it's probably old and full of tech debt.
I believe them when they say it would require a rewrite to work safely in a browser-agnostic way, but that sounds bizarrely like "complying with the law was too much work, so we chose not to".
Now they've made all App Store alternatives suck in one way or another, and fragmented between EU and non-EU markets. It's a total mess that just happens to make App Store with Apple's usual fees the best option.
It's incredibly convenient for Apple that there's overlap between safety features and anti-competive behaviors.
Every time somebody says "I don't want vendor lock-in", they flip it to "Oh, so you don't want safety?"
But these are often false dichotomies created by Apple. Reviewing and rejecting apps for fraud and malware is great, but Apple bundled that with rejecting apps for using the word "Android" and whatever other curation they want.
Having built-in first-party subscriptions UI is safe and convenient for users, but the mobile duopoly and their control of the platform lets them charge for it whatever they want. Apple implies that allowing other payment processors means going to a dodgy website that makes unsubscribing and refunds impossible, but that's a false dichotomy Apple has created. They could require integration with iOS's subscription management APIs to use alternative payment processors (they already support PayPal as a back-end).
And this is another case where it's incredibly convenient that opening up internal APIs without safeguards to 3rd parties would be unsafe, so they haven't done it. But this is a false dichotomy – they don't have to run 3rd party browsers unsandboxed, or allow any app create homescreen icons willy-nilly. Adding to home screen is already a user gesture through the Share sheet, mediated by the OS. Browsers must be sandboxed anyway, and webapps were already allowed to run full screen.
And this isn't lack of just any feature. Apple has argued for years that App Store isn't mandatory, because anybody can just make a web app instead. That was never quite true do to Safari's limitations, but now is just a farce.
And Apple has no end of people willing to carry their water on this. With the recent LastPass debacle you actually had John Gruber saying things like:
> Instead, the scam LassPass app tries to steer you to creating a “pro” account subscription for $2/month, $10/year, or a $50 lifetime purchase. Those are actually low prices for a scam app — a lot of scammy apps try to charge like $10/week.
(emphasis mine)
He also claims, without any way to know, that "it doesn't look like this was made to steal LastPass credentials".
The whole article is very much a "yeah it sucks and shouldn't happen, but this is no big deal, really, why are you getting all up in Apple's face about it?" vibe.
Rustup arch only adds support for static libraries (unliked objects), and craps out as soon as you try to build a binary.
Rust did not do the legwork that zig did to bundle libc and a working linker, and Cargo is exceptionally naive in its default configuration, so it won't even find a usable cross-linker on the system, nor even try the chronically-unfinished rustc-lld integration there is.
Depends how you define it. If you want fine-grained concurrency, in a large and complex program, then Rust can be easier.
Rust itself is not easy to learn, but once you overcome that, its thread-safety features are amazing, and can catch bugs that could otherwise be very difficult to track down. In Golang you're at risk of forgetting to use a mutex or atomic where necessary, or having some function mutate object you thought was immutable, and the race detector needs to catch such violations at run time, whereas Rust catches them at compile time.
Rust has libraries for multi-threaded jobs (like parallel iterators), while in Golang I see people making ad-hoc DIY versions of these with channels and goroutines, and the simple constructs don't always handle cases like cancellation or panics.
Go’s difficulty doesn’t come from being too hard to understand, but from being too simplistic to solve problems properly once.
Repetitive code creates more room for simple mistakes. When every case gets an ad-hoc solution it’s natural to cut corners, because it feels wasteful and too noisy to make every boilerplate copy look complicated by handling edge cases.
So you don’t have `parallel for`. Instead, each instance is a hand-rolled combo of channels that may or may not limit maximum concurrency, may not care to preserve order when items take different time to process, may not finish or report failure correctly when one of the tasks panics.
Additionally, goroutines don’t have any thread safety guarantees. Built-in types aren’t safe to share unsynchronized between goroutines, and the language is too basic to prevent accidental sharing or force immutability or synchronization. A too-easy language can put more burden on programmers.
DNSSEC struggles to justify its existence, because it's mostly useless without transport security, and for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC. This leaves only few scenarios where DNSSEC makes a difference.
The current Web's CAs system has obvious flaws, and periodic clown shows, but it gets just enough workarounds to maintain the status quo. DNSSEC would like to replace Web's CAs with its own (DANE), but that isn't a fundamental departure from trusting CAs, only a different arrangement of authorities.
> for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC
The Web PKI relies heavily on DNS, and thus without DNSSEC it's vulnerable to spoofing. Of course people like Thomas have worked very hard to get people not to enable DNSSEC, and so a great many domains can be spoofed. Are they? Maybe†. It's hard to tell, after all there would be no sign of a problem, everything looks fine, there's no validation step because you said you didn't want one...
† At a previous employer in 2019 I looked into this. Military intelligence definitely perform attacks on foreign country Internet infrastructure, but at that time they mostly seemed to rely on the fact that users don't use TLS and/or dismiss dialogs saying the certificates didn't match. The UX got better since, so I'd expect today they routinely ask a CA to issue for these unvalidatable domains once they control the packet flow.
DNS transaction spoofing is not, in fact, a common cause of domain hijacking; generally, when domains are stolen and have certs misissued, it's through registrar phishing. DNSSEC does not in fact solve a real problem for the WebPKI, which is why virtually none of the Internet's most sensitive WebPKI users (for instance, Google Mail) use it.
I've been out of that game for more than four years now, but I'd be astonished if it's less prevalent now than it was when I left. You seem very hung up on these famous brand names, I have no doubt that works out for your career, but in practical terms those aren't targets for such attacks. Too much by-catch.
It is, but as I understand it, it's all just phishing. I haven't talked to anybody at a CA (maybe excepting Nick here?) who has told me direct cache poisoning attacks on the DNS have been a thing for domain hijacking. Like, full-on BGP4 attacks are more common (in that they actually happen).
If he wants to correct me on this, he should be probably do so more clearly and less evasively? I'm being pretty specific and making claims that I think are pretty easy to falsify.
Assuming properly issued certificate, Web PKI on the browser<=>server side is quite well protected against DNS spoofing of all kinds, and this is where DNSSEC is pointless. Users don't need to have DNSSEC-supporting resolvers, and not supporting DNSSEC only improves reliability of their browsing.
CAs are deterred from misissuing by CA/B forum and CT logs. This is actually stronger than DNSSEC where browsers have no power to catch and punish malicious/incompetent CAs.
Web PKI is vulnerable to DNS spoofing when issuing domain-validated certificates, and this is kinda crapshoot. It is getting "patched" with things like querying from multiple vantage points, push for RPKI to make BGP attacks harder, and certificate transparency to catch spoofing after the fact. This is a weakness, but somehow TLS hasn't collapsed yet because of that.
DNSSEC doesn't have encryption, and does nothing for end-user privacy, so that's not even an alternative to DoH or DNSCurve.
The only thing it deems a potential privacy issue is possibility of enumeration of subdomains, which is security by obscurity for the domain owner, from a time before certificate transparency logs ruined that anyway.
> from a time before certificate transparency logs ruined that anyway.
Isn't it possible under WebPKI rules to get an intermediate cert for all of your subdomains so that only the intermediate cert needs to get logged in certificate transparency? Or at the very least, you could use a wildcard underneath the domain you own...
I don’t think CAB would prevent that kind of intermediate, but I don’t know of any CA that issues them. The domain set would need to be enforced with name constraints, which are notoriously buggy in a lot of validators.
But yes, a wildcard accomplishes the same thing, and I think that’s the route (almost?) everyone goes if a service’s subdomains really need to be kept out of a transparency log.
I was under the impression you could flag your domain to not be in cert transparency logs. Security through obscurity is generally considered a bad idea (to which I think exceptions or nuance exist), but the likelihood of dns names being burnt via other mechanisms (isps/‘security’ products and platforms logging dns requests and selling them being a reasonable assumption).
It doesn't, at all. NSEC3 is crackable like a 1990s password file, and several tools exist to do it. The "standard" solution to this is "whitelies" (RFC4470), which requires your DNSSEC server to be an online signer so it can generate chaff records; the supposedly upcoming solution is NSEC5, which fixes the broken cryptography in NSEC3.
I think in many cases you can. If you replace with compatible cells, you can keep the BMS. For some batteries there are reverse-engineered or alternative BMSes.
However, cells need careful soldering, and the BMS must be working properly to prevent overcharging and overheating. Mistakes can cause nasty and expensive fires, so it's not a DIY job for anybody.
The headline sounds like yet another anti-EV scare, but surprisingly the article actually explains this is a fuck-you quote, and the real repair cost can be a fraction of that.
Yup. Not uncommon to get a really high quote when someone really does not want to do the work. We had a florescent light in a utility room that my Bride wanted to replace with another light fixture. She called a contractor who quoted $2k labor to swap in her new hardware - a 20 minute job for an amateur like me. Another contractor had offered to install 3 new toilets for about $6K labor. These prices were so far out of expectations they were really saying we don't want to do these gigs... nicely. (or take your money if you don't know any better... hard to say which)
I once had a gig where I was told to go directly to the airport. They booked one of the nicest hotels, nicest flights, half way around the world and charged them a small fortune for me to show them they ate an Exception. Apparently our company had really tried to say no, and charged them an unholy amount of money... and they still said yes.
Welcome to the new pricing structure of contractors. I blame YouTube and Facebook groups that basically all congratulate themselves for figuring out "charge 3x more, thus making 6x profits, and just do 1/6th the work!"
These prices seem very consistent with BMW's pricing practices in general for all its vehicles. They get very cheap secondhand around the 6 year / 100000km mark in my country, as that's when bits start breaking and you may as well just buy a new one.
The urban folk knowledge I was told is that a) Germans love leasing cars, not buying them and b) if you salt the roads in winter, cars will rust sooner rather than later, and that's only something you can delay, not prevent.
Ergo (so the folk knowledge goes), their cars are engineered for a short-term market. Amazingly reliable and fun in the designed for lifetime, after that, it's in God's hands.
I have no idea how true that is, but it feels kinda truth adjacent, from my compassionate listening to owners of secondhand BMWs.
Oh, and apparently, there's a bit of a European car part cartel in my country, so spares are even more expensive than they already are.
I've never had to deal in urban folklore when owning Toyotas though.
Live in Central Europe. Most of the people we know either own their cars outright or take public transportation.
Many companies north of the border (Germany) offer company cars as an incentive, which iirc are leased, but these eventually hit the resale market as one year or CPO vehicles.
Most cars also have a fairly long anti-corrosion warranty.
That said, reliability issues were more a matter of 1. US style cost cutting (remember Daimler Chrysler?) 2. getting caught by surprise by the horse power wars of the naughts and early teens. Engines and associated parts were rushed to market without proper testing.
These issues have largely been reversed. Modern BMWs are almost/as reliable as Japanese manufacturers while MB is starting to close the gap.
Chrysler knew they were toast. They either had to be bought out, mortgage everything for massive capital investment (which is what Ford did), or eventually go under.
Meanwhile, Daimler executives wanted a way to get American compensation. A ‘merger’ that would turn them into an ‘American’ company was their preferred option.
Of course, the Chrysler executive team was eventually shown the exit, the company was run from Germany, and it turned out that Daimler’s leadership was making a number of other major mistakes (this is around the time when reliability went down hill, and it had nothing to do with Chrysler).
Since when are corrosion problems still a thing? Unless your car gets it's paint coat damaged in an accident, it's not going to rust at all these days.
Here in Wisconsin the frames usually rust apart and become unsafe to drive well before the drivetrain fails. My last car made it just shy of 200k before the strut mount rusted through the unibody.
Now that I coat everything underneath with Woolwax I'm seeing much less rust, but still something you have to stay on top of.
Corrosion is still a problem anywhere they salt the roads (i.e places it snows). Much less of a problem than in the past, but still an expected thing at a certain vehicle age.
Normal driving results in tiny rock chips over enough miles and all it takes is the tiniest chip for the corrosion to take hold. Super common above the rear wheel wells, at least in my area. Under body corrosion is pretty inevitable as well because it isn't painted, and even if it were it still takes a lot of abuse from road debris. Coating can help significantly (Fluid Film, Woolwax, etc) but you can't coat everything 100% so it still happens.
However companies should be prohibited to propose such quotes at all. they do it because they will earn more on selling a new car, meanwhile what they wipe their mouths with are ecology slogans
Doesn’t hurt to shop around. From my research the replacement costs varied from $20k to $40k for electric vehicle batteries repair quotes. For city driving you charge to 80% so the batteries last quite a while.
Charging network still is bad. Many stations are broken but appear working in what I have seen driving with a friend who has an EV or looking up station reviews.
They didn’t need to charge but wanted to because of little time at home or hotel.
However, most complaints are about size of “Hello World”, which in Rust is due to libstd always having debug info (to be fixed soon), and panic handling code that includes backtrace printing (because print to stdout can fail).
Printing of backtrace is very bloaty, because it parses and decompresses debug info.