Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[gens]

It's not plug and play anymore; you can't replace libjpeg with something else without re-coding your software.
It's not plug and play anymore; you can't replace alsa with something else without re-coding your software.
It's not plug and play anymore; you can't replace cups with something else without re-coding your software.
It's not plug and play anymore; you can't replace freetype with something else without re-coding your software.

yes you can, check libjpeg-turbo
you can change the lib, so half of it (hole if you make a lib as wrapper)
yes you can
freetype is a... complicated subject, but you can

[gens]

check out

http://en.wikipedia.org/wiki/Linker_%28computing%29

or more precisely http://en.wikipedia.org/wiki/Relocation_table
that is a part of a modern http://en.wikipedia.org/wiki/Executa...inkable_Format file

hint "man readelf"

[Gusar]

yes you can, check libjpeg-turbo

libjpeg-turbo is explicitly written to be API compatible with regular libjpeg. But you can't substitute in some other jpeg library.

you can change the lib, so half of it (hole if you make a lib as wrapper)

But unless the lib is written to be API compatible with libasound, you'll need to rewrite your app for the interface this other lib is exposing.

yes you can

If your app is written to get info on available printers and such via CUPS, using something else will require rewriting your app.

freetype is a... complicated subject, but you can

How exactly?

check out

http://en.wikipedia.org/wiki/Linker_%28computing%29

or more precisely http://en.wikipedia.org/wiki/Relocation_table
that is a part of a modern http://en.wikipedia.org/wiki/Executa...inkable_Format file

hint "man readelf"

FFS, drop this stupid tone as if I don't know how software works. You can't just willy-nilly replace libraries unless they were written to be API compatible. For example libedit is API compatible with readline (there's a wrapper in libedit that maps readline's functions to libedit's), so you can use libedit with an app written for readline, but such examples are exceptions, not the norm.

[gens]

Alsa is in userspace as well, and applications willing to use it must explicitly link with alsa-lib, which means writing the necessary code to interface with it. And getting your app to play sound by other means requires rewriting your app. Well, there's abstractions (SDL, portaudio) and sound servers (pulseaudio), but several apps don't use them, they interface with alsa-lib directly.

alsa is in the kernel
only other thing there is an oss wrapper (oss is no more)

alsalib (libasound) itself checks the settings files like .asoundrc and loads modules that are normal .so files
it runs completely in the application that linked against it and does the above stuff when initialization func is called
it talks to the kernel via ioctl (i think theres a couple calls to set up virtual files when starting)

that is why alsa can not directly handle multiple sound formats at once and on the fly rerouting
(well it could in theory by coordinating via some shm or something, but that would involve trusting an app to have the correct library so you need a simple sound server (not PA))

[gens]

libjpeg-turbo is explicitly written to be API compatible with regular libjpeg. But you can't substitute in some other jpeg library.
But unless the lib is written to be API compatible with libasound, you'll need to rewrite your app for the interface this other lib is exposing.How exactly?

...

FFS, drop this stupid tone as if I don't know how software works.

wrapper, its for API's
not much brain in decoding a jpeg, most api's are similar
you call start/setup if it depends on a state
you call like "decode(ptr buff, ptr another_buff, flags_or_whatever)
you call end_yourself()

checkout SDL for a complete example or GLFW for a simpler one

...

i wasn't talking to you...

PS freetype is complicated 'cuz shaped text is not an exact science (even thou it is declared like that), the line widths can vary and such

[Gusar]

alsa is in the kernel
only other thing there is an oss wrapper (oss is no more)

alsalib (libasound) itself checks the settings files like .asoundrc and loads modules that are normal .so files
it runs completely in the application that linked against it and does the above stuff when initialization func is called
it talks to the kernel via ioctl (i think theres a couple calls to set up virtual files when starting)

that is why alsa can not directly handle multiple sound formats at once and on the fly rerouting
(well it could in theory by coordinating via some shm or something, but that would involve trusting an app to have the correct library so you need a simple sound server (not PA))

And again with the stupid tone. What makes you think I don't know all of this already? And what relevance does it have? Fact remains, unless you decide to use an abstraction framework or sound server in your app, you'll have code that directly interfaces with alsa-lib, and playing sound by some other method requires writing new code for your app.

wrapper, its for API's

How does a wrapper help when the app interfaces with libjpeg directly?

i wasn't talking to you...

This is a public forum, not a private conversation between two people.

[gens]

And again with the stupid tone. What makes you think I don't know all of this already? And what relevance does it have? Fact remains, unless you decide to use an abstraction framework or sound server in your app, you'll have code that directly interfaces with alsa-lib, and playing sound by some other method requires writing new code for your app.

how about you stop thinking i'm out to get you

alsalib, like i said, supports modules

one of them, and the best example here, is direct to file "routing"
meaning you dont even need alsa in the kernel to use alsa
it would not be hard to write a plugin to send sound over the network directly without a sound server or a compile time framework

[gens]

How does a wrapper help when the app interfaces with libjpeg directly?

This is a public forum, not a private conversation between two people.

there is no "libjpeg" server running
a library is an ELF file
elf is basically a header saying "theres this and that in this file"

for example you make a shared object like

//whatever goes here

open(*file_name, flags, what_goes) {
printf("file %s was opened\n", *file_name)
sys_open(*file_name, flags, what_goes)
}

and you run your program like
LD_PRELOAD="./haxed_open.so" program

hint: objdump -T /some/bin




on the other thing you stated "me", so next time use "us"

[Gusar]

how about you stop thinking i'm out to get you

What makes you think I think that? But you do write generic descriptions on how something works, as if I don't know these things already.

alsalib, like i said, supports modules

one of them, and the best example here, is direct to file "routing"
meaning you dont even need alsa in the kernel to use alsa
it would not be hard to write a plugin to send sound over the network directly without a sound server or a compile time framework

Again, what relevance does this have? The point is that you can't simply switch out libraries and app is using. How does describe the workings of alsa change this point?

[gens]

Again, what relevance does this have? The point is that you can't simply switch out libraries and app is using. How does describe the workings of alsa change this point?

you can, read last post
if you still are thinking about API, think about how you can make a wrapper for it instead