Re: [DNG] End of free open source software?
On Sat 15/May/2021 15:50:12 +0200 spiralofhope wrote: On Fri, 14 May 2021 14:27:15 +0200 "Enrico Weigelt, metux IT consult" wrote: On 09.05.21 08:33, tito via Dng wrote: So the first question that arises is: how could open source and free software projects ensure protection from damage up to data loss if actually even proprietary software comes with no warranty at all? >> Make it crystal clear, that our software is neither a product, nor service, nor anything near to any commercial thing, but instead just a piece of art, like a novel or a poem. A programming language used to write code is not different than the English an author uses to write a story. It would take some effort to explain, but programming and authoring do map to one another. For example, it's a long-time pursuit for many programmers to author more natural language-like readable code. On the other hand, the majority of people cannot write or read computer programs. Some barely understand the principles by which computers work. Yet, they use them, and at times may happen to depend on them for life-or-death matters. Should that people use free software? Actually, even programmers use a number of software packages without even bothering to download their sources. We may appreciate the syntax or the ease of use, but much of the poetry gets lost. I'd confess that I read code only in a few occasions. When there's not enough docs, when there's a malfunction, when I have to write code which interacts with that. Best Ale -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Beowulf; Increasing the number of boot options under grub. How To?
I am hoping there is a simple config/number change in the grub config files, but I can not find it in the doco I've read. In the past, the list of kernel images just grew each time you loaded/updated the linux-image files. But the current system automatically trims it to just two, with normal and recovery versions of each. The reason I want to do this is to lad step through some of the 5.* kernel to see if any of them now give any support to my AMD RX 5700* XT gpu card that has been unable to be used(unless I want a single screern in vesa mode). LS: At this stage the hardware is correctly identified by various hardware programs with mirrored dual screens during boot up, but the between Xorg, Mesa & Vvulkan, which supposedly make it work, I just get a VESA single screen. My tip is never to but any AMD 5700 card. My 5700 HD never worked reliably under their proprietary driver and it was years before the Radeon driver was able to support it. T.I.A. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On 2021-05-17 23:31:12, terryc wrote: > I am hoping there is a simple config/number change in the grub > config files, but I can not find it in the doco I've read. > > In the past, the list of kernel images just grew each time you > loaded/updated the linux-image files. But the current system > automatically trims it to just two, with normal and recovery versions of > each. > > The reason I want to do this is to lad step through some of the 5.* > kernel to see if any of them now give any support to my AMD RX 5700* XT > gpu card that has been unable to be used(unless I want a single screern > in vesa mode). > > LS: At this stage the hardware is correctly identified by various > hardware programs with mirrored dual screens during boot up, but the > between Xorg, Mesa & Vvulkan, which supposedly make it work, I just get > a VESA single screen. > > My tip is never to but any AMD 5700 card. My 5700 HD never worked > reliably under their proprietary driver and it was years before the > Radeon driver was able to support it. I recently bought an AMD Radeon RX 5700 XT card. Your 5700 might be too new for Beowulf, I had to jump through some hoops te get my 5600 working fully. Using the 5.10 kernel from Beowulf-backports, Mesa drivers and a bunch of related libraries from a third party PPA, and a hack. I now have 3D virtual worlds and dual screen working fine. No idea if any of that will work for a 5700, since I don't have one. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] routing tables.
I now have a new VDSL connexion now, which is supposed to go at 25Mbits/sec downstream and 10 Mbits/sec upstream. Bell has been here and has checked that it is working, using their modem. Now I'd like to get it to actually work, which means that *my* modem has to be able to talk VDSL. It turns out that I have to reconfigure the modem, and I have instructions to do that. The first step is to use a browser to connect to http://192.168.1.1 Now that means I have to configure my routing tables so that packets to 192.168.1.1 will go to port ethv0, which is where the modem is connected. One or two routing table entries should do it. I have found several authoritative-looking web pages on instructions to display and edit the routing tables. But none of them explains what the routing tabe entries *mean*. Anybody have some Linux routing experience or links to explanations? The last time I had to mess with any of this was about 15 years ago, and I've quite forgotten the details. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Collaboration between distros [WAS: FSF and human rights]
There is also PcLinuxOS even if rpm based but they have the full stack systemd free and could be a source of code for devuan as they already solved somehow most of the problems. Systemd free distros should pool their efforts to avoid duplication and to gain critical mass. >>> >>> I'd like to put that onto a broader level: IMHO most of the work to do >>> for distros is about QM (testing, patching, bugfixing) - we should try >>> to consolidate that work, independent of individual distros and their >>> technology. >>> >>> For decades, whenever I package something for some distro, I try to >>> do most of the work in a distro agnostic way. (used to have my own >>> project, called "oss-qm", which collects patches ontop of upstream >>> releases to make up QM'ed branches - unfortunately no distro really >>> showed any interest in that). >>> >>> In essenence, I'm proposing fixing up packages (and individual >>> releases) >>> up to a point where the actual distro-packaging is pretty much >>> trivial. >>> For *most* SW out there we could even invent some universal packaging >>> metadata format, that could be automatically transformed into dist- >>> specific build files. Of course, that only works just *mostly*, since >>> there're still many exceptions. Dh (and its various helpers) is >>> already >>> a great step into that direction, but we could go some steps further >>> and make it useful for completely unrelated distros and even more >>> tricky >>> cases like crosscompiling and tiny embedded scenarios. >> >> >> Standardize the package format of the released versions of each free >> software project would be a total and desirable revolution. > > > Would it? Or would that standardization make Linux vulnerable to > malicious activity and misuse by those who want to control > "free-software" in oh so many ways? > > Christopher Barry's "Open letter to the Linux World"[1] concludes with > this: > > OneLinux == zero-choice > > [1] http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html > > golinux Please, be careful, I'm not saying that distros should disappear to create a single operating system, or anything like that. I am talking about the format in which developers publicly offer for download the code for new versions of the software they create. I do not see how standardizing the format of the "licenses" file or standardising the name of the folders within the source file could imply a security problem or cause the distros to disappear. I think that just the other way around, this would make packaging easier for distros, freeing up time that can be spent on other things. Regarding security, the vulnerable software is the installed and executable software, not the source file. Best regards. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] routing tables.
On Monday 17 May 2021 at 20:35:41, Hendrik Boom wrote: > The first step is to use a browser to connect to http://192.168.1.1 The second step (in IP terms) is to connect *from* an address that 192.168.1.1 can reply to. > Now that means I have to configure my routing tables so that packets to > 192.168.1.1 will go to port ethv0, which is where the modem is > connected. Just add an address in the 192.168.1.0/24 range to your interface ethv0, and it will (a) create the routing table entry for you, and (b) ensure that the router can reply to your browser. How to do that? Old style: ifconfig ethv0:1 192.168.1.42 New style: ip addr add 192.168.1.42/24 dev ethv0 Once you're done: Old: ifconfig ethv0:1 down New: ip addr del 192.168.1.42/24 dev ethv0 Antony. -- This email is intended for the use of the individual addressee(s) named above and may contain information that is confidential, privileged or unsuitable for overly sensitive persons with low self-esteem, no sense of humour, or irrational religious beliefs. If you have received this email in error, you are required to shred it immediately, add some nutmeg, three egg whites and a dessertspoonful of caster sugar. Whisk until soft peaks form, then place in a warm oven for 40 minutes. Remove promptly and let stand for 2 hours before adding some decorative kiwi fruit and cream. Then notify me immediately by return email and eat the original message. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Collaboration between distros [WAS: FSF and human rights]
>> Standardize the package format of the released versions of each free >> software project would be a total and desirable revolution. The burden >> of offering the available software would shift to software developers >> rather than distributions. > > I disagree. The rich variety of distros enables each of us to select > for our own set of priorities. > > As far as shifting the burden to the software developers, I was once > one of those software developers: The VimOutliner project. I *never* > would have created a package for VimOutliner. I had other stuff to do, > including improving VimOutliner. > > As a user of a minority packaging system (xbps), I get hurt more than > most by the lack of xbps packaged drivers and esoteric software, and > yet I'm still for distros choosing a packaging system or even > developing their own. > > Finally, one package manager is a single point of failure. Imagine if > systemd took over that one package manager, eliminating the possibility > of Linux without systemd? > > SteveT Standardise the format in which developers publicly offer for download the code for new versions of the software they create, would make packaging (or port/ebuild creation) easier for distros, freeing up time that can be spent on other things. Standardise the source files is not an obstacle for distros to customize the software they distribute, on the contrary it would make it easier to focus on customizations because the organization of the source file would be predictable. Obviously conforming to a standardised source file format means more burden for developers, it would help the spread of their software by making it easier for more distros to package it, although as I said it is already quite an effort for many developers to package their software code for download in whatever way they find easiest and let distros create ready-to-install packages (be it binaries or ports/ebuilds) for their distro users. Since I'm talking about how developers package their code to make it available for download either to users who compile personally or to distro maintainers who create ready-to-use packages and make them available in a repository for their users, this has nothing to do with the damn systemd wanting to contest the place occupied by deb, rpm, xbps and the bloated AppImage and Snap. Best regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] routing tables.
On Mon, 17 May 2021 14:35:41 -0400 Hendrik Boom wrote: > I now have a new VDSL connexion now, which is supposed to go at > 25Mbits/sec downstream and 10 Mbits/sec upstream. Bell has been here > and has checked that it is working, using their modem. > > Now I'd like to get it to actually work, which means that *my* modem > has to be able to talk VDSL. > > It turns out that I have to reconfigure the modem, and I have > instructions to do that. > > The first step is to use a browser to connect to http://192.168.1.1 > > Now that means I have to configure my routing tables so that packets > to 192.168.1.1 will go to port ethv0, which is where the modem is > connected. My 2c here. All the commmercial moden/routers I've been using since I moved from copper line dial up all havve default IPv4 addresses similar to what you quote. Until recently*, a simple "arp -s hostname MAC-address" was sufficient to enable some comms to enablt telnet or browser to communicate with it enough to set it with an IPv4 that brought it into your current IPv4 after a reboot. Caveat, you may needs to open the netmask on the computer you wish to configure it from e.g. 255.255.255.0 to 255.255.0.0. I use 192.168.x.y as our IPv4 SOHO LAN and we run static IPs, so it is a relative simple matter to either etc /etc/network/interfaces or swap them around to one that already has the wider netmask. Tip; when I retire a modem/router, I usually change the working IPv4 from the active portal to a range of retirement IPv4s, which are listed in /etc/hosts. This way, should you ever have to quickly draft the old modem -router back into harness, you can communicate with it ASAP once you plug it back into the network. > > One or two routing table entries should do it. > > I have found several authoritative-looking web pages on instructions > to display and edit the routing tables. > > But none of them explains what the routing tabe entries *mean*. > > Anybody have some Linux routing experience or links to explanations? > > The last time I had to mess with any of this was about 15 years ago, > and I've quite forgotten the details. Try "sudo route -n" to see your current routing table. I've munged mine below. Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.X,Y 0.0.0.0 UG0 0 0 eth0 192.168.0.00.0.0.0 255.255.0.0U0 0 0 eth0 You will notice, I still have the netmask on this machine at 255.255.0.0 (/16?) from the last modem-router configuration. Then after it is just a series of sudo route -add commands, in theory. YMMv depending on your LAN. I've found the netmask fiddle best for me as it isn't something I do regularly either. * I recently found that you can not arp to the newer Netgear modem-routers. Given the abysmal ingress filtering ability and the configure by smart phone route they push, that brand is on my POS list. I've always had good service from Billion. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] routing tables.
On 5/17/21 1:35 PM, Hendrik Boom wrote: I have found several authoritative-looking web pages on instructions to display and edit the routing tables. But none of them explains what the routing tabe entries *mean*. The routing table entries show the way your host can find other networks, local or remote. Each entry describes how to reach every connected network, and what it considers to be local to your connection. A special route, the default route, shows how to reach networks outside of your local scope. Other routing table entries may show how to reach other networks. When you configure your interface ethv0, a route to its local network will be shown, for example: with "ip route": 192.168.1.0/24 dev ethv0 proto kernel scope link src 192.168.1.10 with "netstat -rn" : Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ethv0 They both describe the same route, to network 192.168.1.0, with a 24 bit netmask (meaning you have 8 bits left for hosts in your network, from 192.168.1.1 to 192.168.1.254, with 192.168.1.0 being used to reference the network itself, and 192.168.1.255 as the broadcast address, where you would send data meant for every host in your network). If you want to reach say network 192.168.90.0/24 which is reacheable via host 192.168.1.2, you could add a route like this: ip route add 192.168.90.0/24 via 192.168.1.2 A special route to network 0.0.0.0/0 is the default route, which is used to reach any network of which your host has no knowledge. With ip show it looks like this: default via 192.168.1.1 dev ethv0 onlink with netstat -rn it looks like this: Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 ethv0 With route it can be added as: route add -net default gw 192.168.1.1 once you have your interface configured. -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On Tue, 18 May 2021 02:18:02 +1000 onefang wrote: > On 2021-05-17 23:31:12, terryc wrote: > > I am hoping there is a simple config/number change in the grub > > config files, but I can not find it in the doco I've read. > > > > In the past, the list of kernel images just grew each time you > > loaded/updated the linux-image files. But the current system > > automatically trims it to just two, with normal and recovery > > versions of each. > > > > The reason I want to do this is to lad step through some of the 5.* > > kernel to see if any of them now give any support to my AMD RX > > 5700* XT gpu card that has been unable to be used(unless I want a > > single screern in vesa mode). > > > > LS: At this stage the hardware is correctly identified by various > > hardware programs with mirrored dual screens during boot up, but the > > between Xorg, Mesa & Vvulkan, which supposedly make it work, I > > just get a VESA single screen. > > > > My tip is never to but any AMD 5700 card. My 5700 HD never worked > > reliably under their proprietary driver and it was years before the > > Radeon driver was able to support it. > > I recently bought an AMD Radeon RX 5700 XT card. Your 5700 might be > too new for Beowulf, I had to jump through some hoops te get my 5600 > working fully. Using the 5.10 kernel from Beowulf-backports, Mesa > drivers and a bunch of related libraries from a third party PPA, and > a hack. I now have 3D virtual worlds and dual screen working fine. > No idea if any of that will work for a 5700, since I don't have one. The 5700 card has been out for about 18 months and has been 'superceeded' by other cards all ready. That would be the Ubuntu PPA stuff I'm assuming from all the guides I've read and must have included a few programs from github. I've basically followed what I can of those various 'guides' and loaded the vulkan and mesa stuff available from beowulf-backports, but even that doesn't make the card work. The mesa in the phoroix article is later than the beowulf-backports Nor it seems that apt-get -t beowulf-backports install/reinstall guarantee the latest. I recently ran the apt-get -t beowulf-backports update/upgrade and it re-installed a number of the packages I've installed in the last 24 hours. Head scratch. I've nailed the problem down to two points. One is hardware and a 'kernel panic - fatal exception in interrupt' when dual monitors are plugged in via dpi sockets at powert on. It is okay to plug the second in afterwards. Otherwise, the 5.10 kernel boots and loads amdgui drivers. The second is software and is an Xorg problem when is barks on not finding /dev/dri/card0 and falls back to VESA mode. I can live with that for a while and will try lurking in relevant dev lists to see if there is a future fix or I've got an orphan. Anyway, thanks. i > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
