Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Gusar
    replied
    Originally posted by gens View Post
    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.

    Originally posted by gens View Post
    wrapper, its for API's
    How does a wrapper help when the app interfaces with libjpeg directly?

    Originally posted by gens View Post
    i wasn't talking to you...
    This is a public forum, not a private conversation between two people.
    Last edited by Gusar; 04-17-2014, 12:05 PM.

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    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
    Last edited by gens; 04-17-2014, 11:58 AM.

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    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))

    Leave a comment:


  • Gusar
    replied
    Originally posted by gens View Post
    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.

    Originally posted by gens View Post
    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.

    Originally posted by gens View Post
    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.

    Originally posted by gens View Post
    freetype is a... complicated subject, but you can
    How exactly?


    Originally posted by gens View Post
    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.

    Leave a comment:


  • gens
    replied
    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"

    Leave a comment:


  • gens
    replied
    Originally posted by TheBlackCat View Post
    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

    Leave a comment:


  • Gusar
    replied
    Originally posted by tpruzina View Post
    1. alsa is in kernel and even pulseaudio uses it by default
    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.

    Originally posted by tpruzina View Post
    2. cups is defacto standard print server, nobody uses anything else.
    Why is such a defacto standard ok in the printing scope, but not ok in the service management scope? It's silly to accept "the one true solution" in one area, but oppose it in another area.

    Originally posted by tpruzina View Post
    3. srsly, you can use whatever fonts you like and this is handled by libraries anyway so...
    If you want your app to display fonts, you need to interface with those libraries, so just like with alsa-lib, you need to write appropriate code. And you can't switch to something else than your chosen library (usually freetype/fontconfig) without rewriting your app.

    So TheBlackCat's argument is fully valid and a nice display of how silly gamer2k's argument was. So please kindly take back your claim about who the troll here is.

    Originally posted by tpruzina View Post
    there is no sw created by competent develope which should depend on systemd
    Yes, theoretically KDE could use a different service manager for their needs. But since systemd is there and is suitable for the task, they've decided to use it. And I'd say using the already existing (and proven to be working - SailfishOS on the Jolla phone uses systemd --user) solution rather than implementing your own is the more competent thing to do. Your insinuation about who is competent or not is quite condescending.
    Last edited by Gusar; 04-17-2014, 11:20 AM.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by TheBlackCat View Post
    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.
    This is the logic of not reinventing the wheel.

    1. alsa is in kernel and even pulseaudio uses it by default
    2. cups is defacto standard print server, nobody uses anything else.
    3. srsly, you can use whatever fonts you like and this is handled by libraries anyway so...

    Whole comment makes no sense (troll).

    If your sw has hard dependency on these, there is something wrong with your sw.
    Also, it's plug and play in a sense that that you can easily bundle needed libraries with your software (and users can easily replace them with their own system versions via LD_PRELOAD if they want to).

    Tho back to my original point, there is no sw created by competent develope which should depend on systemd (except things depening on udev that is bundled with systemd).

    Leave a comment:


  • doom_Oo7
    replied
    Originally posted by Nobu View Post
    I disagree, I think 'ls -lh | less' is just as useful, or moreso, depending on what your purpose is. Another one I like is 'find . --name foo* |grep -i bar', or even, 'find . |grep foo |grep bar'.

    You don't propose merging find into that tool too, do you?
    Well of course I do !
    Let's see :
    ls -lh <=> give current directory files information with details in an human-readable form (less is only a display medium, it could as well give the data as XML or JSON...)

    find . --name foo* | grep -i bar <=> give current hierarchy files whose name begins with foo and whose name contains a case-insensitive occurence of bar

    find . |grep foo |grep bar' <=> give curren hierarchy files whose name contains foo and whose name contains bar.

    I don't really see where the pattern doesn't apply. It would make for a nice human-without-training-useable command system.
    (sorry for small mistakes maybe, lack of cafeine <_<)

    Leave a comment:


  • Nobu
    replied
    Originally posted by doom_Oo7 View Post
    I disagree : both are useless if taken separately. And I don't want useless things on my computer
    I disagree, I think 'ls -lh | less' is just as useful, or moreso, depending on what your purpose is. Another one I like is 'find . --name foo* |grep -i bar', or even, 'find . |grep foo |grep bar'.

    You don't propose merging find into that tool too, do you?
    Last edited by Nobu; 04-16-2014, 08:30 PM.

    Leave a comment:

Working...
X