Recently posted comments

They can contribute to Samsung's existing implementation if they're serious about Linux.

What, really, do you need from a more complex build system? The majority of CMake's complexity comes from compiler and linker inconsistencies. Generated sources have solutions in Rust. Platform introspection can be done at the same time (and generate code for inclusion). Preprocessing to handle some intermediate language is fine too. I guess I'm missing what kinds of complexities are actually required that aren't possible with stock cargo.

One thing I know of is linker stuff (manifest files on Windows, custom ELF sections, library ID management on macOS, rpath/runpath shenanigans, linker scripts, packaging metadata, etc.). But, most of this can also be done as post-processing steps on the resulting artifacts anyways, so I don't think that is a fundamental lack in cargo itself.

That "relatively limited deployment" includes all photographers/videographers working with SD cards bigger than 32GB...

Well, it does, but you can only really use it for C ABI boundaries. A shared Rust library would also likely need recompiled/linked for updates due to a lack of ABI stability (in the sense of "updating the compiler can change this") of Rust calls and structure layouts.

Now that the exFAT specification is publicly available, I'd prefer using exFAT on external USB hard drives over NTFS, which is still closed (even though there are implementations for Linux).

I've never tried UDF on flash media or hard disks. How well is read/write access to UDF 2.5 or 2.6 filesystems supported by Linux, Windows 10, and MacOS? Is the Linux implementation robust? Does it transparently (through FS metadata) deal with using larger blocks than 512 bytes in order to support >2TB file system? I've seen some criticism of writeable UDF for not tolerating or recovering from forced unmounts (user disconnects or powers off drive) as well as NTFS and exFAT, but I don't know how accurate that is.

That's one of the items on the FFI working group's list to work on.

But there is some much potential here! Surely someone must have written nice wrapper scripts..

I agree with Greg. That's what reply is there for, to provide context. Also reply is such a basic functionality I'm really curious what kind of mail program does not support reply?

I doubt that anyone can come up with an alternative to reply, that is as easy to use and adopt by most/all developers.

Support for anything MUST be in-tree so it benefits from whole-tree changes automatically, shows up when a developer greps for “does anything use this function?”, etc.

1. Linux kernel doesn't guarantee API/ABI stability, so it's hard to design a universal Rust interface. At least it is almost impossible to make it work on all versions of Linux.
2. Many C language features have no corresponding Rust support. For example, it seems like impossible to construct a struct with bitfields.
But yes, I believe Rust is a promising language for kernel programming. Let's join forces to make this happen!

I don't see anything bad in a word that's used in the context of "easily" or "comfortably". But again, the bikeshed color must always be blue!

I wrote this, then I remembered Apache OpenOffice, which transcends to Dilbert-esque levels of suckage.

Even the most pathological F/OSS project is lightyears beyond the depressing suckage in the proprietary world.

None of that has any bearing on pathologic development/business processes that treat post-release maintenance as a four-letter word, nor does it help anyone who doesn't have access to complete corresponding source code to everything.