SGI: Development

uunix wrote: I think Kevin Bacon pressed the wrong button

Nah... How could he have?

He clicked the windows exit X.. there's 6 to pick from. Easy mistake.

That is one awesome dashboard though.

jimmer wrote: Well, now I guess you understand the context of my rant at viewtopic.php?f=8&t=16727998 a little better...

Yeah I was laughing before just because of my grief with gtk2 et al but I never thought that the cancer had spread to the entire Loonix organism. Took ten minutes at lunch to casually search Mr Pottering, holy shee-it. Pages and pages and pages of childish whining, bitching, and pointless trivial squabbling. I don't think I saw more than one or two remarks about the actual merits of systemd.

It's as if the software is now merely an excuse to act like three year olds.

I've never used systemd and never will, cuz I'm never gonna use Loonix. Ever. But smf works well on Solaris. Probably a lot of the bitching is because Mr Pottering's work is shit.

Personally, I think they are all barking up the wrong tree. IBM had it right in 1990. Server systems have one set of requirements, clients another. So split the operating system accordingly. Client Loonix, Server Loonix. Then everyone can get what they want/need without pissing off the other group of users.

But these guys - almost all of them - would rather bicker about "the license ! ooh, the license !" and multitudes of other extraneous crap, than actually solve the problem.

It's appalling. Even worse than I ever imagined.

Sorry to be late to the party.

hamei wrote: Within major versions they are supposed to be the same . If you have a library swahili-tagalog 1.1, and come out with an improved version 1.1a then it should do exactly the same thing but maybe with better spelling. So you should be able to replace 1.1 with 1.1a directly, is that not correct ?

No, not necessarily.

The major/minor versions of a library can mean two things:

• either the major/minor version of the software they are part of, which can be anything and only has a human meaning.
• or the major/minor version of the library interface embedded in the libfoo.so file (also known as the `soname').

What matters here, in order to get consumers of the library to keep working, is to take care of changing the major/minor versions only when needed, because keeping the existing tuple would actually break applications.

The usual rules, since the SunOS 4 days, are as simple as this:

• every time you add a new visible interface, you need to increment the minor version. This way, existing binaries linked against libfoo.so.42.0 will still run when linked against libfoo.so.42.1, and in fact the dynamic linker will prefer libfoo.so.42.1 over libfoo.so.42.0, but your new application using the new symbol will explicitely require libfoo.so.42.>=1 and will not run on a machine where you have not upgraded libfoo.so.42.0 to at least libfoo.so.42.1.
• every time you make an incompatible change to an existing interface (change the number of parameters of a function, change the layout of a public structure used by this function, remove a function), you need to increment the major version. This will prevent applications requiring libfoo.so.43.0 semantics to run with libfoo.so.42.* - they would be likely to dump core with this version.

Unfortunately, many shared library maintainers use the current project release as the soname, even if there are no interface changes, or, worse, even if there are interface changes requiring a major number change in a maintainance release. To be fair, most users don't understand this either, and getting angry ``why does your bollocks 4.38 release install libbollocks.so.72.0 and not libbollocks.so.4.38?'' is only funny the first two times.

In the `release early, release often' state of mind, interface changes will happen very often, and will theoretically require many different library versions. With a good packaging system able to remove orphaned libraries, this is bearable. The use of ELF symbol visibility, on ELF systems with modern toolchains, also help a lot, as this allows the visible interface to a library to be shrunk as much as possible.

Still, as long as software evolves, shared library version numbers will continue to evolve as well. And there is IMO nothing bad with this... as long as the versioning rules are understood and followed.