matthewbauer

Looks like it is now. Must not be automatic tho.

Reply by Jason Wright:

https://marc.info/?l=openbsd-tech&m=129244045916861&w=2

I don't think these are all necessarily required. At least I would be very very surprised if both avr-libc, mingw, and go were needed.

It would almost certainly kill WASM

Found it: https://github.com/golang/go/issues/20803

This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?

Going from convicted criminal to celebrated on bank notes by the SAME government in less than 100 years is pretty notable!

It's certainly up to them if they want to rewrite everything in Rust. I'm just saying the net benefit just does not exist for stable software like librsvg or bzip2.

> Is there something intrinsic to Rust that would lead them to this error? (no, I think not).

There is nothing intrinsic to Rust that creates this kind of problem, besides it being a different language than the project was originally written in. I'm sure Go, Swift, Haskell, Java, or any other language (with the possible exception of C++) would have similar issues. No other language community is quite as arrogant as the Rust community though.

They do, but that doesn't mean the decision is wise. The point is you are creating more bugs than you could ever possible fix in this kind of refactor.

Rewriting stable software in Rust is a very bad idea. Especially in open source, where we don't have enough maintainers, it ends up hurting the ecosystem. A certain prominent GNOME maintainer has been trying this recently and breaking things along the way:

https://gitlab.gnome.org/GNOME/librsvg/issues/456

Apparently, GObject Introspection doesn't even work in Rust, yet it is expected to be a perfectly valid replacement:

https://github.com/gtk-rs/gir-files/issues/35

Please don't be like these people! Keep the stable software we have, and maybe write new software in Rust.

Perhaps the future of software isn't "rewrite everything in Rust", but instead we end up annotating existing C/C++ with borrow checking information. This would be similar to how there is a push in JavaScript to add TypeScript annotations everywhere. It gives you the flexibility of the existing language and ecosystem while still allowing you to use new techniques in programming languages.

If you want to be taken seriously, don't include these dumb images in your post.

But then you can't make changes to the app! You're stuck with a read-only copy.

This is a good rebuttal to the study:

https://twitter.com/jbenton/status/1142891539598852102

LaTeX + ORG mode is an easy way to get some literate programming features while also still using a real typesetting engine. You can reuse my setup here:

https://github.com/matthewbauer/resume

I would discourage libui… The bus factor is 1 right now. There is now guarantee it’s going to be around in a few years. Qt5 on the other hand has a large community around it.

I think a few distros still support all the way back to i486. Debian and Ubuntu only support i686 though. Too bad too because i586 CPUs were on the market as recently as 2015 (Intel Quark).

https://www.phoronix.com/scan.php?page=news_item&px=Debian-6...

It sounds like they expect everyone to use Snap for 32-bit binaries. This might make sense for very popular apps like Steam, but is bound to break for legacy binaries that won't have any Snaps available.

What's been missing here is the rationale for removing these libraries, though. Glibc, and most other base libraries still support 32-bit intel without any problems. The cost of Ubuntu providing them seems very low here. Since they even use APT still, I suspect they could even reuse the Debian repos for i386!

Does this mean macOS users get their Emojis back?

This is very confusing, but is standard naming convention for Debian/Ubuntu. Basically i386 means x86_32 and amd64 means x86_64. Why they can't use the latter is beyond me. True i386 doesn't even work with recent Linux kernel and Glibc. i386 in Debian-speak is actually i686.

They still use libgcc, ld.bfd, and libstdc++ though.

/sw isn't provided by Apple either, but they provide it so that Fink will work.

I don't think it's as easy as crouton. There's no chroot or user namespace equivalent for XNU.

It's interesting that /usr/X11 isn't in that list!

This doesn’t exactly shine well on mongo’s development practices. Why go through all of this trouble when you could use something that works well out of the box like CMake? Maybe they like wasting money.

This same thing is done anywhere semver is used or any other version range system. This includes python, rust, go, and many more.

You’re still vulnerable if you lock down dependencies during the period the malicious code is wild though. You have to actually audit your locked dependencies to consider yourself safe.

Dependency ranges mean package updates happen automatically. So a minor release could contain malicious code without anyone noticing. I still think semver is worthwhile even if it a little bit more vulnerable to this kind of attack.

Semver probably makes the problem worse though.

I don’t think it’s fair to single npm out here. The truth is any package manager that lets anyone publish package updates is vulnerable to this type of attack.