| tuxd3v | hello, is there any possibility that gnu compiler 8.3 comes to ascii i386 os? | 02:04 |
|---|---|---|
| tuxd3v | I need to install Cuda toolkit | 02:05 |
| tuxd3v | and it complais about 6.3.. | 02:05 |
| gnarface | tuxd3v: 0 possibility | 02:17 |
| gnarface | as a general rule, Debian doesn't do major version updates to stable/oldstable | 02:19 |
| gnarface | i see 8.3 is in beowulf though | 02:19 |
| tuxd3v | gnarface, yeah, but it would be nice to have them in ascii-backports, don't you think? :) | 02:36 |
| tuxd3v | its a mission to install cuda toolkit, in a machine with 2 diferent vendors graphics, in which both need libGL.so.. | 02:37 |
| tuxd3v | the gcc problem was surpassed easilly, now I need to do some black magic to have both, mesa-glx, and at same time nvidia-glx.. | 02:38 |
| gnarface | i don't think it's ever coming to backports, either. it probably needs a newer glibc or something | 02:41 |
| gnarface | i think they only added it to beowulf recently | 02:42 |
| gnarface | you can try backporting it yourself, but as i've said before - by the time you get down to backporting all the dependencies, and those include core system components like glibc, usually you might as well have just upgraded to the next release by then | 02:43 |
| tuxd3v | a bin-utils it need for sure, because of ls, ar, ar, and yeah a lot of other things are related.. | 02:44 |
| tuxd3v | but those packages could be in ascii-backports, it would be very nice to have them in i386 | 02:45 |
| tuxd3v | My opinion is that a i686 makes more sense than i386, but I don't know how i386 was created.. it can have features from i686, i don't know.. | 02:46 |
| tuxd3v | I am saying this because i feel that i386 is a lot less memory contrained than amd64 | 02:47 |
| tuxd3v | I for instance are comming from amd64 to i386, due to 4GB memory contraints.. | 02:47 |
| tuxd3v | and when I installed nvidia drivers after reboot, my machine consumes already around 450MB | 02:48 |
| tuxd3v | yeah, having dual hraphics make me suffer a bit, maybe the motif for migration, doesn't exist after all, since I get similar cold boot Ram usage.. | 02:49 |
| tuxd3v | motif -> reason | 02:50 |
| onefang | In general running 32 bit software uses less memory than 64 bit software, coz the memory pointers are half the size, and there might be a lot of memory pointers, so it adds up. | 02:51 |
| onefang | And then moving smaller amounts of memory to and from the CPU means tings might run a little faster as well. | 02:52 |
| tuxd3v | yeah, and I notice that, but after install nvidia drivers..I see that ~200MB are consumed onde by it.. so long story short 'maybe the migration to beowulf is not so hungry in 386..' | 02:53 |
| GyrosGeier | no | 02:53 |
| GyrosGeier | x86 32-bit does not have PC-relative addressing modes | 02:53 |
| tuxd3v | onde by -> only by | 02:53 |
| GyrosGeier | emulating these eats up any performance gains you get from the smaller pointers | 02:54 |
| GyrosGeier | the only place where you don't need PC-relative addressing is statically linked programs | 02:54 |
| tuxd3v | GyrosGeier, it could be true at least at some extent, but i386 code density relies less in simd intructions than amd64 | 02:54 |
| tuxd3v | and simd instructions duplicates the amout of registers at each iteration | 02:55 |
| GyrosGeier | simd instructions are unaffected by pointer size | 02:56 |
| tuxd3v | i386 has less simd intructions, ofcourse the ones it has are not so powerfull, but hey.. they also consume less memory than the amd64 counterparts.. | 02:56 |
| GyrosGeier | you have wider SIMD instructions that have longer opcodes, but do more work at once | 02:56 |
| tuxd3v | GyrosGeier, ofcourse they are, but the point is not about pointers here, but about the amount of registers you will be using when simd is in place | 02:57 |
| tuxd3v | remember that each process will the schedules again | 02:57 |
| GyrosGeier | that is not a relevant performance impact | 02:57 |
| tuxd3v | preemptive or not, it will have to save its context, each time it goes of cpu | 02:57 |
| tuxd3v | and they ofcourse are saved to ram memory | 02:57 |
| tuxd3v | that is not performance, that I am talking about | 02:58 |
| tuxd3v | I am talking about code density/Ram usage | 02:58 |
| GyrosGeier | and even then, SIMD registers are saved lazily | 02:58 |
| tuxd3v | humm | 02:58 |
| GyrosGeier | only when actually switching to a different task and if they were actually used | 02:58 |
| tuxd3v | yes, but the thing is.. | 02:59 |
| GyrosGeier | the kernel doesn't use MMX/SSE/AVX registers | 02:59 |
| GyrosGeier | so taking the timer interrupt is cheap | 02:59 |
| tuxd3v | the userpace uses | 02:59 |
| tuxd3v | and you now, when simd comes in place at each iteration it duplicates the amount of registers.. | 03:00 |
| tuxd3v | ofcourse, its faster! | 03:00 |
| tuxd3v | but ofcourse it uses more memory too | 03:00 |
| GyrosGeier | and tasks initially start out with SIMD support disabled, so the first SIMD instruction traps, then the kernel sets a flag to actually save and restore the registers | 03:00 |
| tuxd3v | so code density in i386 is better than amd64 | 03:00 |
| GyrosGeier | no | 03:00 |
| tuxd3v | simd starts disabled because simd is like a plague | 03:01 |
| tuxd3v | it consumes tons of power | 03:01 |
| GyrosGeier | no, power management is automatic | 03:01 |
| GyrosGeier | the CPU would use the same if it wasn't disabled | 03:01 |
| GyrosGeier | that is just to get the lazy switching | 03:02 |
| onefang | I said "in general", and should have added "if in doubt, benchmark". No need to get into nitty gritty details of a specific CPU architecture here, there are better places for that. | 03:02 |
| tuxd3v | its exactly because of that they are disabled, and when a program requires simd a exception is raized and the kernel activates them | 03:02 |
| GyrosGeier | the memory to store the registers is also always reserved | 03:02 |
| GyrosGeier | not using them doesn't save anything | 03:03 |
| tuxd3v | yes, but i386 usesa lot less registers :) | 03:03 |
| GyrosGeier | yes | 03:03 |
| tuxd3v | so a lot less memory is reserved.. | 03:03 |
| GyrosGeier | which degrades code density | 03:03 |
| GyrosGeier | i386 always spills registers to the stack | 03:03 |
| tuxd3v | with simd at some extent it could be | 03:03 |
| DarwinElf | if a package I'm rebuilding needs debhelper 12, what can I do? Debian 2 has debhelper 10... | 03:03 |
| GyrosGeier | DarwinElf, there should be a backport of debhelper | 03:04 |
| GyrosGeier | also, that shouldn't have too many dependencies | 03:04 |
| onefang | Debian 2? | 03:04 |
| DarwinElf | oops, Devuan 2 | 03:04 |
| DarwinElf | i haven't used backports yet... | 03:04 |
| GyrosGeier | DarwinElf, also, I recommend pbuilder for compiling packages | 03:05 |
| DarwinElf | i'm not compiling more than one, so at this point I just need to learn how to install a backport on Devuan... | 03:06 |
| GyrosGeier | still a good idea to use pbuilder -- that way, you don't need to install anything on your real machine | 03:07 |
| DarwinElf | well, I will need to install it | 03:07 |
| GyrosGeier | true | 03:07 |
| GyrosGeier | but you don't need any build dependencies | 03:07 |
| DarwinElf | actually I did | 03:08 |
| GyrosGeier | and you can often do your own backports | 03:08 |
| GyrosGeier | pbuilder is like "here's a source package, please set up a chroot, install all the builddeps inside, compile the package and give me the result" | 03:08 |
| GyrosGeier | all in one command | 03:08 |
| DarwinElf | i don't really want to do that until I've done it myself without any tools | 03:09 |
| GyrosGeier | debhelper 12.1.1 is in beowulf | 03:10 |
| * GyrosGeier sets up ascii environment | 03:12 | |
| GyrosGeier | hmmk | 03:15 |
| GyrosGeier | debhelper backport is complicated | 03:15 |
| GyrosGeier | you can install dh-autoreconf and debhelper from Debian buster | 03:17 |
| GyrosGeier | that works | 03:17 |
| GyrosGeier | those are the same packages as in beowulf | 03:17 |
| GyrosGeier | sanest way is to add beowulf sources, and set up an apt_preferences file to set the default release to ascii | 03:18 |
| GyrosGeier | then you can use "apt install dh-autoreconf/beowulf debhelper/beowulf" | 03:19 |
| gnarface | yes, that might work though it's important to note that mixing distros and versions is explicitly advised against by Debian | 03:21 |
| GyrosGeier | yes | 03:21 |
| gnarface | (and all Debian derivatives inherit the risks they are warning of, despite that Ubuntu leadership lies and sweeps them under the rug) | 03:21 |
| GyrosGeier | for those two packages I'd say it's mostly harmless | 03:22 |
| DarwinElf | you mean Ubuntu Windows? | 03:22 |
| GyrosGeier | but yes, pbuilder would be preferable :) | 03:22 |
| DarwinElf | well, I already have it from Devuan and am using it now | 03:22 |
| gnarface | never even touched it. i'm just talking about Ubuntu PPA's... they're very risky | 03:22 |
| GyrosGeier | PPAs avoid mixing | 03:23 |
| GyrosGeier | people upload source packages, and the PPA compiles once per release | 03:23 |
| gnarface | they do not, that's the whole point of PPA's; they're community-contributed and unregulated | 03:23 |
| gnarface | you have no idea what they're doing behind the scenes there | 03:23 |
| GyrosGeier | they run pbuilder :) | 03:23 |
| gnarface | Ubuntu has been very dishonest and misleading about that | 03:23 |
| chillfan | https://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do | 03:25 |
| chillfan | all you need to know about ubuntu ^^ | 03:26 |
| * tuxd3v Zas... mission acomplished :) | 03:26 | |
| * tuxd3v cuda toolkit installed in a unsuported os, unsuported compiler, unsuported glx infraestructure :) | 03:26 | |
| onefang | Congrats, now don't come here asking for support for that lot. B-) | 03:27 |
| onefang | Tongue firmly in cheek, for those that didn't spot that. lol | 03:27 |
| GyrosGeier | the ubuntu setup for PPAs is rather easy to replicate | 03:28 |
| GyrosGeier | # pbuilder create --basetgz /tmp/xenial.tgz --distribution xenial --mirror http://archive.ubuntu.com/ubuntu | 03:28 |
| GyrosGeier | now all you need is to replace "xenial" by a shell variable and make a for loop around that | 03:28 |
| GyrosGeier | and also run a for loop for building packages | 03:29 |
| tuxd3v | onefang, I followed my bisect intructions.. the hold perl install utility saves a man sometimes lol.. I extracted the package and installed some things by hand :), after that easy peasy | 03:30 |
| tuxd3v | hold -> old | 03:31 |
| DarwinElf | turns out I won't need this package because a good enough one is in backports, and some of the results were confusing (like built ones for a newer and older version)... but at least I learned how to do it... would rather have learned it without debuild (or even equivs, but didn't use it) but maybe that's not necessary | 03:56 |
| DarwinElf | thanks for all the replies when I was asking questions about that | 03:56 |
| Digit | what packages do i install to get the go compiler stuff? (needed for pixterm https://github.com/eliukblau/pixterm (like termpix)~(neither in repo)). or is it not packaged either? should just get it manually? or are there other pixterm/termpix alternatives in the repos already? | 07:41 |
| tarzeau | Digit: https://go-team.pages.debian.net/ | 08:17 |
| psarria | hi, are there any plans or progress for the next "Debian 10" based Devuan ? | 13:21 |
| onefang | It's almost ready. | 13:23 |
| psarria | great news then | 13:24 |
| hemimaniac | oh good, I can't wait, I broke my devuan real bad | 16:38 |
| hemimaniac | but it wasn't devuan's fault | 16:39 |
| James1138 | How did you break Devuan?! I do not want to make same mistake please. | 16:59 |
| hemimaniac | tried upgrading/updating it without following the posts in the forums. tried to do it in 2 steps instead of 5, got b0rked | 17:00 |
| James1138 | Ahhh | 17:01 |
| hemimaniac | oh and tried to force in a couple PPA's (which they explicitly tell you not to do) and ya, broken | 17:01 |
| debuankernel | What is advised how to compile PM_TRACE in to the kernel on devuan, and for acpi resume debugging? | 19:28 |
| debuankernel | May be a pointer? | 19:28 |
| debuankernel | Thanks in advance | 19:28 |
| debuankernel | Or: Which source do I take? | 19:29 |
| fsmithred | debuankernel, I think this still works: http://forums.debian.net/viewtopic.php?f=16&t=36525 | 19:37 |
| debuankernel | thanks | 19:45 |
| systemdlete | devuan is now #16 on distrowatch for non-systemd distros? Is this because of a possible re-merge with Debian? | 21:31 |
| systemdlete | (am I dreaming?) | 21:31 |
| djph | devuan merged back in with Debian!? | 21:34 |
| djph | ABANDON SHIP | 21:35 |
| golinux | No it's because we kick ass | 21:35 |
| djph | golinux: oh, sweet. continue as normal then. | 21:35 |
| systemdlete | If we "kick ass" why only 18th in the rankings? | 21:35 |
| systemdlete | IIRC, devuan was much higher way back | 21:35 |
| djph | beowulf is nice; moved up to that on my apache / postfix box. | 21:35 |
| systemdlete | has beowulf been released? | 21:36 |
| golinux | I don't follow numbers. If you want that number to go higher, contribute or be quiet. :D | 21:36 |
| golinux | Soon. Putting on the final touches | 21:37 |
| systemdlete | Some people here talk about beowulf as if it had been released already. OK, thanks. I am looking forward to Beowulf. | 21:37 |
| systemdlete | (I know how to "make" a beowulf and have done it a few times already) | 21:38 |
| MinceR | those rankings reflect interest on the distrowatch site, nothing more | 21:38 |
| MinceR | you can expect more page views when there's more hype | 21:38 |
| systemdlete | It's a heuristic for me. Just makes me wonder. I know it is not scientific. | 21:39 |
| djph | I had to update to testing -- needed PHP 7.3 to get off Owncloud | 21:39 |
| djph | lessee -- MX, antix, gentoo, slackware ... all long-standing releases (IIRC) | 21:39 |
| systemdlete | So you think it is due to devuan being relatively new? | 21:40 |
| systemdlete | that would make sense | 21:40 |
| djph | not "new" so much as going up against some considerably older names | 21:41 |
| systemdlete | (I DID say "relatively" djph) | 21:41 |
| djph | what I mean is it's not that devuan itself is relatively new (in general) -- but that the comparisons have been around for _AGES_ -- and the people using them aren't likely to leave without their chosen project making some big missteps | 21:42 |
| systemdlete | I thought I read a link from here a month or two back saying that the debian project was looking at not being so systemd-centric. Someone here posted it. | 21:42 |
| djph | yeah, their last GR / vote or something like that | 21:42 |
| djph | I dunno what actually came of it | 21:42 |
| systemdlete | (djph, I think we are saying the same thing, with different words) | 21:42 |
| systemdlete | there were umpteen proposals for the exact wording, yes. | 21:43 |
| djph | systemdlete: the other ones "above" dev1 all appear to be rather specialized (and again, popular in their nicehs) | 21:43 |
| djph | *niches | 21:43 |
| systemdlete | anti-x and MX linux are not "specialized at all really. I am using both of them. For me "specialized" means, like, ipfire or openmediavault | 21:44 |
| systemdlete | djph: "relatively" means precisely what you are saying. "in comparison to..." | 21:45 |
| golinux | Maybe this should go to #debianfork. It is hardly a support discussion. | 21:45 |
| systemdlete | it has degraded into a social discussion, yes. | 21:46 |
| systemdlete | let's take it there | 21:46 |
| golinux | Thanks | 21:47 |
| Akuli | how do i search for non-systemd distros on distrowatch? | 22:16 |
| Akuli | (hmm, this isn't a support question either) | 22:17 |
| Akuli | (now it's a crosspost on #debianfork too and everyone are even more annoyed because i cross-posted) | 22:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!