• 1 Post
  • 268 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle



  • Nobody intentionally creates vulnerabilities, but more complicated software is more error prone and therefore more likely to be vulnerable. Fast release cycles also get in the way of good testing. The most complicated piece of software on most phones is the web browser, and its complexity is imposed by the web and its advertisements, rather than by what the user wants or needs.

    IOS and Android face pretty much the same issues on the OS developer and phone manufacturer sides. Therefore, the IOS and Android worlds could both clean up their acts in about the same way if the incentives were right. That they don’t do so might be a bad situation that we have to cope with, but we shouldn’t pretend that it is a good situation.

    I wonder what apps require IOS 16 in some meaningful way. I know there is a situation with Android apps requiring OS upgrades unnecessarily.

    Why do companies like McDonalds want you to run an app anyway, instead of e.g. using a web page? There are a few sites or products where I currently give up the equivalent of a french-fry discount rather than run their stupid app. It’s just a minor annoyance so far, but it doesn’t make sense to me. Do those apps usuallly keep running the background so they can track you, or what?


  • Those security vulnerabililties are because of buggy old software, and updating the software in the old devices does as good a job of fixing the vulnerabilities as selling you a new device does. A significant e-waste tax on every new device, accompanied by credits for keeping old devices working, might help with that. Anyway, if it’s an app (rather than OS) vulnerability and you can’t fix it with an update because the new version of the app requires a new OS, that’s mostly likely an app that you don’t need to use. I’m getting by ok with F-droid apps instead of Play Store apps, for example.

    Best still would be to debug the software before shipping it, so it wouldn’t have those vulnerabilities in the first place. There are various forces that get in the way of that, but a significant one is that web development is now driven by delivering more advertising rather than useful information to the user.













  • If whatever they are doing has been working for stuff written in languages other than Rust, we have to ask what makes Rust special. Rust is a low level language, so its dependencies if anything should be simpler than most, with just a minimal shim between its runtime and the C world. Why does any production software have a version <= X constraint in any of its dependencies anyway? I can understand version >= X, but the other way implies that the API’s are unstable and you’re going to get tons of copies stuff around. I remember seeing that in Ruby at a time when Python was relatively free of it, but now Python has it too. Microsoft at least understood in the 1990s that you can’t go around breaking stuff like that.

    No it’s not all C99. I’m using Calibre (written in Python), Pandoc (written in Haskell), GCC (written in C, C++, and Ada), and who knows what else. All of these are complex applications with many dependencies. Eclipse (written in Java) is also in Debian though I don’t use it. Bcachefs though is apparently just special.

    Joe Armstrong (inventor of Erlang) said of OOP, “you wanted a banana but what you got was a gorilla holding the banana, and the entire jungle”. Rust begins to sound like that too. It might not be inherent in the language, but it looks like the way the community thinks.

    I also still don’t understand why the Bcachefs userspace stuff is written in Rust. I can understand about the kernel part, but the concept of a low level language is manual resource management that a HLL handles for you automatically. Writing the userspace in a LLL seems like more pain for unclear gain. Are there intense performance or memory constraints or what?

    Actually I see now that kernel part of Bcachefs is also considered unstable, so maybe the whole thing is not yet ready for production.



  • Talks about different developer styles, slightly interesting and not too long winded I guess, but not much about the actual situation.

    I think this is still not such a great look for Rust. I had expected interfacing Rust to C to present fewer problems than it seems to. I had hoped the Rust compiler could produce object code with almost no runtime dependencies, the way C compilers can. So integrating Rust code into the kernel should be fairly painless from the C side, if things were as one would hope.

    It does sound to me in the earlier post that there was some toxicity going on. Maybe it had something to do with the context being a DRM driver.

    I looked at a few Rust tutorials but they seemed to take forever to get to any interesting parts. I will keep looking.