SGI: Development

Maybe I do not understand libraries I thought that a library / shared object / dll was a small program that did a prescribed thing, like a black box - put xyz in, get lmnop out. Maybe you put in a Swahili word, can expect to receive a Tagalog word out the other end.

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 ?

Then if the people making this library make some major changes, then they name it 1.2 and any program using the library will have to be re-jiggered and rebuilt to use the new inputs and outputs. That makes sense.

But as far as I can see, within a major version, there is no reason for all this 1.1a, 1.1b, 1.1c, 1.1-2015-13a and so on crap. Why do we have all this junk ? Why does not a new and improved version of 1.1 just overwrite the old one ?

I can see 'why not' for a developer but for a user, this seems to just create excessive complexity. BRM thought that excessive complexity was fine as long as each part was equal to the task, but they proved themselves wrong. Several times.

I ask this because diegel's latest dist of libpng 1.2.52 mentions that he blanks out the versions_type in libtool to build the library. My first question was, why ? But the second question is now, why not ? Why not all the time ? Why do I even have applications looking for libfoozis.so.1.3.4.12.006a.19 ? Oh noes ! You only have libfoozis.so.1.3.4.12.006a.123f ! We can't use that !

This is wrong. Why not go into libtool for every library and set version_type to "none" ?

hamei wrote: Why not go into libtool for every library and set version_type to "none" ?

because that'd break everything that depends on or wants such a version

foetz wrote:

hamei wrote: Why not go into libtool for every library and set version_type to "none" ?

because that'd break everything that depends on or wants such a version

But why does anything want such a "version" ?

Where is my understanding off ?

Between major versions, agreed. They are different. But minor versions are supposed to be the same. Is it the case that these minor-versions checks are entirely to enable the diarrhea model of programming ? Release early, release often, release shit ? Because logic says, if libfoo-1 does xyz then all versions of libfoo-1 should do the same xyz. If they don't, then they should become libfoo-2. And if they don't work, they never should have existed in the first place and you definitely don't want them on your computer.

Therefore, minor version checks should not exist ... ??

hamei wrote:

foetz wrote:

hamei wrote: Why not go into libtool for every library and set version_type to "none" ?

because that'd break everything that depends on or wants such a version

But why does anything want such a "version" ?

well, different versions are different. if a program uses a feature that only came with a specific version (or higher usually) then it needs to check for it

foetz wrote: well, different versions are different. if a program uses a feature that only came with a specific version (or higher usually) then it needs to check for it

To my (somewhat) Germanic mind, this is bullshit.

Design the effing library to do a particular thing. Make it do that. Sure, as you find errors, fix them. Change minor version numbers to reflect that. But the library should do what it says it does.

If you want to add "features" to make it into something else, then give it a different version. A real version, not some incrementing mess of crap that's bound to cause chaos. Calling a giraffe a "horse ver 2.32" is stupid. A horse is a horse and a giraffe is a giraffe.

Mr Diegel Sir, how come you repressed the versioning in libpng ? I'm sure you had a reason ...

hamei wrote:

foetz wrote: well, different versions are different. if a program uses a feature that only came with a specific version (or higher usually) then it needs to check for it

To my (somewhat) Germanic mind, this is bullshit.

Design the effing library to do a particular thing. Make it do that. Sure, as you find errors, fix them. Change minor version numbers to reflect that. But the library should do what it says it does.

That's how it supposed to work. But in real world it simply doesn't. Even minor changes break programs, because for programmers will depend on the erroneous behavior. Microsoft solved it via Side-by-side assemblies .

GL1zdA wrote: That's how it supposed to work. But in real world it simply doesn't. Even minor changes break programs, because for programmers will depend on the erroneous behavior. Microsoft solved it via Side-by-side assemblies .

What would happen if the people supplying the dll's in question said, "This is the guaranteed behavior. If you depend on erroneous behavior, you are on your own and we arn't going to fix it. You can face the wrath of your customers alone when your software breaks, because we fully intend to tell them why the program broke."

And then stuck to their guns ...

Standards are good, if they are enforced, maybe ?

Time to grab a beer and read this:

https://en.wikipedia.org/wiki/Library_%28computing%29

jimmer wrote: Time to grab a beer and read this ...

This was pretty much my understanding ... you are not helping my mood :

"In computer science, a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked . This means that as long as a higher level program uses a library to make system calls, it does not need to be re-written to implement those system calls over and over again ."

"Since shared libraries on most systems do not change often ..."


Seems like a lot of these boys could use a little discipline ...

hamei wrote:

GL1zdA wrote: That's how it supposed to work. But in real world it simply doesn't. Even minor changes break programs, because for programmers will depend on the erroneous behavior. Microsoft solved it via Side-by-side assemblies .

What would happen if the people supplying the dll's in question said, "This is the guaranteed behavior. If you depend on erroneous behavior, you are on your own and we arn't going to fix it. You can face the wrath of your customers alone when your software breaks, because we fully intend to tell them why the program broke."

And then stuck to their guns ...

Standards are good, if they are enforced, maybe ?

And in the end the providers of the library will suffer. Imagine a client, whose program works on your OS with your library version A. You are providing the upgrade, which upgrades the library to version B. Now the clients program breaks, because you modified some of the libraries undocumented behavior. Who do you think will be blamed? MS learned it quickly with MSVCRT.DLL . Search Raymond Chen's blog for information about how important is backward compatibility for OS developers.

Is that your place of work (pic above). No wonder you're worried about using her CPU cycles. Actually I wouldn't mind using her cycles

GL1zdA wrote: And in the end the providers of the library will suffer. Imagine a client, whose program works on your OS with your library version A. You are providing the upgrade, which upgrades the library to version B. Now the clients program breaks, because you modified some of the libraries undocumented behavior. Who do you think will be blamed?

I disagree, and perhaps this illustrates a difference between people of the past and tomorrow's young whippersnappers.

In the early nineteenth century there were a gazillion railroads with a gazillion track gauges. This obviously impeded interaction between railroads, so they got together and developed a standard . Now any railcar could go on any railroad (with the exception of some isolated narrow gauge lines.) If a car builder sold a boxcar with a non-standard wheel width, the railroad did not "get the blame." If any company had been stupid enough to provide non-standard trucks, that company would have been quickly bankrupted by pissed-off customers. Not the railroad, which was adhering to the standards. The company which insisted on doing something in a non-compliant way.

What would happen if I started selling blenders that ran on 93 volts, 35 hz ac ? "Well, once upon a time in Bumfuck, Idaho, the electricity used that voltage and frequency ..." Yeah right. Good luck with that, Bunky.

What is the point of standards (standard practices, standard utiltities, standard languages, standard libraries) if people are free to ignore them ? Hell, we may as well re-invent the wheel three times a week ... which, come to think of it, is pretty much what Loonix does. Seems like people will put up with any old shit in software.

Devolution. The people of 1800 were smarter than the people of 2015

hamei wrote: Hell, we may as well re-invent the wheel three times a week ... which, come to think of it, is pretty much what Loonix does.

Hell, it's basically Lennart Poettering's entire reason for existing...

commodorejohn wrote: Hell, it's basically Lennart Poettering's entire reason for existing...

He-who-must-not-be-named

yetanother**ixuser wrote:

commodorejohn wrote: Hell, it's basically Lennart Poettering's entire reason for existing...

He-who-must-not-be-named

Jesus. I didn't know anything about all this, did ten minutes' research.

Not sure what to say .... All of them ..... is this what the world is like now ? These people are using up perfectly good oxygen.

hamei wrote:

yetanother**ixuser wrote:

commodorejohn wrote: Hell, it's basically Lennart Poettering's entire reason for existing...

He-who-must-not-be-named

Jesus. I didn't know anything about all this, did ten minutes' research.

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

hamei wrote:

GL1zdA wrote: And in the end the providers of the library will suffer. Imagine a client, whose program works on your OS with your library version A. You are providing the upgrade, which upgrades the library to version B. Now the clients program breaks, because you modified some of the libraries undocumented behavior. Who do you think will be blamed?

I disagree, and perhaps this illustrates a difference between people of the past and tomorrow's young whippersnappers.

In the early nineteenth century there were a gazillion railroads with a gazillion track gauges. This obviously impeded interaction between railroads, so they got together and developed a standard . Now any railcar could go on any railroad (with the exception of some isolated narrow gauge lines.) If a car builder sold a boxcar with a non-standard wheel width, the railroad did not "get the blame." If any company had been stupid enough to provide non-standard trucks, that company would have been quickly bankrupted by pissed-off customers. Not the railroad, which was adhering to the standards. The company which insisted on doing something in a non-compliant way.

The problem is, libraries are more complicated than tracks and railcars. People rarely get them right the first time they try, so the APIs/ABIs have to evolve.

hamei wrote: What would happen if I started selling blenders that ran on 93 volts, 35 hz ac ? "Well, once upon a time in Bumfuck, Idaho, the electricity used that voltage and frequency ..." Yeah right. Good luck with that, Bunky.

Well, then, you are expected to include at no extra cost a power supply that can provide that.

guardian452 wrote:

hamei wrote: What would happen if I started selling blenders that ran on 93 volts, 35 hz ac ? "Well, once upon a time in Bumfuck, Idaho, the electricity used that voltage and frequency ..." Yeah right. Good luck with that, Bunky.

Well, then, you are expected to include at no extra cost a power supply that can provide that.

That's pretty much what took Apollo 13 out of their mission plan...

I think Kevin Bacon pressed the wrong button