DocScrutinizer05 | I'd recommend sysv init, it's really the mother of init systems when it comes to learning how system startup works | 01:55 |
---|---|---|
DocScrutinizer05 | and, unlike systemd, sysvinit is deterministic usually | 01:58 |
gnarface | expert975: the best argument i have in favor of sysvinit is that i can help you with it. i can't say that for any of the other init systems. (and i'm not sure anyone at all can honestly say that for systemd) | 02:57 |
gnarface | sysvinit has some rough edges, and may be primitive by many modern standards, but from what you've already said in channel, that's going to glow like a star to you | 02:58 |
gnarface | the primary actually functional problems with sysvinit lower themselves to the level of minor annoyance once you're familiar with the basics of file naming and creating symlinks (skills that used to be taught in elementary school computing classes that have inexplicably fallen out of favor) | 03:00 |
gnarface | and with basic shell scripting skills, everything else pretty much obviates itself | 03:00 |
gnarface | (though that used to be true of the entire system at one point) | 03:01 |
gnarface | the issues you see with systemd having a sinister-seeming corporate influence that somehow mysteriously can't put their own shit back together with all the king's horses and all the king's men... well that's right on point too, and nobody will really disagree with you about that here, but soapbox about that in #debianfork so that this channel can be reserved for support purposes | 03:03 |
gnarface | (#debianfork is not owned by the Debian project, it is our official ranting channel) | 03:04 |
gnarface | oh, and yea, some stuff that depended on systemd *has* been actively crippled, you're right about that. it's not the end of the world though, volunteers have put a lot of it back together for Devuan anyway | 03:05 |
gnarface | some conspicuously popular projects still are under their thumb (*cough* Gnome *cough*) but you can easily find alternatives if you ask around here | 03:06 |
gnarface | Linux is like Monty Python and the Holy Grail's Black Knight | 03:10 |
onefang | You don't even have to deal with file naming and symlinks if you use the right tools. sysv-rc-conf is very handy. | 03:12 |
gnarface | yes, most people don't even have to touch them at all, even with tools | 03:13 |
gnarface | but it was originally intended to be edited by hand, and occasionally if you're doing something special you still might need to | 03:13 |
gnarface | (or if you make a mess and need to untangle it, it's easier to do that too) | 03:14 |
onefang | Or if you want to learn the guts of how it works. X-) | 03:14 |
onefang | Er that should have been - B-) | 03:15 |
gnarface | yea, sure if you just want to see what it's doing and how, it's great for that. very transparent | 03:17 |
tuxd3v | 'update-rc.d' do the job :) | 03:18 |
gnstaxo | Hello. Is devuan_ascii the right distro to download? | 05:37 |
gnstaxo | devuan_ascii_2.1_amd64_netinst.iso | 05:38 |
tuxd3v | gnstaxo, you can download it version 2.1 | 05:38 |
gnstaxo | is that file the main installer? | 05:39 |
tuxd3v | but now Devuan is already in beta mode for release 3.0( beowulf ), maybe it would be a better choice, since when released you are already there :) | 05:39 |
tuxd3v | https://mirror.leaseweb.com/devuan/devuan_beowulf/ | 05:40 |
tuxd3v | gnstaxo, what is your architecture? | 05:43 |
gnstaxo | 64bits | 05:44 |
tuxd3v | amd64? | 05:44 |
tuxd3v | it should be :) | 05:44 |
tuxd3v | you have there always 2 options | 05:45 |
tuxd3v | or i386( which I believe is compiled for i686.. ) | 05:45 |
tuxd3v | or amd64( for 64 bits ) | 05:45 |
gnstaxo | is devuan not a rolling release distro? | 05:50 |
tuxd3v | devuan is stable release cycle | 05:51 |
tuxd3v | but it also has development branchs | 05:52 |
tuxd3v | that work as rolling, like ceres repo | 05:52 |
tuxd3v | if you update to ceres you will be always with the last software | 05:52 |
gnstaxo | gtg. good night | 05:55 |
sedrosken | so, is there any way to get proper OpenCL support on AMD cards without installing the entire AMDGPU-PRO stack? I'd rather not use dkms if I don't have to | 05:55 |
sedrosken | I don't know what it is, but dkms has *never* worked for me | 05:56 |
tuxd3v | sedrosken, that will depend on your graphics card | 05:57 |
tuxd3v | :) | 05:57 |
tuxd3v | what is your graphics card? | 05:57 |
sedrosken | RX480 | 05:58 |
tuxd3v | and your cpu? | 05:59 |
sedrosken | Ryzen 5 1600 | 05:59 |
tuxd3v | ofcourse you can have OpenCL 2.0 without AMDGPU-PRO | 05:59 |
tuxd3v | :) | 06:00 |
sedrosken | the mesa OpenCL ICD doesn't work with anything, it comes up as a platform device but when anything tries to use it, be it Folding@Home or darktable's cltest, it declares it "not suitable" | 06:00 |
tuxd3v | you need installed amdgpu | 06:00 |
sedrosken | I'm using the AMDGPU kernel driver | 06:00 |
tuxd3v | your rx480 is supported by mainline linux kernel :) | 06:00 |
sedrosken | does that mean I have to install the "open" components of the AMDGPU-PRO stack? again, that relies on dkms, I'd rather not if I don't have to | 06:01 |
tuxd3v | AMDGPU( without the 'PRO' is opensource ) | 06:01 |
sedrosken | because then that entails getting dkms working, which is too much of a headache for me right now | 06:01 |
tuxd3v | My Idea would be something like amdgpu + rocm | 06:02 |
tuxd3v | byt yeah rocm I believe uses dkms | 06:02 |
sedrosken | maybe it's just that I'm using the backports kernel 5.4 | 06:04 |
tuxd3v | I believe that rocm installs everything and the process is automated | 06:06 |
tuxd3v | but it install a lot of things yeah.. | 06:06 |
tuxd3v | its has nothing todo with the 5.4 kernel I think | 06:07 |
systemdlete | gnarface: I searched for "debian 9 nvidia nv50 driver" and discovered https://wiki.debian.org/NvidiaGraphicsDrivers#Version_340.106_.28legacy_GPUs.29 | 15:25 |
systemdlete | I installed nvidia-legacy-340xx-driver and -- viola! I get 1280x1024 | 15:26 |
systemdlete | So probably all I ever really needed to do was install that package. | 15:27 |
systemdlete | And I got rid of that persistence package for nvidia. That cleaned up a lot of errors. | 15:27 |
systemdlete | awesome... :) | 15:30 |
tom__ | freedom | 23:45 |
tom__ | and justice | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!