yeti | who knows kilo? | 00:41 |
---|---|---|
tuxd3v | yeti does you have a nanopi R2S :P | 00:41 |
tuxd3v | :) | 00:41 |
yeti | "Kilo does not depend on any library (not even curses). It uses fairly standard VT100 (and similar terminals) escape sequences." | 00:42 |
yeti | hardcoded for vt100? | 00:42 |
yeti | seriously? | 00:42 |
yeti | nah... pi0..4, bananapi-r1, cubietruck | 00:42 |
tuxd3v | yeti, pi{0..4}? | 00:44 |
yeti | yip | 00:44 |
tuxd3v | awesome :) | 00:44 |
tuxd3v | can rpi4 be overclocked to 1.8Ghz or something like that? | 00:45 |
yeti | I'd be more interested in underclocking | 00:45 |
yeti | havent looked for overclocking | 00:46 |
tuxd3v | hehehe, because of the heat? | 00:46 |
yeti | frying pans! | 00:46 |
tuxd3v | :D | 00:46 |
tuxd3v | I am in a good damm dead end, with ananopi R2S.. | 00:47 |
yeti | https://www.berrybase.de/media/image/97/66/2c/ID_85048_orig_600x600.jpg <<< even with that dress, they come near to painly temperatures... | 00:47 |
yeti | not overclocked | 00:47 |
yeti | that's trash by design | 00:48 |
yeti | but the cheapest armish with 8G RAM | 00:48 |
yeti | ok... wirh netbsd... with linux they probaly will glow bright white | 00:49 |
yeti | :-Þ | 00:49 |
mason | NetBSD's a bit harder on hardware than Linux generally. | 00:49 |
tuxd3v | actually netbsd is more advanced that what I tough, on ARM.. | 00:50 |
onefang | How many terminal programs these days don't talk VT100? Hard coding "fairly standard VT100 (and similar terminals) escape sequences." is actually a good idea. | 00:52 |
yeti | thats an opinion, not a fact. | 00:52 |
tuxd3v | http://www.netbsd.org/releases/formal-9/NetBSD-9.0.html | 00:52 |
yeti | pi4 currently needs netbsd9.99 | 00:53 |
mason | NetBSD doesn't have a tickless kernel yet, so it doesn't sleep as cleanly, since we are comparing heat and power. | 00:53 |
mason | I guess a tickless kernel can be opinion. :P | 00:54 |
mason | yeti: What's your opinion on whether NetBSD's kernel has a fixed clock? | 00:55 |
stiltr | Make sure you have the latest usb FW. Drops the temps considerably on the Pi4. | 00:55 |
tuxd3v | mason, what was the card you brought? | 03:45 |
tuxd3v | and AMD one, I searched for it, its a powerfull gard | 03:45 |
tuxd3v | very very nice :) | 03:46 |
mason | tuxd3v: gtx 1660 super | 03:54 |
tuxd3v | wow, that is the upgrade of mine, a big upgrade.. I own a gtx 1060 &GB | 03:55 |
tuxd3v | &GB -> 6GB | 03:56 |
tuxd3v | lol o.0 | 03:57 |
systemdlete | is ascii or beowulf 64bit time? | 04:47 |
systemdlete | when I size the struct timeval, it shows me it is 16, which means that the time_t field is 8 bytes. | 04:48 |
systemdlete | but maybe that's because of alignment. | 04:48 |
systemdlete | See this short source: http://paste.debian.net/1167546/ | 05:03 |
systemdlete | when I compile this, and it does compile and run, I get output telling me that the tv_sec and tv_usec elements of the struct are 8 bytes each, and the overall size of the struct is 16. | 05:04 |
systemdlete | My understanding is that 64 bit time isn't official until about kernel 5.6.1 or so | 05:05 |
systemdlete | (I'm trying to make sense of this) | 05:05 |
Matrox | has devuan patched dbus to not use machine-id? | 14:44 |
fsmithred | Matrox, yes. You can control that in /etc/default/dbus | 14:49 |
Matrox | fsmithred, isn't machine id necessary for dbus to work? | 14:50 |
fsmithred | nope | 14:50 |
fsmithred | u, | 14:50 |
fsmithred | um | 14:50 |
fsmithred | maybe so. | 14:50 |
fsmithred | the patch changes the id every boot | 14:50 |
Matrox | oh | 14:50 |
Matrox | i might use that patch on gentoo | 14:51 |
fsmithred | some people are very happy to have it | 14:51 |
fsmithred | you know where to find our sources? | 14:51 |
Matrox | no, i guess github | 14:51 |
fsmithred | git.devuan.org | 14:53 |
Matrox | alright, will check that patch. | 14:53 |
fsmithred | https://git.devuan.org/devuan/dbus | 14:53 |
Matrox | also some questions about devuan. does it use sysv init or something else? and also is libsystemd0 necessary on devuan? does it use elogind also (from gentoo)? | 14:54 |
fsmithred | one sec. | 14:54 |
fsmithred | sysvinit is default, but openrc and runit are available. So is s6. | 14:56 |
fsmithred | first three are available in the installer | 14:56 |
fsmithred | libsystemd0 is required for some things, but it can be replaced with libelogind0 | 14:57 |
fsmithred | I think the former still comes up first on debootstrap installs. | 14:57 |
fsmithred | yes, we have elogind and we managed to get it into debian. | 14:57 |
fsmithred | also we have consolekit for uh, I think two desktops. | 14:58 |
fsmithred | https://files.devuan.org/devuan_beowulf/Release_notes.txt | 14:58 |
fsmithred | ^^^ They are short. | 14:59 |
Matrox | debian with openrc sounds like a good thing | 15:00 |
Matrox | with elogind | 15:00 |
Matrox | so you provide the necessary init scripts for every service right? (some distros say they support other inits, but in their packages they dont give you the initscripts for services, and tell you to write your own) | 15:01 |
fsmithred | we fork around 200 packages | 15:02 |
fsmithred | the rest get pulled from debian and automatically merged into our repo | 15:02 |
fsmithred | some debian devs have started dropping init scripts from the packages | 15:02 |
fsmithred | we are attempting to keep up | 15:02 |
fsmithred | pulling the scripts from older versions | 15:03 |
Matrox | alright thats nice. | 15:03 |
fsmithred | also trying to get debian devs to put them back | 15:03 |
Matrox | yeah debian devs should offer init diversity | 15:03 |
Matrox | in debian they tell me they don't have init files for sysv anymore | 15:04 |
fsmithred | one thought for long term solution would be for all init systems to be able to use systemd service files | 15:04 |
fsmithred | they should not be saying that | 15:04 |
fsmithred | it's a misrepresentation of the last vote | 15:04 |
fsmithred | they don't have to have them, they are not required. but they can be included. | 15:04 |
fsmithred | many still are. | 15:05 |
fsmithred | I think most still are, or we would be in deep shit. | 15:05 |
Matrox | i mean, since devuan already does all the work to keep those init scripts available. | 15:05 |
Matrox | why can't they just take the work from devuan an merge it into debian, to offer more options | 15:05 |
fsmithred | that's just it. We mostly aren't doing any work to keep them. | 15:06 |
fsmithred | they are already there | 15:06 |
Matrox | oh alright | 15:06 |
fsmithred | we inherit 99% of packages from debian. In fact, those packages aren't even on our servers. | 15:06 |
fsmithred | invisible merge happens. | 15:06 |
fsmithred | so you only use devuan sources in apt | 15:06 |
Matrox | fsmithred, is there a way to use systmed unit files with other inits? | 15:56 |
hagbard_ | Where would be the right place to propose (or even provide) forks of debian packages in regard to systemd-dependencies? I think the libsystemd version that wireshark-common depends on can safely be downgraded, so that libelogind can be used instead. | 18:48 |
hagbard_ | This would make wireshark, tshark (and the packages that belong to / depend from it) installable in testing and unstable. | 18:49 |
hagbard_ | Builds and runs just fine. | 18:49 |
golinux | #devuan-dev | 18:49 |
golinux | or the -dev mail list | 18:49 |
hagbard_ | thx, i'll head over there | 18:50 |
golinux | wireshark has been a topic of conversation recently do that might already be in the works. Check the dev1galaxy.org forum | 18:50 |
golinux | do > so | 18:51 |
mason | hagbard_: I'd suggest that removing that dependency entirely would be preferable. | 18:57 |
hagbard_ | Haven't tested that yet. And it would certainly require some more surgery (code, makefiles, build-config), than just to lower a version number in the control file. | 19:01 |
golinux | hagbard_: https://lists.dyne.org/lurker/message/20200825.214233.c6bab666.en.html | 19:10 |
golinux | https://lists.dyne.org/lurker/message/20200814.065450.f5e0da1e.en.html | 19:11 |
hagbard_ | hmm, there is said "Until there is a new version of elogind upstream, I am afraid I have no ideas of how to fix this." | 19:14 |
hagbard_ | But an idea exists, that seems to work out. | 19:15 |
hagbard_ | And the replies to the debian bug report don't read like they're in the mood to fix it over there. | 19:18 |
n4dir | Hi. If i quickly want to translate a word from french to english or german, is there a program for that (which is easy to set up) ? | 22:50 |
fsmithred | you don't want google to know what you're translating | 22:52 |
n4dir | ha ha. No, i don't mind that, but i usually don't have a web-browser open | 22:53 |
n4dir | for german-english i use ding, which does a good job. I think you can make it use german-french too, but that will get a bit messy | 22:53 |
fsmithred | apt-cache search dictionary | 22:53 |
fsmithred | translate is a package that does german/english | 22:53 |
n4dir | yeah, but i don't understand the results. got ispell, hunspell ans what not. | 22:54 |
n4dir | and it seems some explain french words in french. But i am not sure about the names for such stuff | 22:55 |
n4dir | looks like ding is a backend for trans: /usr/share/trans/de-en | 22:58 |
fsmithred | you might find bilingual dictionaries, but to translate text you probably need to pay money or use goober | 22:58 |
fsmithred | they do a pretty good job these days | 22:59 |
fsmithred | much better than 10 years ago | 22:59 |
n4dir | i just need single words. | 22:59 |
Wafficus | Hi there, how do I change my timezone in Devuan on my current machine? | 23:00 |
fsmithred | qstardict - International dictionary written using Qt | 23:00 |
fsmithred | Wafficus, dpkg-reconfigure tzdata | 23:01 |
Wafficus | I have Central timezone present, but I'd like to change it to EDT | 23:01 |
Wafficus | thanks | 23:01 |
Wafficus | nice that worked, thanks a ton fsmithred | 23:01 |
systemdlete | is ascii or beowulf 64bit time? | 23:18 |
mason | systemdlete: Looks like the year 2038 problem is fixed as of Linux 5.6, so neither of those, unless there's some subtlety I don't know of. | 23:27 |
systemdlete | mason: Thank you for your response. If I compile this short snippet: http://paste.debian.net/1167546/, I find that I get 8, 8, and 16 for output. | 23:28 |
systemdlete | if library routines are passing in 8 byte (64 bit) values to the kernel for, say, timers and the like, then the kernel would have to be supporting 64 bit time, at least in this context. | 23:29 |
n4dir | if i am not wrong: apt-get install dictd dict dict-freedict-fra-eng | 23:30 |
systemdlete | But perhaps I am forgetting some things from my kernel internals classes | 23:30 |
n4dir | then: dict <french-word>; and i get the translation. Nice | 23:30 |
systemdlete | (I had a 3b20 internals class, and a 2-week Amdahl UTS class, 30+ years ago) | 23:30 |
n4dir | dict-freedict-en-fra; i tried first, but that would only take english words for <word> | 23:31 |
mason | systemdlete: Libraries can handle and convert things. Looking at this, one of the thing I found, for example, was from a year years ago, with Boost having 64-bit times. | 23:31 |
systemdlete | boost? Sorry, don't recall what that is | 23:31 |
mason | systemdlete: C++ libraries, a tier down from the standard C++ libraries. | 23:32 |
systemdlete | ah. | 23:32 |
systemdlete | anything could be happening then. But the timeval and timespec structs are standard C library mechanisms. | 23:33 |
mason | systemdlete: I see 8 bytes for time_t under Beowulf. | 23:33 |
mason | systemdlete: I'm not sure what the answer is. I found an article talking about Linux 5.4 and 5.6, and saying glibc-2.32 and newer, so I'm not sure what's happening with that 8-byte time_t. | 23:34 |
systemdlete | mason: Even if there are backend routines stuffed in between the libraries and the kernel calls, still, in order to be accurate, the kernel would need to support 64 bits, wouldn't it? I don't see any practical way around that. | 23:34 |
mason | https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ came up | 23:34 |
systemdlete | thanks! | 23:34 |
mason | systemdlete: Yeah, I don't know, but if you find something authoritative and enlightening, please share it, as I'm curious now. | 23:35 |
systemdlete | it is almost as if the kernel devs and library support folks (if different) have been dropping small parts of the solution into place over time, rather than one clean cutover? | 23:35 |
mason | systemdlete: It sure looks like that. | 23:36 |
systemdlete | I wonder what sorts of fallout that could be causing without many people realizing it. | 23:36 |
mason | Hopefully none if each change is compartmentalized. | 23:37 |
systemdlete | Again, if even ONE SINGLE routine passes a 64 bit arg to the kernel in a system call, then the kernel MUST be able to handle it, right? | 23:38 |
systemdlete | that's my argument. Not saying you are wrong, but I am feeling this a different way. | 23:38 |
mason | systemdlete: Just promise to tell me what you learn. :P | 23:39 |
systemdlete | will do mason! And thanks for the chat | 23:39 |
systemdlete | mason: Different topic. Any suggestions on decent development workbench for linux? | 23:40 |
systemdlete | eclipse is one I know of. | 23:40 |
mason | systemdlete: vi and Makefiles - I'm a dinosaur | 23:40 |
systemdlete | (me too, heheheh. But I am hoping that a workbench will help sort out some header file issues I am running into. It would be more convenient I think. | 23:41 |
systemdlete | ) | 23:41 |
n4dir | not really an IDE, more of an editor, but quite some liked geany back some years | 23:42 |
systemdlete | geany... ok, thank you. | 23:42 |
n4dir | if it is for C and the like, a few are recommended at the according sites (i forgot the names, but you will quickly run in them) | 23:42 |
n4dir | code::blocks and codelite and anjuta is what i forgot. Found them here: https://wiki.ubuntuusers.de/Entwicklungsumgebungen/ systemdlete | 23:50 |
systemdlete | thanks again! | 23:51 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!