:)

i don't suppose anyone's looked at extended ipd/ipdadm to apply more granularly than an entire zone?

err extending

In the past when talking with Seb he suggested doing that with flowadm.

And if I had thought about that, that'd honestly have been a better way to probably go.

ahh you mean adding the drop/delay/etc. as properties to a flow?

Yeah.

Because once you want to be more granular, that's probably the thing to specify it on.

yeah, that makes sense..

Not a very satisfying answer though.

i guess i need to look at the code and see how hard it'd be to do that :)

[illumos-gate] 16542 Document ACL_NORESOLVE flag for acl_totext -- Bill Sommerfeld <sommerfeld⊙ho>

Hi. I know nobody is likely using it any longer, but does anyone here have experience with Oracle Developer Studio compilrs on illumos (OpenIndiana)?

I was able to get it working great, and I even modified the binaries to also define `__unix__` and `__illumos__` like current illumos GCC and Clang does.

That needed a bit of binary patching, which was fun.

The problem I'm seeing is that I get all sorts of warnings from the header files with Lint, that don't happen in Solaris. Nothing chagnes even if I explicity set -errhdr to %none

Like dpaste.com/G6VPB6DCE.txt

And that odd library warning. Debug output looks like dpaste.com/6JTLCANZ4.txt

Everything else I've tested is working great (C, C++, Fortran, etc.)

jhj: illumos stopped shipping system lint libraries when we integrated illumos.org/issues/10361

you'd need to work out how to build your own against the illumos-gate sources.

Oh, I see.

I'll have to look into it.

Hello All

Will Solaris expire in the future?

it's not milk

Discontinue

everything ends eventually but there's no reason to believe that will happen to illumos (and related) any time soon.

No illumos. Will Oracle discontinue Solaris?

Solaris from Oracle has a support end of 2034 at the moment. This project is unrelated and we only hear the rumors that others hear too. In the illumos project works in oracle

*nobody in the illumos projects works on Solaris or inside of Oracle

Only Oracle can tell what Oracle will or will not do:)

It's its own Oracle

It is doubtful even oracle knows what they're going to do 6 months from now.

last I saw, they extended somewhat

you'd need your oracle support person to tell you more

probably make sure it's in writing, if they do

blood if you can :P

given that people are still running solaris 10 in production, that end data wont really mater much;)

I think they actually just bumped the end of days to 2037.

sommerfeld: On Linux, does

the lint libraries work by using some kind of generic POSIX prototypes?

I'm kind of upset that they have end of support for 6/2024 for Studio, and a "real" EOL for 6/27.

Doesn't look like that is going to be extended.

And it's getting a bit long in the tooth, especially C++ support, and dbx doesn't handle latest DWARF formats, yadda yadda.

Oracle doesn't seem to care too much about the developer tools.

horacle only cares about their main cash cow.

It would be awesome if they open-sourced the compilers and tools, but that'll never happen.

Anything that doesn't contribute *directly* to that is not going to get much love.

nomad, yeah.

Even if it contributes indirectly they won't care (until they find out that it does actually contribute.)

and they certainly don't care about the convenience of their developers. Useful tools? Who needs those?

We use other tooling of course (LLVM's sanitizers, Clang Analyzer, GCC Static Analyzer, Coverity, PVS-Studio, Cppcheck, Sonar, etc.)

But for C stuff through C11, Oracle Lint is nice, and it's found things uniquely, and we like it's type analysis stuff.

Meh, ignore me. I'm just a bitter ol' sysadmin, not a dev (bitter or otherwise).

Just tired of the enshitification.

And on x86_64, for raw benchmarks, it's not really that far behind the state of the art, like 20% or so really.

Considering it's not had major development since 2017, that's quite impressive.

Also, Oracle C does things differently (allowably differently). It's the only compiler I Know of that does bit-field stuff in a big-endian way, even on LE platforms.

And a host of other oddities that it's nice to have some diversity for, when testing.

But does horacle care about any of that?

jhj: lint libraries are built by lint, from *.ln input

nomad: I guess not.

the format is probably undocumented, but we happen to still have `lintdump` in usr/src/tools

the resulting format of the llib-libfoo files, that is

I like still like using discover, but msan works well enough to replace it now, and gcov/lcov/gcovr works equally well or better than uncover these days...

richlowe: Yeah, I just briefly looked at it, I'm not sure it's worth the effort to get that going again, especially since I can run Studio on Solaris and Linux.

jhj: I've never used the Studio tools on Linux

To develop Illumos, which programming language you must know?

largely C, though is some stuff in a few others

Not Rust?

nongeek: most of the code is in C. But there are bits in ksh, perl, python, awk, sed, a bit of C++, a sprinkling of assembler. some config is in xml.

some exciting m4

downstreams of illumos have extensive amounts of rust, we as yet have none

exciting is certainly one way to describe m4

jbk: usr/src/cmd/sgs/libelf/common/xlate64.m4

Downstreams?

Why Illumos doesn't use Rust?

we have perl generating assembler

nobody's written any code in it and asked illumos to

(see, among others, usr/src/common/crypto/sha2/amd64/sha512-x86_64.pl )

New OSes using it. I guess windows 11 and Linux uses it.

most of the code was written before there was a generally available rust compiler.

i'm guessing that came from openssl

jbk: yup.

Is it true C is not secure?

no, C can be just as secure as anything else... though a fair criticism is that it can be harder (sometimes much harder) to write secure code compared to other languages

C is very user friendly. It is just picky about who its friends are.

i mean, openbsd is probably a higher percentage of C (relative to their total code) than we do

err we are

and I don't think anyone would accuse them of not being secure :)

There is excellent tooling for C and C++ that you can prove formally (in the absolute mathematical sense) that absense of any bugs in your code.

Not just saying there aren't bugs, but proving that they can't exist.

well, by starting to validate your function domain and co-domain you can exclude quite a many problems;)

But doing this is really something that a) takes a very large amount of effort, and b) really needs to be done up-front. It can't really be applied retroactively to existing code that wasn't developed with sound formal verification and validation.

Tnx

I guess this falls into what jbk said in that "C can be just as secure as anything else", but it's just harder to do.

Oh he left. We scared him away.

Oh, well, in case any of you guys want to run Oracle Studio tools on illumos, but you want to have `__illumos__` and `__unix__` defined by the preprocessor like current illumos Clang and GCC do...

yeah, we can't really arrange for that.

I'm going to assume Oracle won't patch it for us

You can nop out the JMP here, change the `__linux` and `__linux__` below it both into just `__unix` (it won't complain if defined the same multiple times this way) and then you can turn `__gnu__linux__` into `__illumos__` quite easily. :)

You need to do it a few binaries, but it's code is always in the same spot.

That way it ends up defining `-D__unix -D__SVR4__ -D__svr4__ -D__SVR4 -D__sun -D__sun__ -D__SunOS -D__unix__ -D__unix -D__unix__ -D__illumos__`

richlowe: It's easy enough to do yourself. I know it's not really a supported compiler anyway.

Most distributions stopped shipping studio when we lost the legal right to use it. I've used it in a few commercial settings, but it wasn't a cheap licence

We have the legal right to a 12.1 that we can't actually use to build illumos (properly)

and the specific tarballs that _can_ build illumos, but I'm not sure we could ever redistribute

andyf: Hi Andy, yes, I remember I asked you about this a while back and you explained to me that Oracle did let you use that older version officially.

what we're not allowed to do, unfortunately, is patch the binaries

so that's why we deleted the support for building illumos, because we kinda had nothing else to do

I don't remember the specific wording, but my recollection was only that we could use that studio 12.1 under certain circumstances, and our circumstances changed.

I know from a couple of people that what -- what I assume is a tiny tiny group that's left -- have done with newer versions is very impressive, though.

(or at least, some lawyers recommended that omnios no longer ship it)

You could probably distribute patches and have people supply their own toolchains.

andyf: if they're your lawyers, listen to them.

Probably not worth it.

The current license for the GA release (no post-2017 patches) says it "provides perpetual no-cost license for production use and the development of commercial applications"...

... but the actual terms don't allow you to re-distribute the toolchain.

It does allow you to modify it, but only "as required by law for interoperability".

Anyway, they're no longer developing it as of last month, so I don't think Oracle is going to sue me for using it on current illumos :)

*next month

I'm a very low-risk kind of person, and have always felt that guessing where oracle would feel litigious is probably not good for me.

I'm probably going to see what a support contract costs for premier support, to see if I can grab the "last" version of it, before they kill the product.

However, it no longer even appears on the current price list (oracle.com/a/ocom/docs/corporate/pr…ng/technology-price-list-070617.pdf)

It's dead, Jim. :(

Well, "extended" support ends 2027.

I guess I'd have to call them, and get added to the ForceSales database again.