Announcement

Collapse
No announcement yet.

Solus Releases Linux Driver Management 1.0

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

  • profoundWHALE
    replied
    Originally posted by ikey_solus View Post

    ...? We have VirtualBox, Qemu, various spice bits, GNOME Boxes, virt-manager on the VM front alone. On the VNC front there is Vinagre,
    gtk-vnc, etc. Search for rdp + vnc in the repos.
    I have had issue after issue when trying to use these. Some of them are (or were) crippled by a lack of libraries or some sort of additional software to do basic functions, like, resize the virtual drive, and allocate more memory.

    Additionally, despite my system saying that gtk-vnc and Vinagre as being installed, there is no way to actually use them. In the commandline, it's as if the programs don't even exist. I've been using Solus as my primary Linux machine for about a year now (through multiple fresh installs) and my issues have stayed a constant.
    Last edited by profoundWHALE; 03 February 2018, 06:17 PM.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by monraaf View Post

    Yes, they do. Heck, it's even part of the RPM spec:

    > https://www.suse.com/documentation/s...tml#sec.system
    I was talking about Ubuntu (which you mentioned first), not SuSe.

    But it doesn't matter what SuSe does 'cause it's all part of RPM, as you said. Linux Driver Management, on the other hand, is distro-agnostic. It already runs on CentOS, for example.
    Last edited by Vistaus; 30 January 2018, 08:01 AM.

    Leave a comment:


  • Espionage724
    replied
    Originally posted by ikey_solus View Post

    Yay, conspiracy theories :P. We constantly provided details on the X.Org update, and this was eventually tracked down to a latent patch. The reasoning for folks **requiring** X.Org 1.19 was completely invalid, it doesn't magically fix tearing on any known system, and wasn't a priority (Do understand I have multiple test devices and 2 Optimus laptops)
    I was referring to the comment chain at https://www.reddit.com/r/SolusProjec...ember/dqcwecp/

    Optimus and Prime Sync requires Xorg 1.19, and from what I've seen personally, it does fix screen tearing. But really I was more interested in the other minor fixes that came with 1.19 and modesetting.

    Originally posted by ikey_solus View Post
    We killed wine-staging because in general more folks wanted an up to date WINE with cherry picks of wanted features, thus we moved to RCs and quickly adopt new stable releases (i.e. we're on wine 3.0) but with the D3D9 support from staging.
    https://dev.solus-project.com/T700

    People either want staging or they don't.
    That's the comment I was referring to; I looked around for discussion prior to that and couldn't find anything. Even posted a forum post asking for more feedback here a while back: https://solus-project.com/forums/viewtopic.php?t=2774

    It's not that important now that regular Wine supports CSMT, but prior to that, Wine without CSMT was pretty much useless to me (I played a few games that need CSMT for performance), and the switch from Staging to Regular was kind of unexpected.
    Last edited by Espionage724; 30 January 2018, 01:44 AM.

    Leave a comment:


  • boxie
    replied
    Originally posted by pal666 View Post
    <snip>
    Thanks for taking the time to answer my questions, very helpful!

    Leave a comment:


  • Gibb
    replied
    Originally posted by monraaf View Post

    It constantly blows my mind why Solus never bothers to make any research before boasting they have invented something new.
    It constantly blows my mind that some people think that their favorite distro is the anwser to everything :-P

    They are not claiming any inventions here, they are just taking another approach to problem they have to tackle.

    As I understand it, Solus tries to be independent from other distros/repositories, so although they can use existing software or solutions to package management, they decided not to, which is their right. As a bonus, they are producing and sharing other solutions/approaches with the rest of the Linux world, for free.

    TL;DR don't be so hateful, spread the linux love!

    Leave a comment:


  • pal666
    replied
    Originally posted by boxie View Post
    ok I have questions - Would a RPM packages for libratbag / piper would be auto installed when plugging in a supported gaming mouse?
    it depends on package metadata, i don't have hardware to check
    Originally posted by boxie View Post
    or does the package manager show "hey, you can install these things to make the most of your new hardware".
    it depends on implementation. package manager knows which package provides certain dependency, so it can either install this dependency or tell you which package to install. it is invoked from udev, so writer of udev hook controls behavior.
    Originally posted by boxie View Post
    how does it handle the scenario where for example you have a gaming mouse covered by more than 1 piece of config software?
    it handles standard dependency resolution. more than one piece should form dependency tree. hardware requires some string, some package has to provide this string, everything else is business as usual
    Originally posted by boxie View Post
    as someone who does not know much about RPMs (i am assuming lots has changed over the last 20 years since using them), is this information fully/partially populated? is it used?
    obviously it depends on distro(on package author). as i said printer drivers in fedora were installed automatically many years ago. (mayby automatically in the sense of gui dialog with ok/cancel buttons, i don't remember details)
    Last edited by pal666; 29 January 2018, 09:34 AM.

    Leave a comment:


  • RealNC
    replied
    I remember when Solus first appeared, I was thinking to myself "yeah, yeah, another smart-ass who thinks can do better than all the other gazillion distros."

    Now I'm slowly realizing that this smart-ass actually does better than all the other gazillion distros...

    And this is coming from a Gentoo guy, even (elitism is over 9000.)
    Last edited by RealNC; 29 January 2018, 04:47 AM.

    Leave a comment:


  • ikey_solus
    replied
    Originally posted by kalin View Post

    Thanks for your effort. I really appreciate it. I just have questions. What is the reason to use glib and c language ? From what I can see You really prefer c over c++ for your tools.
    Is that caused by reason or just You feel more comfortable with c
    No worries I actually try to avoid glib where possible and keep to "pure C". At minimum I'll go for C99 but I'm pushing for C11 where possible these days. I'll use GLib for projects where automatic bindings are required, like for LDM, or in projects bound to the toolkit (GTK projects like Brisk and Budgie 10). For me I knew C first and C makes sense to me. C++ has a tendency to vastly over complicate simple concepts. Typically most of my projects now are low level systems (lower than LDM) - and require sane ABI, and need to be clean.

    One thing that GLib typically sucks at is being hygienic with memory. As a result I actually ripped out all uses of GIO in LDM given that it was implicitly leaking file descriptors for dbus (and associated memory) because "convenience". With a little bit of fiddling - you can get the same result, in less lines of code, and not leak, using a purer C/POSIX approach. I think for me C just works with the way that I think. You have less paints and brushes so arriving at a portrait is that much simpler, whilst keeping true to your initial aims. With C++ it feels a bit like having an army of advisors telling you about all the latest brushes and tones of paint, and you arrive at the only eventuality: abstract art. (Yes, I'm sad enough to make puns through metaphors.)

    For me I guess I'm a bit of a control freak when it comes to code, and I have my own style when it comes to C. I'm a valgrind addict, and will never recover. I like to know exactly when and where my memory is being used, and severely dislike leaking or unnecessary allocations. If I need ADTs then rolling a list or map isn't exactly difficult (and I have a couple of libraries around for this purpose, `libuf` and my older `libnica` for clean long running C programs)

    For people who are able to always use and enjoy C++, I say stick with it, and fair play. It just doesn't work with me personally, and I rarely enjoy it. Obviously, I have to bite that bullet for Budgie 11, but I can keep myself sane by hacking on some of my other C projects :')

    Leave a comment:


  • andrebrait
    replied
    Ikey's responses on their own would already make topics about Solus worth reading.

    Leave a comment:


  • ikey_solus
    replied
    Originally posted by Espionage724 View Post

    Solus was my distro of choice for a while, but I had two main gripes with it.

    It took forever for Xorg 1.19 to be included in the default repos. According to a post, a developer had a problem with it on a multi-GPU laptop, but also said they didn't look into it any further than that and provided no further details aside from it wouldn't boot. I've used a few AMD/AMD and Intel/NVIDIA laptops with Xorg 1.19 for months without issue, so I can't really think what the problem could be. But in any case, I think Solus has Xorg 1.19 as of last month...

    There's also no Wine Staging in default repos (it was there, but for some reason it was switched back to regular Wine abruptly; this was back before regular Wine had CSMT). And due to their policies, both regular Wine and Staging couldn't exist in the default repos. Iirc, the change was said to be because of users complaining that Staging had more bugs than regular, but I couldn't find any posts like that at the time.
    Yay, conspiracy theories :P. We constantly provided details on the X.Org update, and this was eventually tracked down to a latent patch. The reasoning for folks **requiring** X.Org 1.19 was completely invalid, it doesn't magically fix tearing on any known system, and wasn't a priority (Do understand I have multiple test devices and 2 Optimus laptops) We killed wine-staging because in general more folks wanted an up to date WINE with cherry picks of wanted features, thus we moved to RCs and quickly adopt new stable releases (i.e. we're on wine 3.0) but with the D3D9 support from staging.

    Leave a comment:

Working...
X