chrono VS illumos-gate

The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented).

For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See:

https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499

https://github.com/rust-lang/rust/issues/27970

https://github.com/rust-lang/rust/issues/90308

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.

I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.

[1] https://github.com/chronotope/chrono

[2] https://github.com/chronotope/chrono/issues/146#issuecomment...

[3] https://github.com/chronotope/chrono/issues/156

[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...

On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.

The example has been randomly taken from the [Chrono][https://github.com/chronotope/chrono/blob/main/src/offset/utc.rs] crate.

libc isn't "just a wrapper". Is a massive legacy codebase filled with hacks, UBs and bugs: https://github.com/chronotope/chrono/issues/499

Would love to have people test this, you can leave feedback here: https://github.com/chronotope/chrono/issues/674.

Security issues? I'm looking at the open issues, but haven't noticed any that seem to be security related (no security related labels either). What am I missing here?

It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]).

[0] https://github.com/illumos/illumos-gate

Nobody's paid to have it pass Open Group Unix Branding certification tests

https://www.opengroup.org/openbrand/register/

so it can't use the UNIX™ trade mark.

But it's got the AT&T Unix kernel & userland sources contained in it.

PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...

IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...

> it seems like this bug might actually date back to the very beginning of ZFS with Sun

Looks like you might be right about that. The oldest commit referenced in the fix [0] was from 2006[1], which was just months after Sun released ZFS.

[0] https://github.com/openzfs/zfs/pull/15571

[1] https://github.com/illumos/illumos-gate/commit/c543ec060d

It could be good for in memory stores / log-structured merged trees / other data store applications although it isn't used much now-days. I find them simpler to implement and understand than red-black trees -- although that's a matter of taste I suppose. They beat red-black trees in read-heavy loads (i.e. writes / updates are more costly for AVL trees than for Red-Black trees although they beat R-B trees for read-heavy loads). You can find another implementation in Illumos (an open source Unix operating system) available here: https://github.com/illumos/illumos-gate/blob/master/usr/src/...

It's high time that the Illumos developers patched https://github.com/illumos/illumos-gate/blob/master/usr/src/... and https://github.com/illumos/illumos-gate/blob/master/usr/src/... to just set the error flag and return, and made the #ifndef TIOCSTI path in https://github.com/illumos/illumos-gate/blob/master/usr/src/... the only path.

Because by the looks of https://github.com/illumos/illumos-gate/blob/7c478bd95313f5f... the C shell was fixed years ago.

People are still actively working on Illumos. The last change was yesterday morning.

* https://illumos.org

People are still actively working on MirBSD. There's a CVS commit account that can be followed on the FediVerse.

* http://www.mirbsd.org

It's DragonFly BSD, not Dragon BSD, and the irony of that is that you missed FreeBSD, which is of course still going.

* https://dragonflybsd.org

* https://freebsd.org

As is GhostBSD, which tracks FreeBSD.

* https://ghostbsd.org

HardenedBSD is still going. Shawn Webb regularly talks about it on the FediVerse.

* https://hardenedbsd.org

Its successor is still out there: Illumos. Though it seems to be mainly focused on backwards compatibility for existing custom applications as it still enforces things like an 8 character username limit.

> Since then, illumos has rewritten all those components

But apparently kept the same license?

>> Most of the existing code is licensed under the CDDL and we expect new code will generally be under this license as well.[0]

[0] https://github.com/illumos/illumos-gate