Re: [DNG] M$ Linux-frendly
On 04/23/2016 10:54 AM, Go Linux wrote: On Fri, 4/22/16, Simon Walter wrote: What is the reason people use CentOS? It's in the name and Cpanel is evidence. I think that people use Centos to avoid the cost of an expensive support contract with Redhat. But still have the cozy feeling that they are using an "enterprise" product. CentOS = Community enterprise OS. Why would you want to use RedHat anyway? I remember RPM hell. That made me love Debian. I would rather use Slackware than RedHat - sorry to be such a snob. I don't use it anymore much, but Gentoo was gorgeous engineering. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] M$ Linux-frendly
On 04/23/2016 12:14 PM, Go Linux wrote: On Fri, 4/22/16, Simon Walter wrote: Subject: Re: [DNG] M$ Linux-frendly To: dng@lists.dyne.org Date: Friday, April 22, 2016, 9:28 PM On 04/23/2016 10:54 AM, Go Linux wrote: On Fri, 4/22/16, Simon Walter wrote: What is the reason people use CentOS? It's in the name and Cpanel is evidence. I think that people use Centos to avoid the cost of an expensive support contract with Redhat. But still have the cozy feeling that they are using an "enterprise" product. CentOS = Community enterprise OS. Because Centos IS Redhat without the paid support ie a "free' community version. Nearly all the hosting companies I've done business with have used Centos. And I find that highly annoying because my experience is that CentOS is OK and Cpanel just makes it seem like CentOS is a nightmare. Then it dawned on me why. It's not a matter of apt-get install php5-mysql libapache2-mod-php5 to get a "LAMP" server up and running with sane defaults. I really like OpenBSD's motto of secure by default. I am glad that we have the experience of Debian as a foundation and we can improve on that. Why would you want to use RedHat anyway? For me it was just a matter of circumstances. Back @2005 the geeks at the local LUG were using it. They had an "installfest" and that's what got put on a hand-me-down machine alongside Winblows 98. Those were blissful days of a sane Gnome2 desktop and a customizable usplash login screen. Ubuntu hadn't arrived yet and Lennart was still in 'diapers' with only sugarplum dreams of Lendows . . . sigh . . . Ah yes, I saw one once in the Revolution OS documentary. Looks like loads of fun. All those different machines! I can be such a nerd. S... Don't tell anyone! lol! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which desktops work without systemd
On 04/23/2016 04:20 PM, aitor_czr wrote: On 04/22/2016 11:17 AM, KatolaZ wrote: In my opinion there's no magic line where things on one side are window >managers and things on the other side are desktop environments. I think >we can all agree that Unity, KDE and Gnome are desktop environments, >and dwm and i3 are window managers, but what's Xfce? What's LXDE? >What's Openbox? > >I think of de/wm as a spectrum, not a 1/0. I agree with you, there is not a borderline. It doesn't matter how much you agree on an opinion. That will not make it fact. There is a technical difference between the two. Just look up the definition of "window manager" and "desktop environment" on any techsite/dictionary/encyclopedia. Unless you are trying to sound ignorant, it would make sense to use the correct terminology. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] software that sucks
On April 26, 2016 4:36:04 AM GMT+09:00, Mitt Green wrote: > aitor_czr wrote: > >> Seeing that the kde project switched to >> cmake i guess it might be not so ugly aswell. > >I suppose, KDE shouldn't be a role model :) > > KatolaZ wrote: >> Seeing that 90% of free software uses autohell >> I guess it might be not so ugly :) > >These 90% don't know, such an ugly thing they use. >Like Arnt mentioned Windows market share, don't >forget, that systemd is used by 90% nowadays, too. >___ Yes, lets not use appeal to mass AKA the bandwagon technique. It is commonly heard like this: "But Mom, all the kids are doing it." In and of itself is not a reason. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Gtk Development
On April 26, 2016 2:37:42 AM GMT+09:00, KatolaZ wrote: >On Mon, Apr 25, 2016 at 05:36:44PM +0100, Arnt Gulbrandsen wrote: >> kato...@freaknet.org writes: >> >Seeing that 90% of free software uses autohell I guess it might be >not >> >so ugly :) >> >> That's the Microsoft Windows argument: "Seeing that 90% use windows >> it can't be so bad". >> > >My comment was exactly in that direction: the fact that KDE has >adopted Cmake does not make Cmake good per-se ;) > >HND > >KatolaZ > >-- >[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] >[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] >[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] >[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] >___ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Might I interject the reason why they have adopted it is because one of their target platforms is Windows.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] For all you automounter programmers
On 04/28/2016 09:28 AM, fsmithred wrote: You could get the label from lsblk, do 'pmount label' and it will be mounted at /media/label. Every time you plug in a thumb drive labeled backup, it'll go to the same place. If you unmount the drive, /media/label will no longer exist, so you could even have the backup script check to make sure it's there. I am a little bit fuzzy as to what distro did it, but I recall quite a few did. Then along came unmemorable UUIDs. Sometimes I wonder if I am the only one who labels partitions still. Glad to see I am not alone. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beta
On 04/29/2016 04:53 AM, p wrote: Thanks for beta :) Yes! Thank you! It's good to see devuan.org now goes to beta.devuan.org. Good stuff. On 04/29/2016 05:24 AM, Ismael L. Donis Garcia wrote: When you will come out devuan jessie v1.0.0-beta_i386_CD.iso? Me too. I need this for visualization. I hardly ever use a 64bit system when it is visualized. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Mitt Green wrote: >> The current init system is old. Ancient. >> We should all agree on it. Devuan is looking >> for a new init system that is not systemd and my >> personal choice for this task from now on is >> Gentoo's OpenRC. > > Unix is old. Ancient. We should all agree on it. > Devuan is looking for a new base system that > is not Unix and my personal choice for this > task from now is Microsoft's Windows. If there were a prize for the wittiest response, I think that should have it :-) My 2d worth, I agree with earlier comments that the project probably doesn't have the resources yet for such a major undertaking. I'm not saying it's a bad idea, but it's a huge undertaking which means (probably) adding & maintaining a fork/derivative/add-on of every package that uses an init script - and I suspect that for many packages, asking the Debian maintainers if they would please add & maintain the extra init script will be met by "less than co-operative" responses. Yes, certainly think about what's needed, and how best to do it, but for the moment I'd agree that a higher priority should be getting to a "production release" with (at least the appearance of) all the support tools that manglement expect to see behind something they allow on production servers. IMO, at the moment Devuan isn't seen as a "serious" distro - Debian has a long history, plenty of resources behind it, etc, etc. RH and Suse have commercial backing. These things matter to manglement types. Get Devuan to a "complete" and stable (sans SystemD) distro, persuade people to come on-board, and once you've got those solid foundations, then is the time to be getting more adventurous. Trying to do too much too soon risks diluting resources too far and never getting to that critical stage. As I say, just my 2d worth. And written from the PoV of someone who never seems able to learn to not take on too much - and always having unfinished projects and unfulfilled promises :-( ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Wheezy LTS until 2018
KatolaZ wrote: > Many people have kept wheezy on their production > servers to see what happens with systemd in Jessie. And might prefer > to migrate to Devuan eventually, if it has proved to be a credible > option. Put me down in that camp. I've a lot of systems on Wheezy - plus a few on older releases, I'm not one for being on the bleeding edge ! With no disrespect to those who are working hard on Devuan, I'm sitting tight (on my production servers) for the moment to see how it pans out. I really really hope it works out well - which is why I caution against trying to do too many things at once. Stick with the primary objective (being systemd-free) and "prove it can be done" - and then start off from that solid base with other projects (like alternative init system choices). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Jaromil wrote: >> Instead of an openRC effort at this point, I'd rather see a hook >> for apt-get / aptitude / etc, to move all files specific to init >> systems not being used to their own file hierarchies, eg. >> >> /var/cache/init-systems >>/sysvinit >> /etc >> /lib >> /usr >>/openrc >> /etc >> /lib >> /usr >>/systemd >> /etc >> /lib >> /usr > This is an important suggestion, which parazyd himself was evaluating > yesterday, noting that among the errors made in the previous openrc > packages was this one: put the files of each init system in the same > /etc/init.d directory, basically making them overlap. > > I agree we should adopt the policy you are proposing in Devuan. How does that work in terms of getting the right files into place ? Is it a case of the switching process will copy the files into /etc and so on ? Or will they be symlinked, or what ? And possibly more important, what's the process for removing them when switching to another init ? And what about having two systems installed for those who want to try one but leave the other selectable at boot time (for if it doesn't work out ?) I'm thinking back to the "debate" over /bin and /usr/bin and the discussions related to what needs to be mounted early during boot - /var isn't typically mounted until relatively late. From that basis, would it be better to perhaps put openrc scripts in /etc/init-orc or something like that ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan (and Windows)
Steve Litt wrote: > There's a special place in hell for people using ambiguous > abbreviations, acronyms, and nicknames. You mean, like the whole IT industry - and in fact pretty well any industry ? Such terms are routinely used because they make speech and writing less verbose. I did my apprenticeship in an engineering (plenty of acronyms there) firm that was also a supplier to the UK's navy - the defence field is a sea of acronyms* :-) But back to our world, "pen testing" is a common term. A few seconds with ${preferred_search_engine} would come up with a definition. * I was involved in software, and one day for a bit of light amusement decided to fully expand the acronym of something I was working on. Thing is, some of the letters in the acronym were in fact initial of other acronyms, and by the time I'd fully expended all the levels I think a 6 letter acronym became a whole paragraph ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supervision scripts
Rainer Weikusat wrote: > But leaving these two general remarks aside, I don't quite understand > what you wanted to express. That "freedom of choice" is very important - as demonstrated by two posts setting out the reason why (for the poster's situation) the correct option is both one way and the other way. Ie one poster has set out why *for him* not respawning is the only correct way, while the other has set out why *for him* respawning is the correct way. So any system that enforces one or the other, or makes it very difficult to change, is *wrong*. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)
On 05/05/2016 03:18 AM, Stephanie Daugherty wrote: Process supervision is something I'm very opinionated about. In a number of high availability production environments, its a necessary evil. However, it should *never* be an out of the box default for any network-exposed service, Service failures should be extraordinary events, and we should strive to keep treating them as such, so that we continue to pursue stability. Restarting a service automatically doesn't improve stability of that software, it works around an instability rather than addressing the root cause - it's a band-aid over a festering wound. The failure of a service is analogous in my eyes to the tripping of a circuit breaker - it happened for a reason, and that underlying reason is probably serious. Circuit breakers in houses generally don't reset themselves, and either should network-facing services. The biggest concern in any service failure is that a failure was caused by an exploit attempt - attacks which exploit bad memory-management tend to crash whatever they are exploiting, even on a failed attempt. In an environment where such an event has been reduced to routine, and automatic restarts are the norm, that attacker gets as many attempts as they need, reducing one of the first signs of an intrusion to barely a blip on the radar if the systems are even being monitored at all. The second reason is that it will reduce the number of high-quality bug reports developers receive - if failure is part of the routine, it tends not to get investigate very thoroughly, if at all. A third reason is convention and expectation. We've lived without process supervision in the *nix world for almost 4 decades now, those decades of experienced admins generally expect to be able to kill off a process and have it stay down. Please consider these factors in any implementation of process supervision - while it's certainly it's a needed improvement for many organizations,, it's not something that should just be on by default. I couldn't agree more. Some systems I've administered had monitoring daemons, but they would only warn the admin via email and not act automatically. When you are working with many servers, you want to have your own monitoring like icinga for example. I think warning notifications by default are a good thing. On 05/05/2016 05:45 AM, Rainer Weikusat wrote: It greatly reduces the number of "low-quality" (or rather, "no quality") bug reports I receive as I don't (usually) get frantic phone calls at 3am UK time because a server in Texas terminated itself for some reason. Instead, I can collect the core file as soon as I get around to that and fix the bug. NB: I deal with appliances (as developer) and not with servers (as sysadmin). So, for example, would something like daemontools be what you use with your field deployed software? I tend to think that something like automatic restarts are the exception rather than the rule, and so no default support needs to be provided. I would not like to, for example, install apache and mod php and have it restart after it has crashed due to a crappy PHP application. I am of the opinion that is a big security risk. I am sure much thought has been spent on the subject of sane defaults for a server. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: Why I was away.
Edward Bartolo wrote: > Some may think I am insane, but sometimes even the company of a four > legged friend can be beneficial. Not at all, ours is just coming up to 2 year old now. It's fairly widely accepted that pets can be very therapeutic. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supervision scripts
On 05/05/2016 11:11 PM, Rainer Weikusat wrote: Simon Walter writes: [...] On 05/05/2016 05:45 AM, Rainer Weikusat wrote: It greatly reduces the number of "low-quality" (or rather, "no quality") bug reports I receive as I don't (usually) get frantic phone calls at 3am UK time because a server in Texas terminated itself for some reason. Instead, I can collect the core file as soon as I get around to that and fix the bug. NB: I deal with appliances (as developer) and not with servers (as sysadmin). So, for example, would something like daemontools be what you use with your field deployed software? I certainly wouldn't use "something like daemontools" for anything but that's a completely different conversation (my present idea for 'server management' is to implement whatever I need in form of relatively simple 'do one thing and do it well' C programs which can be combined freely to create complex program invocation commands). OTOH, I am convinced that 'automatic restarts' is a sensible policy, especially for background infrastructure servers, as these are usually invisible to users unless they manifest themselves in form of "the internet doesn't work". I understand your position. What I don't understand is what you are suggesting. What are you suggesting should change in Devuan? Are you suggesting that daemon monitoring be included and activated by default? It sounds like to me that you as a developer of custom software have a solution that works well for you. Does that have anything to do with monitoring services and restarting them on Devuan? Are you just anxious to show the other side of the coin that automatic restarts are useful in some cases? Because, AFAICT, that is NOT what is being discussed. I am not the author of apache. So I am not going to make assumptions about when it can or cannot be automatically restarted safely. I know cpanel and WHM have something to handle restarting crashed services. I think that someone, who needs that hand holding, not use a general purpose OS - which Devuan is striving to be. Am I mistaken? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why I was away.
Go Linux wrote: > At the risk of dragging on this OT thread longer than it would have lasted ... I can understand that you consider the topic inappropriate for the list. But generally I'd considered this list a friendly place, where a certain amount of 'banter' would be tolerated. In this case, a list member has explained why he's been absent for a bit - that's not (IMO) inappropriate, and it's not unexpected that he'd get a handful of replies in support. As someone with my own issues (officially diagnosed), and having been in some uncomfortable places (mentally) in the past, I have some sympathy for his problems - and I can vouch for the therapeutic value of four legged friends. Your response is inappropriate in any list, friendly or not. It shows you to be an arrogant and insensitive person, with no concept of what it can be like to have issues - and even less consideration for other persons' feelings and needs. I hope you never get to learn first hand what these issues are like. So next time, just try thinking of others for a change. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supervision scripts
On 05/06/2016 08:05 PM, Rainer Weikusat wrote: Simon Walter writes: On 05/05/2016 11:11 PM, Rainer Weikusat wrote: Simon Walter writes: [...] On 05/05/2016 05:45 AM, Rainer Weikusat wrote: It greatly reduces the number of "low-quality" (or rather, "no quality") bug reports I receive as I don't (usually) get frantic phone calls at 3am UK time because a server in Texas terminated itself for some reason. Instead, I can collect the core file as soon as I get around to that and fix the bug. NB: I deal with appliances (as developer) and not with servers (as sysadmin). So, for example, would something like daemontools be what you use with your field deployed software? I certainly wouldn't use "something like daemontools" for anything but that's a completely different conversation (my present idea for 'server management' is to implement whatever I need in form of relatively simple 'do one thing and do it well' C programs which can be combined freely to create complex program invocation commands). OTOH, I am convinced that 'automatic restarts' is a sensible policy, especially for background infrastructure servers, as these are usually invisible to users unless they manifest themselves in form of "the internet doesn't work". I understand your position. Maybe, maybe not. Rather not, actually. But that's not really important. [...] I am not the author of apache. So I am not going to make assumptions about when it can or cannot be automatically restarted safely. Unless you modify the code, you are (as I already explained) not in the position to decide this ... So I understand you are not really discussing this for the benefit of Devuan but rather to discuss. Thanks for the chat. Take it easy! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] booting old system on a different partition
Peter Olson wrote: > So I cleared out another partition and moved the backup of my Debian 8.3 onto > it. Ran update-grub, which found the backup in its new location. > > But, when I try to boot it grub is confused and is pinned to the old UUID of > the > root filesystem. (I have already updated /etc/fstab in the restored backup, > but > it is not even getting that far.) It just dumps me into busybox saying it > can't > find the root fs. From there, it should, if you know the magic incantation, be possible to manually mount the root fs etc and then continue. I don't know the magic incantation - perhaps ${pref_search_engine} will help. But from a step back, at the grub menu, you can opt to edit (it's not persistent) the config - so you go and replace "root= " with "root=sdxn" which should allow it to boot. Or, you can boot your normal system, list the UUID, write it down, and edit it into the grub config at boot time. All this is why I much prefer filesystem labels (you can put "root=LABEL=oldroot" in the grub config to boot it) - and it's annoying that (at least in Debian) the only options are UIDs or device names. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] hashtag retarded
On May 9, 2016 7:40:50 PM GMT+09:00, Jaromil wrote: > >TL;DR some people find it cozy to stay here, therefore dng will keep >existing, but if you don't like it, there are more options with less >"noise". > > >On Mon, 09 May 2016, Teodoro Santoni wrote: > >> In this mailing list there has been a peak in things >> I don't care about, during recent weeks. > >this list is the first firecamp out of town after the debianfork >diaspora. I don't think we can nor should change it in any way. >But your concern is shared by many, especially newcomers. > >That's why we have created a forum https://talk.devuan.org which >allows FAQ style publishing, wiki pages with comments and >categorization and reputation metrics. > >plus for the e-mail aficionados two new mailinglists: > >one for devuan related discussion (OT will be moderated there) >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-discuss > >and one for those who want just to receive the important announcements >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-announce > >I encourage you and everyone else willing to review your subscriptions >in order to make your own experience in Devuan more pleasant. If you >like you can unsubscribe from here at this link >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > >and the subscribe one of the above, with my recommended preference for >https://talk.devuan.org since materials posted there will contribute >to the community-made documentation in Devuan. > > Fantastic. Thank you! There is so much in the right direction day after day. Much appreciation. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Brief OpenRC/Jessie Discussion on the linux-elitists lists
emnin...@riseup.net wrote: > Please do not take my question wrong (probably i am missing something): > If it's that way, how can devuan then rely on debian as for packages > etc.? At least in a forseeable future ... ? The thing is that Debian is already there, pretty well complete, and the majority of packages don't need fixing. I don't know how well you've followed some of the threads (and web pages linked to), but many of the problems are of the form : package A depends on package B, package B depends on package C, package C depends on ..., and package X depends on systemd - often in a very minor way. So indirectly Package A depends on SystemD, even though you might not be wanting to use any features of Package X that caused the dependency in the first place. In this case, it's a matter of looking at Package X and determining what (if anything) it needs SystemD for and either removing the dependency or figuring out a way of providing the needed functions without using SystemD. Thus un-corrupting Package X allow Package A to be installed without modification. Of course, packages A, B, C etc may not be single packages, they might be whole suites of (say) desktop software - so fixing a small number of packages preventing the desktop environment installing could open up hundreds of packages with no direct dependency - and which don't need any "fixing" to be used. As long as Devuan can survive the short term, over time it'll deviate more and more from Debian, and rely less and less on Debian packages. But in the short and medium term, it can use all those packages that are already there, already packaged, and that saves a lot of effort for what is currently a very small team with limited infrastructure. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] You might have seen this already...
On 05/28/2016 09:55 PM, Rainer Weikusat wrote: This means the leading sentence would be more appropriately worded as "In my opinion, it's actually quite strange that UNIX(*) enables users of the system to run background jobs". Well put! On 05/29/2016 02:48 AM, Steve Litt wrote: I see poettering's point, but it's just not a problem for me. I don't use a desktop environment that, without my permission or knowledge, starts tens of processes in my behalf. For the most part, when a process is started in my behalf, I personally started it from a command prompt, Dmenu or UMENU. So I can choose whether or not to close it before logging out. I think this is Lennart's biggest failing. He is trying to make a traditionally server OS into an entertainment system. Face it, most people these days use their devices for entertainment - not work. So it's not even fair to say that systemd is useful for workstations. Every bit of this was predictable from the moment we learned about systemd's architecture. Gratuitous component intercommunication leads to ever worsening problems. A system with gratuitous component intercommunication is so complex that it's difficult to predict exactly what those problems will be, but it's a certainty those problems will occur. It's also scope creep, which is diametrically opposed to "one tool for one job". Some of the comments on that list were interesting: "...who in turn will finally get annoyed at systemd." It's like they understand the problems associated with systemd but are committed to it. So now they have to protect their decision - making their relationship with systemd more emotional than logical. I am not afraid of change, yet, experience has shown that consensus is wonderful. Lennart doesn't seem to understand that. I am so glad that there are people with, shall we call them, traditional (unix) values still on this planet. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] You might have seen this already...
On 05/29/2016 03:20 PM, Edward Bartolo wrote: After all, it is money that counts. I am of the opinion that it is veracity that counts. I am also of the opinion that there are many who share the previous opinion with me. Therefore not all software will cater to the ignorant. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] You might have seen this already...
On 05/29/2016 04:13 PM, Edward Bartolo wrote: Hi, The last statement is not an expression of my opinion but sadly what the majority think. Yes, I too hold the belief that 'veracity' is of prime importance. Edward, I am glad you clarified that and I am glad to be in such good company! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What's the correct place for backgrounds, wallpapers etc.
On 06/02/2016 12:10 AM, Go Linux wrote: On Wed, 6/1/16, hellekin wrote: Subject: Re: [DNG] What's the correct place for backgrounds, wallpapers etc. To: dng@lists.dyne.org Date: Wednesday, June 1, 2016, 1:23 AM You may also install desktop themes in your user's $HOME: ~/.themes/foo == hk True but then root apps like synaptic and gparted won't be themed properly. To work across the board themes should go into /usr/share/themes. ;) golinux Aha! I never knew there was a way "fix" that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] SoylentNews discussion
Steve Litt wrote: > My opinion: If the init specification of a daemon exceeds 25 lines, > that's a problem. Many sysvinit and OpenRC daemon init specifications > are over 100 lines, especially if you take into account all the stuff > imported from the "functions" file. I never want one of those long > files darkening my door again. Playing devils advocate ... What's the difference between importing a few functions and using them, vs embedding that functionality in some C code ? That seems to me to be one of the big differences between SysVinit and SystemD. In a SysV init script you have a few lines which setup the requirements and call a function to start the daemon. In the other one, you have a few lines that setup the requirements, and then hand over to some black box. The problem with SysV init scripts isn't what people are making it out. As has been pointed out many times, a lot of that bloat isn't there because SysV needs it - it's there because ... well "it's there" ! They really can be quite short and compact - once you weed out the stuff like LSB metacode to control which runlevels it runs in, prettifying output, and stuff like that. But what is needed, after you've taken the stuff out that really isn't inherent in SysV, is IMO better than passing a few arguments to some black box binary that can't be debugged. As someone else pointed out, with a shell script you've got somewhere to stick your voltmeter. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] ifconfig vs ip
Hi All, I am working on some cdist scripts for setting up some network interfaces. So far I am modifying the /etc/network/interfaces and then bring down and up the interfaces. For a while now /etc/init.d/networking has a warning that it is deprecated. I understand why. So I issue: # ip address flush dev xxx && ip link set xxx down Which seems to work fine. However, when I try to bring the device back up with the new config with "ifup xxx" It fails. If I first issue a "ifdown xxx" then it works. So I have couple questions for those who know about the situation in De*an: 1. Is there a plan to move away from ipconfig? 2. Is there a plan to write a /etc/init.d/networking script that works properly? 3. Is ifup unrelated to ifconfig and will continue to live and be used in the De*an ecosystem? 3. For my project: How does one bring up and down interfaces with ip in coordination with /etc/network/interfaces? Or shall I use ifup? Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Top100 on DistroWatch
On 06/03/2016 01:55 AM, KatolaZ wrote: > On Thu, Jun 02, 2016 at 06:27:43PM +0200, Jaromil wrote: >> On Thu, 02 Jun 2016, Joel Roth wrote: >> >>> Actually, the news doesn't even have to be good. There's nothing >>> like an engineered controversy full of flames, to gain interest of >>> the press. >> >> sad, but true in most cases. >> >> anyway the main cornerstone for Devuan beta2 will *not* be a media >> stunt :^) we have to make some fixes, consolidate the infrastructure >> and last but not least include properly the fine look of the default >> desktop that golinux and hellekin have made. >> > > Flames fade away, and leave little good behind, if anything. It would > be far better for Devuan to focus on facts, rather than on opinions. > Yes, I totally agree. "There is nothing hidden that will not be revealed." Which is why open source trumps closed source. Which is why many people see through Redhat and their greedy moves. Here is another little "fact" I came across: https://wiki.debian.org/LXC#Incompatibility_with_systemd Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] SoylentNews discussion
On 06/03/2016 06:45 AM, Jaromil wrote: > however this is all abstract speculation now. I'm not even sure we'll > make such a big change in testing. most people and organizations > switching to Devuan today (me included) are in need of a system that > does not change their workflow arbitrarily. On 06/03/2016 06:57 AM, Steve Litt wrote: > But like you say, this decision is a long, looong way off. Very sensible. Thank you! People "at the coalface" appreciate this. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/03/2016 04:43 PM, Adam Borowski wrote: > On Fri, Jun 03, 2016 at 08:56:50AM +0900, Simon Walter wrote: >> I am working on some cdist scripts for setting up some network interfaces. >> >> So far I am modifying the /etc/network/interfaces and then bring down >> and up the interfaces. For a while now /etc/init.d/networking has a >> warning that it is deprecated. > > /etc/init.d/networking is not deprecated, only calling it with the argument > "restart" (="force-reload") is. There's no real way to do that reliably in > any non-static setup. OK. I see. So it's only with restart. Got it. By non-static is that only dhcp or are there other non-static setups? I would imagine a dhcp setup would restart fine, but maybe I am such a simple user. > ifupdown keeps its state in /run/network/ifstate, if you bring devices up or > down using low-level tools then ifupdown may get confused. Use --force to > override the saved state. Nice. >> 2. Is there a plan to write a /etc/init.d/networking script that works >> properly? > > What do you mean by "properly"? What's your problem with it? Well, considering I misinterpreted the part where only "restart" was deprecated, I suppose if restarting is not possible, then fine. >> 4. For my project: How does one bring up and down interfaces with ip in >> coordination with /etc/network/interfaces? Or shall I use ifup? > > Don't try to mix the two -- or rather, you may use ip safely for > configuration (like, changing addresses, routes, etc) but not bringing an > interface up or down. If ifupdown doesn't fit your needs you can simply > omit that interface in /etc/network/interfaces or let it bring it up during > boot and never touch it again. Unlike, say, network-manager, ifupdown will > not mess with the interface unless either you or udev explicitely tell it > so. Thanks man. I don't know why there would be network-manager install on a server, but we live in such a entertainment world. It's good there are others striving for a professional OS. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/03/2016 11:23 PM, Rainer Weikusat wrote: This stop-modify-restart is a bit coarse-grained and it's also possible to do this manually without 'interface downtime' but there's no general interface for that: The sequence of commands will depend on both the running configuration and the desired configuration and has to be worked out beforehand and then executed. Considering that the modified interfaces file can be created before causing any side effects and then be swapped atomically via mv in between the down and the up, 'play nice with the system' is IMHO a better idea. Changing the stored configuration while the interface is up bound to cause trouble unless care is taken to ensure that this can be interrupted at any point (imagine a sudden power outage) with the system still remaining in or capable of returning to an operational state. Yes, I 100% agree. Thank you for the detailed info. I am trying to do it like that (using the interfaces file). However, cdist has some limitations in it's default usage pattern regarding "down-mod-up". Of course since it's connecting over the network, I need to be careful what NICs go down and how they are reconfigured. I think I've hit on something. Since I am adding containers (LXC) and virtual network to the box, I think I will add an tap and bridge interface to an /etc/network/interface.d/ file. If I use something like: auto br0 iface br0 inet static pre-up ip tuntap add dev tap0 mode tap pre-up ip link set tap0 up post-down ip link set tap0 down post-down ip tuntap del dev tap0 mode tap bridge_ports tap0 address 10.1.1.1 netmask 255.255.255.0 broadcast 10.1.1.255 And make sure there is the source /etc/network/interface.d/* line in the interfaces file. Then route with iptables between the a physical NIC (eth0 for example) and the virtual NIC (tap0) and have all the containers connected to br0. Are there any glaring problems with this setup? Thanks everyone again for all the advice and explanations. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init compatibility
On 06/04/2016 04:27 PM, Steve Litt wrote: I always feel a lot better when I can singlehandedly fix what goes wrong with my possessions. Here here! Give this man a beer! I usually use both hands, but I do know what you mean. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init compatibility (was: SoylentNews discussion)
Florian Zieboll wrote: > Seriously, what else besides dependencies on other daemons that have to > be running and some testing for the existence of certain (everything is) > files would be necessary to pass to a parser script, which could be > packaged with the respective init system? Are we in danger of removing one of the great benefits of the shell scripts used by sysvinit - the ability to code pretty well anything that's needed. I realise that this also means the scripts can tend to "sprawl", but it gives great flexibility - including for local modifications. So for example, a database init script can go further than just checking that the daemon has started, it can run specific queries against the database to determine that it's actually ready to serve queries before returning "started". I believe MySQL does this - hence a sprawling script. For local modifications, it may be desirable to check that a service is running on a remote host before starting. For example, I have a small mail server cluster that uses a single policy daemon running on a backend machine - although I haven't done it, it would be fairly easy on the shell script to wait for that service to be available before starting Postfix. While both of these could be handled with a set of "before starting", "after starting", etc type hooks to call external scripts - IMO we're then into an even worse situation where you have a config file feeding into the block box of hidden logic AND have one or more scripts containing exactly what people are criticising SysV for. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init compatibility (was: SoylentNews discussion)
Steve Litt wrote: > In all daemontools-inspired process supervisors, dependency handling, > if you indeed need it, is just this easy: > > == > #!/bin/sh > if ping ; then > exec /path/to/app_depending_on_network > fi > sleep 1 > == > > In the preceding, if the ping succeeds, the run script is replaced by > app_depending_on_network. If the ping fails, after 1 second the run > script finishes, at which time or soon after, daemontools will try it > again. There is an argument for doing everything that way. IIRC it was discussed in here, I know I've seen it discussed elsewhere, but there are inherent problems with the "classical" dependency model - namely that "ready" is often a nebulous thing, and may only be transient. A classic example of that is networking. When is "the network" ready ? When the first ethernet port is active ? When a WiFi port is active ? When a PPP link is up ? When you can actually ping "something on the internet" ? Something else ? In the general case, it's absolutely not possible for a generic supervisor, running a generic config, to know that for every combination of networking that people could come up with. And of course, what if an interface goes down ? So logically, anything that relies on "networking" being active should have (probably installation specific) checks to determine for itself when there is sufficient networking available. And of course there are (these days) very often dependencies outside of the host that's starting up - eg no point starting the mail service if the back end database it needs isn't available. So if every "something" was made responsible for working out when it's dependencies are met, startup sequencing becomes "fire up everything" and leave them to it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init compatibility (was: SoylentNews discussion)
Florian Zieboll wrote: > i was not talking about replacing sysvinit's shellscripts, but suggest > to implement a routine that creates them "on the fly" on installation > of a new daemon, from /one/ init-independent "meta" configuration file, > packaged with the daemon. OK, my experience in this is limited, but whenever I've seen a "conversion routine from language A to language B" setup - the restrictions on language A (to avoid the parser being chronically complicated) are severe and the output in language B is "not user readable". I wonder if it would actually be easier to write the different init scrips/definitions manually - thus using the best features of each system without the compromises of shoehorning it al into one common meta script. I can see a case for doing automated conversions on "simple" and generic cases, but I can't help thinking that many would be better done by hand. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] man init
On 06/04/2016 09:39 PM, Didier Kryn wrote: Le 04/06/2016 14:00, Nate Bargmann a écrit : * On 2016 04 Jun 04:52 -0500, Jaromil wrote: On Fri, 03 Jun 2016, Joel Roth wrote: My system is devuan/jessie, upgraded from debian. It's interesting that 'man init' brings up the systemd man page. strange! I don't have that on my laptop (installed from devuan directly) but will check on other systems. curious why this occurs. well spotted On this desktop upgraded from Debian Jessie to Devuan Jessie about a month ago, 'man init' gives me the page for sysvinit. Only libsystemd0 is installed. Any other search for systemd shows uninstalled packages. - Nate Same as Nate on a fresh install of Beta two weeks ago. No problems here: #uname -a Linux i7 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux #cat /etc/devuan_version jessie Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/05/2016 12:16 AM, Rainer Weikusat wrote: Simon Walter writes: [...] I am adding containers (LXC) and virtual network to the box, I think I will add an tap and bridge interface to an /etc/network/interface.d/ file. If I use something like: auto br0 iface br0 inet static pre-up ip tuntap add dev tap0 mode tap pre-up ip link set tap0 up post-down ip link set tap0 down post-down ip tuntap del dev tap0 mode tap bridge_ports tap0 address 10.1.1.1 netmask 255.255.255.0 broadcast 10.1.1.255 And make sure there is the source /etc/network/interface.d/* line in the interfaces file. Then route with iptables between the a physical NIC (eth0 for example) and the virtual NIC (tap0) and have all the containers connected to br0. Are there any glaring problems with this setup? This will create a bridge with one virtual network interface bridged to a character device an application could use to talk 'ethernet' to the network stack. That's certainly not inherently related to/ useful for anything-lxc. I will route the packets to the physical device using iptables, thereby creating a firewalled private network. I have only tried it out and not done much research and testing on whether this is actually secure or not. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/06/2016 08:48 PM, Rainer Weikusat wrote: Simon Walter writes: On 06/05/2016 12:16 AM, Rainer Weikusat wrote: Simon Walter writes: [...] I am adding containers (LXC) and virtual network to the box, I think I will add an tap and bridge interface to an /etc/network/interface.d/ file. If I use something like: auto br0 iface br0 inet static pre-up ip tuntap add dev tap0 mode tap pre-up ip link set tap0 up post-down ip link set tap0 down post-down ip tuntap del dev tap0 mode tap bridge_ports tap0 address 10.1.1.1 netmask 255.255.255.0 broadcast 10.1.1.255 And make sure there is the source /etc/network/interface.d/* line in the interfaces file. Then route with iptables between the a physical NIC (eth0 for example) and the virtual NIC (tap0) and have all the containers connected to br0. Are there any glaring problems with this setup? This will create a bridge with one virtual network interface bridged to a character device an application could use to talk 'ethernet' to the network stack. That's certainly not inherently related to/ useful for anything-lxc. I will route the packets to the physical device using iptables, thereby creating a firewalled private network. I have only tried it out and not done much research and testing on whether this is actually secure or not. You don't need the tap port for that, the bridge will happily work without any ports statically assigned to it. And will I be able to set up iptables with just the bridge? I was thinking of using shorewall. I've never used it before, but it seems like it's configuration is easy to maintain. Therein lies my concern. There are zones with interfaces for each zone. For some reason I thought a bridge needs to at least have one interface that it is bridging for it to be up. Can I bring a bridge up and do iptables stuff with it having no interfaces that it bridges? The machines I'm dealing with use a bridge as 'main interface' a principally arbitrary number of (lxc) containers connect to via veth with one physical interface also assigned to the bridge to provide actual connectivity. It's also possible to do packet filtering between bridge ports if that's considered to be desirable/ useful. I want to filter packets between physical NIC (WAN, eth0) and a virtual internal network (LAN, br0/tap0???). I am basically creating an isolated virtual network with virtual machines all inside one machine. Each container will have just enough software to carry out it's place in the network. Thereby isolating everything as much as possible, allowing for independent updates, modifications, hotswaps, etc. 'Introduction site' http://ebtables.netfilter.org/ One of the advantages of ip(route) over the older, BSD-style tools is that they can be used to assign an arbitrary number of protocol addresses to a single interface without employing 'interface aliases'. Good to know. Thank you! Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
Simon Walter wrote: >> You don't need the tap port for that, the bridge will happily work >> without any ports statically assigned to it. > > And will I be able to set up iptables with just the bridge? I was thinking of > using shorewall. I've never used it before, but it seems like it's > configuration is easy to maintain. Therein lies my concern. There are zones > with interfaces for each zone. For some reason I thought a bridge needs to at > least have one interface that it is bridging for it to be up. Can I bring a > bridge up and do iptables stuff with it having no interfaces that it bridges? In Shorewall you would declare the bridge as the interface for a zone. Note that Shorewall will filter packets in/out of that interface - not between interfaces in the bridge. >> want to filter packets between physical NIC (WAN, eth0) and a virtual >> internal network (LAN, br0/tap0???). I am basically creating an isolated >> virtual network with virtual machines all inside one machine. Each container >> will have just enough software to carry out it's place in the network. >> Thereby isolating everything as much as possible, allowing for independent >> updates, modifications, hotswaps, etc. How you want to do this affects the answer ! If you want to route traffic between two (or more) bridges, then you just declare each bridge as an interface for Shorewall and define the policies/rules for traffic between them. This can be done either in the host, or (as I have it) as a small VM running as a 2 port router. If you want to do inter-port security within the switch then that's a bit harder and not something I've done. I think you can probably only do that with ebtables - and of course you have the dynamic nature of the interfaces to consider. For Shorewall specific questions you'd be better asking over at Shorewall Users shorewall-us...@lists.sourceforge.net ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
Adam, Rainer, Simon, Thanks guys. I thought I knew what I was doing, but now I think I might be able to execute this better with all of your advice. Cheers, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] resolved
On 06/07/2016 05:45 AM, Jim Murphy wrote: On Mon, Jun 6, 2016 at 2:23 PM, Klaus Hartnegg wrote: All programmers please read this, and treat it as a list of things not to do. https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html Systemd manages to shoot itself in the foot, and in the elbow, and trigger a timebomb, all with one single bullet. Did anyone follow the "systemd blob" link(within the above mentioned link) and read any other points including -logind? This apparently prompted a bug[1] on Debian that turned into a somewhat long discussion within the bug messages. It appears that Debian wanted to turn on, as default, the clean-up feature on logout. If I read it correctly it would kill background processes when you log out. This would result in killing, among other things, a detached tmux process or a long running background processes that in the past would have remained running. So maybe the average user won't be concerned. :( [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 Yes, that "clean-up" feature was mentioned and discussed and pretty vomited on - for obvious reasons. Which is why, and I repeat myself, I am so thankful for everyone here. Not everyone drank the coolaid! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan installer and overheating
On 06/07/2016 02:45 PM, emnin...@riseup.net wrote: Finally i succeeded in installing a devuan ascii into qemu (running on an archlinux openrc system). And here too, i noticed that the debian installer is somehow "extreme" in using ressources. Note this is *NOT* an amd graphics based machine but a sony_vaio with nvidia graphics. (On another laptop, a samsung with amd processor and graphics, i could not get installed devuan until i did not put the machine on top of an icepack!!!). But nevertheless, installing devuan also this vaio heats up to something like 85° - but it has a stronger fan than, so the process went through. I'm wondering why this problems do not happen with installers of other distros. If this is repeatable for others too, may be, if some one is able and prepared to do that, it might be good to check, if there is a reason why (?) I have not noticed this. What are the models of your notebook computers? You could do everyone a favour and debug it a little. Do you know which process was spinning the CPU? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to acknowledge ported version of Open Source program?
On 06/07/2016 02:51 PM, Hughe Chung wrote: I've been porting an Open Source program to Python 3.4 for my personal use. The original source code written by C language in 2005 has MIT license. ... I'm planning to release it under GPLv3 soon. I will definitely acknowledge original author on the license but don't want to include the ancient source code in my program. I think it depends on how much you copied and how polite you are. You can say "inspired by", but if your code is structured the same and it really is a port, I think you might want to word it differently. Though I don't think you need to include such a notice in your source code. If you are naming it the same and calling it a Python version, then maybe coordinate with the original author. That's just my opinion. I am not a lawyer. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] resolved
On 06/07/2016 03:47 PM, Jaromil wrote: sorry for abstracting the topic, but I definitely see a pattern in many contexts. I could bring forward more arguments on why this happens in the technology industry at a time in which material production techniques reached an innovation peak after 2 decades of incredible acceleration. I am interested in your (and everyone's) musings on the subject. In my circle, it is heresy. I suppose I am seeped in the corporate culture and find open discussions invigorating. I do think (was it Mr. Litt that said of) Redhat has a part to play. How much of that the you es ay spy agencies were involved is speculation. I'd love it if some info was leaked. It would cause everyone to be much more critical, think twice, and review code more. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] resolved
Steve Litt wrote: > I'm all for corporations making money. I get paid, why shouldn't they? Indeed. I find it "interesting" to hear some people suggesting they shouldn't have to pay for anything - and think that if anyone suggested they shouldn't get paid for whatever they do/produce then they might have a different view ! Also bear in mind that a lot of what is "free" is only free and there because "someone else" actually paid for it - just look at how many of the major projects are led/staffed by people employed by various technology companies to produce the "free" stuff. Eg, while we may deride RH (especially over SystemD), it's true that their paying customers do indirectly pay for some of the stuff we use for "free". I personally know someone employed by them to work on virtualisation - IIRC he works on improvements to things like Qemu. Of course, we know that a lot of people work on this in their own time - but we assume that they are still either employed, or getting a pension, or getting some other form of support in order to pay the bills, keep a roof over their head, and put food on the table. > But what if I owned a bicycle shop, and furnished bicycle thieves > with bolt cutters and five bucks for every bike they boosted, so that > the recently ripped off would buy a new bike from my shop? That's > basically what Redhat's doing: Destroying Linux to make their training > and consulting more valuable. That does seem a good analogy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] resolved
KatolaZ wrote: > Despite being originally intended as a "guerrilla weapon" (and RMS and > the others were very careful at designing it), copyleft is indeed the > only way to keep free software free, forever. Indeed. I've heard a few descriptions of RMS - most of them uncomplimentary. Having met him, I can see why many people dislike him - he does come across very much as the stereotypical geek with no social skills (mind you, me writing that does involve a certain amount of "pot, kettle, black" - fill in the rest !) I can understand his POV, though I'm very much in the pragmatism camp and use a mix of free and closed software. But, I respect his position - and I respect the fact that without people like him, we would not have the freedoms we have now. That's important to remember. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] resolved
On 06/07/2016 06:59 PM, Simon Hobson wrote: Steve Litt wrote: I'm all for corporations making money. I get paid, why shouldn't they? Indeed. I find it "interesting" to hear some people suggesting they shouldn't have to pay for anything - and think that if anyone suggested they shouldn't get paid for whatever they do/produce then they might have a different view ! Also bear in mind that a lot of what is "free" is only free and there because "someone else" actually paid for it - just look at how many of the major projects are led/staffed by people employed by various technology companies to produce the "free" stuff. Hold on. I must interject. Not all programmers are equal. Some are so skilled that to write up a piece of software and maintain it just for themselves, is not as difficult as it is for someone like me. If a hobbyist or professional cannot get the parts s/he needs because the information on the package is incorrect in some way, then some resort to DIY. It is this group of DIY hobbyists and professionals and their vision gave us open source software. Others in other replies have mentioned some of the pioneers. I respect and admire them and their fortitude. It doesn't much to do with producing something directly for sale. The motivation to produce superior parts might be to enable one to do ones job better, but those parts were not originally for sale. Redhat is taking those and selling support for them. Great. Nice. Good. But then when they start the systemd BS, all the comments about them having greedy ulterior motives start to make sense. The freeloaders will never care. After all, they are comfortable with the theft of software. Eg, while we may deride RH (especially over SystemD), it's true that their paying customers do indirectly pay for some of the stuff we use for "free". I personally know someone employed by them to work on virtualisation - IIRC he works on improvements to things like Qemu. Yes. My brother works for RH and feeds his children with that money. I still don't care for RH. I never have and never will. RPM hell may have been intentional. Just like MS doesn't fix horrible bugs because they make good money off of support. Knowing someone in an organization doesn't make it a good organization. Of course, we know that a lot of people work on this in their own time - but we assume that they are still either employed, or getting a pension, or getting some other form of support in order to pay the bills, keep a roof over their head, and put food on the table. My first paragraph applies. Only freeloaders are asking for a handout and those people do not matter to us anyway. Money is no justification for nefarious action. My biggest gripe with systemd: How many man hours have been wasted and will be wasted. There is an lack of wisdom in that project. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan installer and overheating
On 06/07/2016 07:38 PM, emnin...@riseup.net wrote: Am Tue, 07 Jun 2016 08:33:08 + schrieb Simon Walter : I have not noticed this. What are the models of your notebook computers? You could do everyone a favour and debug it a little. Do you know which process was spinning the CPU? a Samsung NP535U3C (amd processor and graphics) a Sony Vaio VPCF23S1E (Intel Core i7-2670QM (-HT-MCP-) NVIDIA GF108M) It always happened when it came to install the software tasks (desktop, printserver, etc) - apt i'd presume. The fans are going crazy. At first i thought it might be a problem related to the amd/ati graphics which unfortunately do not work fine with the free driver. But now, i realized this also on the Sony Vaio which has nothing to do with amd. But indeed, on the Vaio it was a qemu installation - but otoh, just to check, i compiled libre office from source and the machine never got hotter than 60°. Installing Jessie in qemu the top heat was 87°! (How can i debug the installation?) Well, those are certainly powerful enough machines. Do you have a very fast Internet connection? I would assume the fans go crazy, but unless your room is very hot and the machines full of dust, they should not crash from overheating. Let me see... OK first of all, at least on the version I have (devuan-jessie-i386-alpha4-netboot.iso) there is no graphical installer. So it's most likely nothing to do with your graphics chip. Second of all, there is no top on the installer and the busybox version of ps that is on the installer is completely striped down. So you may have to resort to parsing /proc to find the misbehaving process. That being said, I don't know if I should say that you should write a shell script to parse that info or if you should pick through it by hand. It might be simpler to cp top from a compatible installation and use that to find the misbehaving process. Once you find that, then you will know basically what is going on. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan installer and overheating
On 06/08/2016 12:15 PM, Simon Walter wrote: On 06/07/2016 07:38 PM, emnin...@riseup.net wrote: Am Tue, 07 Jun 2016 08:33:08 + schrieb Simon Walter : I have not noticed this. What are the models of your notebook computers? You could do everyone a favour and debug it a little. Do you know which process was spinning the CPU? a Samsung NP535U3C (amd processor and graphics) a Sony Vaio VPCF23S1E (Intel Core i7-2670QM (-HT-MCP-) NVIDIA GF108M) It always happened when it came to install the software tasks (desktop, printserver, etc) - apt i'd presume. The fans are going crazy. At first i thought it might be a problem related to the amd/ati graphics which unfortunately do not work fine with the free driver. But now, i realized this also on the Sony Vaio which has nothing to do with amd. But indeed, on the Vaio it was a qemu installation - but otoh, just to check, i compiled libre office from source and the machine never got hotter than 60°. Installing Jessie in qemu the top heat was 87°! (How can i debug the installation?) Well, those are certainly powerful enough machines. Do you have a very fast Internet connection? I would assume the fans go crazy, but unless your room is very hot and the machines full of dust, they should not crash from overheating. Let me see... OK first of all, at least on the version I have (devuan-jessie-i386-alpha4-netboot.iso) there is no graphical installer. So it's most likely nothing to do with your graphics chip. OK, well, I just tried the new BETA. It does have a graphical installer. You might want to try the text version and see if there is any problem with that. I don't know why there is a graphical installer. My opinion is that If it's not taking up too much developers time, then great, but it's really not necessary. Hopefully no one is spending much time on it. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to acknowledge ported version of Open Source program?
On 06/07/2016 09:35 PM, Arnt Karlsen wrote: On Tue, 7 Jun 2016 15:31:31 +0900, Simon wrote in message <57566a43.4050...@gikaku.com>: On 06/07/2016 02:51 PM, Hughe Chung wrote: I've been porting an Open Source program to Python 3.4 for my personal use. The original source code written by C language in 2005 has MIT license. ... I'm planning to release it under GPLv3 soon. I will definitely acknowledge original author on the license but don't want to include the ancient source code in my program. I think it depends on how much you copied and how polite you are. You can say "inspired by", but if your code is structured the same and it really is a port, I think you might want to word it differently. Though I don't think you need to include such a notice in your source code. If you are naming it the same and calling it a Python version, then maybe coordinate with the original author. That's just my opinion. I am not a lawyer. ..11 years with Groklaw.net has thaught me to be a little harsher; you cannot "port" a program written under one license (MIT), under another license, unless that first license has language that allows such "relicensing" under other licensing terms. The MIT license must be retained. Though it does say you can sub-license. Since Chung's new version is written in Python, wouldn't it be considered a different piece of software? I don't think a re-write in another language of something licensed under the MIT license can even be considered a derivative, much less a copy. I think a port is normally considered what you do when you recompile code for another architecture. (https://en.wikipedia.org/wiki/Porting) says so. I am aware that some say, "port such and such to PHP," but I think that is technically incorrect. "The term is not generally applied to the process of adapting software to run with less memory on the same CPU and operating system, nor is it applied to the rewriting of source code in a different language <https://en.wikipedia.org/wiki/Programming_language> (i.e. language conversion or translation)." Of course Wikipedia is not the authority on all knowledge. ;) Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Killing background processes on logout [was Re: resolved]
On 06/08/2016 07:49 PM, KatolaZ wrote: [sorry for the long reply] Very well put. Killing all the processes at logout should be easily doable using cgroups (which existed much before Poettering got his bachelor degree), and is indeed easily doable with screen, nohup, and hundred of similar amenities. Those *mechanisms* exist already, and new ones can and should be introduced as needed, to complement the existing ones, so that they can be combined in thousands of different new ways, to serve the needs of different and emerging use cases. But it is not possible to enforce the policy "all the processes that want to survive have to use a precise mechanism", which in the meanwhile breaks backward compatibility with other mechanisms and other policies. This is not innovation. This is just breaking things for the sake of it. IMHO, systemd should probably be called gnomed and then employ all the well known, well documented APIs of the system(s if it is to be useful on other OS that Gnome might run on) to do it's thing. By not employing those existing mechanisms, the authors of systemd are guilty of moving Linux systems farther away from POSIX and Unix then they already are. Linux might not be a true Unix for a few reasons, but those reasons have been deliberated over and there is no need to be in a hurry to break things. If it were not for projects like Devuan, Linux may really become something a Unix user cannot use comfortably and/or fluently. I should not have to learn to drive again just because the engine of a car has become more efficient. To the business man, it might make sense to put forth this excuse, because he gets to rip you off, but to the rest of us it is what is called sh177y engineering. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to acknowledge ported version of Open Source program?
Jack L. Frost wrote: > Yeah, I was going to say that too: a rewrite in another language is a > completely new piece of software ... I wouldn't be too sure. It will vary considerably on the details. At one extreme, you look at what the original is doing and write new code to do the same manipulations on data - but in your own way. *Probably* OK. At the other extreme, you look at what the source is doing and merely "translate" that into another language making minimal changes. *Probably* not OK. Not to mention, in many jurisdictions, people can't assume they can afford to win in court ! I'd suggest the sensible way is, as already suggested, to contact the original developer/copyright holder. If it's a single person, they may be happy to extend the licensing anyway and completely remove any debate or risk. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Killing background processes on logout [was Re: resolved]
Edward Bartolo wrote: > One strategy would be to deny > server access to anyone not using systemd. This would force Devuan to > set up an entirely independent infrastructure. I think, this may do > some serious disruption: be prepared as Devuan is not yet totally > divorced from Debian. I suspect that even for the most rapid of systemd fanboys, getting your licence to use GPL software revoked* for breaking the terms of the licence is probably going over the line. * And then, getting all your US based infrastructure shut down when your hosting companies get DMCA requests over the (now) illegally distributed software. Yes, as said before, the GPL and "copyleft" is indeed a powerful weapon. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Killing background processes on logout [was Re: resolved]
On 06/09/2016 07:07 AM, Dan Purgert wrote: Didier Kryn wrote: [snip] I cite: "Systemd and cgroup developers are working together to turn systemd into a global cgroup manager that creates higher-level control knobs and prevents direct access to the kernel. Many Systemd changes are already released while cgroup changes are set to be merged into the upstream kernel. Much work still remains, however." Yet another thing that systemd is getting its tentacles into ... wonder when the majority of users will say "enough is enough" with it? They will not. The majority of users are freeloaders. So we may end up using a BSD. But not today. GNU/Linux is still available. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Killing background processes on logout [was Re: resolved]
linuxvoice.com/interview-lennart-poettering It's an old article, but as I read, I realized how much I disagree with Lennart. TBH, he sounds like an Apple fan. Now we get controversial, because those who like to feel smart, yet don't know much, feel empowered by AI. Those who don't feel smart, but want to be smart, don't like AI, because it means they can't learn. Admins and technicians alike need to be able to know what is going on. So we hate AI. I hate it when a handful of the desktops in an office running Windows >XP decide that the network is unsafe and just deny access somehow with some undocumented mechanism. I can ping. I can resolve. But none of the desktop programs work because of the yellow exclamation mark. Some command line fu to force the system into a state, and we're back in business. A few choice quotes: "The Unix misconception is a pretty interesting one, because most people who say Systemd is un-Unixish have no idea what Unix is actually like. What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was!" Nice one pulling the wool over the reporters eyes. What people mean by un-Unixish has nothing about releasing code and coding style. It has everything to do with one tool for one job. Lennart knows this and he is being intellectually and academically dishonest. I wouldn't hire him. Well, he does seem sly enough for sales. "We thought: if you want to solve this properly, then you need to let the computer do these things. And this had lots of different effects: for example, Upstart always maximised what happened on the system, while we think you always have to minimise what happens." I don't like Upstart or Cannonical, but, here he says what most admins do not like. Why would you want to minimize what happens? He is like the new Steve Jobs. "You shall like what I decide is best for you. You don't need options. I know how everyone will use the machine." These guys just want to be worshiped. They don't play well with the other kids. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
Hi everyone, After some testing, I have a question about an option in /etc/default/shorewall: wait_interface If I add the bridge interface to that line, shorewall will not start unless a container is brought up. I suppose that is why I was thinking of bridging the bridge inerface with a tap interface so that it's always available. It seems that bridges do not start with ifup (-a) unless one of their bridged interfaces are up. Or I could do as Mr. Hobson does and run shorewall in a container. Would that actually be a more insulated "secure" approach? Thanks and kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
Simon Walter wrote: > After some testing, I have a question about an option in > /etc/default/shorewall: > wait_interface > If I add the bridge interface to that line, shorewall will not start unless a > container is brought up. I suppose that is why I was thinking of bridging the > bridge inerface with a tap interface so that it's always available. > > It seems that bridges do not start with ifup (-a) unless one of their bridged > interfaces are up. I don't think I've used "isolated" bridges so it's never come up for me. Do you need to specify wait_interface for it ? > Or I could do as Mr. Hobson does and run shorewall in a container. Would that > actually be a more insulated "secure" approach? "Security" is a relative thing, and depends on your priorities. Putting the firewall in it's own VM would improve isolation (the netfilter rules will be processed in the VM) - but the traffic still goes through the host Dom0. You can, AIUI, reduce this latter bit by running a separate driver domain to own the virtual interfaces and further insulate the traffic from Dom0. You could also use PCI passthrough to make a NIC owned by a VM - so Dom0 doesn't handle the packets. But this all depends on your priorities (or level of paranoia !). I don't think handling the network traffic in Dom0 is "insecure" - just not as secure as if it doesn't handle it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/09/2016 10:24 PM, Simon Hobson wrote: Or I could do as Mr. Hobson does and run shorewall in a container. Would that actually be a more insulated "secure" approach? "Security" is a relative thing, and depends on your priorities. Putting the firewall in it's own VM would improve isolation (the netfilter rules will be processed in the VM) - but the traffic still goes through the host Dom0. You can, AIUI, reduce this latter bit by running a separate driver domain to own the virtual interfaces and further insulate the traffic from Dom0. You could also use PCI passthrough to make a NIC owned by a VM - so Dom0 doesn't handle the packets. But this all depends on your priorities (or level of paranoia !). I don't think handling the network traffic in Dom0 is "insecure" - just not as secure as if it doesn't handle it. Indeed. And if I was really paranoid, I might use something other than LXC, since other technologies isolate even more. Though, I might put the firewall in it's own container even if just for the sake of modularity/maintenance. On 06/10/2016 08:06 AM, Greg Olsen wrote: > On 2016-06-09 02:50, Simon Walter wrote: >> It seems that bridges do not start with ifup (-a) unless one of their >> bridged interfaces are up. > > That doesn't sound right. > Here's a bridge I have defined for LXC containers: > > auto lxcbr0 > iface lxcbr0 inet static > pre-upbrctl addbr $IFACE > address 10.0.0.1 > netmask 255.255.0.0 > network 10.0.0.0 > broadcast 10.0.255.255 > bridge_stp off # disable Spanning Tree Protocol > bridge_waitport 0# no delay before a port becomes > available > bridge_fd 0 # no forwarding delay > upip link set $IFACE up > down ip link set $IFACE down > post-down brctl delbr $IFACE > > The IP address is assigned as part of the bridge definition. Like > Rainer said, no tap device needed. > > Due to the "auto lxcbr0" the bridge is brought up automatically > during system startup. > It comes up just fine with *no* containers running. Though, you do need to specify the bridge to be created and destroyed, which is something I thought was done automatically. It is when there are ports specified. As Rainer pointed out, when bridge_ports is "none", then the bridge device is created automatically and one not need to create it and destroy it pre-up and post-down. Though it seems to do it explicitly is a bit faster. I am not sure which is better or if there are any side affects. > Here's the ifstate resulting from ifup: > # grep lxcbr0 /run/network/ifstate > lxcbr0=lxcbr0 > > I've never had the need to specify a *bridge* interface on the > Shorewall wait_interface list. > > /etc/default/shorewall "wait_interface" is used when you need to > detect a dynamically assigned IP. I.e. so > 'find_first_interface_address' can return an IP, which it can't do if > one hasn't been assigned yet. > > However as can be seen in the example above, it already has an IP and > therefore no need for Shorewall to *wait* for one to be assigned. I > suggest leaving the bridge off the wait list. OK, that's good to know. I couldn't find documentation for it. I wasn't sure what it was for. > In my setup Dnsmasq is configured to listen on the bridge IP. When > dnsmasq starts up, the bridge is already there. The LXC containers > are then DHCP assigned the bridge IP as their default GW. And the > kernel handles the routing from there, provided IP forwarding is > turned on. > > To have Shorewall turn on forwarding for you, just specify > "IP_FORWARDING=On" in /etc/shorewall/shorewall.conf. Yes, I did notice this and have that set up. In fact it was working in the convoluted way with a tap interface. However, thanks to everyone's advice, the end result will probably be much better. Thanks and kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] LXC template for Devuan
Hi all, I am wondering if it is a good idea to submit a modified version of the debian template to the upstream LXC project. I am not sure who wrote those scripts. It seems like that is part of LXC source. So I am guessing it has nothing to do with the Debian LXC package maintainer. Also, I wouldn't want to submit something for Devaun to LXC without at least one other LXC + Devaun user taking a look at it and kicking the tires. Or maybe someone has already modified the debian template for Devuan. Checking (/usr/share/lxc/templates/lxc-debian), it looks like sysvinit is in use: # configure the inittab cat < $rootfs/etc/inittab id:3:initdefault: si::sysinit:/etc/init.d/rcS l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin 1:2345:respawn:/sbin/getty 38400 console c1:12345:respawn:/sbin/getty 38400 tty1 linux c2:12345:respawn:/sbin/getty 38400 tty2 linux c3:12345:respawn:/sbin/getty 38400 tty3 linux c4:12345:respawn:/sbin/getty 38400 tty4 linux p6::ctrlaltdel:/sbin/init 6 p0::powerfail:/sbin/init 0 EOF Hence there is a bug about LXC containers not working with systemd yet. So maybe this is a good base and just the MIRROR needs changing. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
(A little update) What I did was: cp /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-devuan cp /usr/share/lxc/config/debian.common.conf /usr/share/lxc/config/devuan.common.conf cp /usr/share/lxc/config/debian.userns.conf /usr/share/lxc/config/devuan.userns.conf I don't know if the last one is used. It doesn't seem to be referenced in the template. Then I: - removed the function configure_debian_systemd. - changed the MIRROR to https://auto.mirror.devuan.org/merged/ - removed debian from all the function names - changed debian to devuan in all the messages Then I created a container the new template. There were some warnings. insserv: warning: current start runlevel(s) (empty) of script `checkroot.sh' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (S) of script `checkroot.sh' overrides LSB defaults (empty). insserv: warning: current start runlevel(s) (empty) of script `checkroot.sh' overrides LSB defaults (S). update-rc.d: error: umountfs Default-Start contains no runlevels, aborting. insserv: warning: current start runlevel(s) (empty) of script `hwclock.sh' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (0 6 S) of script `hwclock.sh' overrides LSB defaults (0 6). update-rc.d: error: cannot find a LSB script for hwclockfirst.sh These are the same warning encountered with the Debian template. So if anything we should fix that for Devuan, but it doesn't seem to be a problem. I then modified the containters config and network settings and it started and seems to work fine. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifconfig vs ip
On 06/10/2016 03:55 PM, Greg Olsen wrote: On 2016-06-10 06:34, Greg Olsen wrote: [snip] > The only side-effect are the extra messages during ifup with > "bridge_ports none": > > iface testbr1 inet static > bridge_ports none > address 10.91.0.1 > netmask 255.255.0.0 > network 10.91.0.0 > broadcast 10.91.255.255 > bridge_stp off # disable Spanning Tree Protocol > bridge_waitport 0# no delay before a port becomes available > bridge_fd 0 # no forwarding delay > upip link set $IFACE up > down ip link set $IFACE down Sorry to respond to my own post here: I meant to remove the up/down statements in the example above. Those aren't needed either when using "bridge_ports none". No, that's cool and thanks for explaining. I think the up/down statements are not needed at all. It seems to work without them - whether using pre/post line or "bridge_ports none". Using "bridge_ports none" and then having post line delete the bridge does however cause message to say the device does not exist. I am a bit confused about the distros relationship with ifupdown. Isn't /etc/network/interfaces Debian specific? So I am guessing the ifup/down is a different program on say CentOS. I should try to stay relevant even though I use mostly Devaun now. Cheers, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/10/2016 05:11 PM, KatolaZ wrote: On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote: Hi all, I am wondering if it is a good idea to submit a modified version of the debian template to the upstream LXC project. I am not sure who wrote those scripts. It seems like that is part of LXC source. So I am guessing it has nothing to do with the Debian LXC package maintainer. Hi Simon, I think you might want to liaise with Greg Olsen on Devuan support for LXC. You probably know that there is already some material on the gitlab: https://git.devuan.org/gregolsen/lxc-devuan Nice. Thank you for pointing that out. I see Greg has already done most of this. Greg, on the page there is: $ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git For read access maybe it would work better if it was: $ git clone http://git.devuan.org/gregolsen/lxc-devuan.git I couldn't clone it using the git protocol (if that is what is called). I will give the templates a go now. Do you have plans to include that into an upstream release? Do you know if those are maintained by a Debian maintainer or by the LXC project itself? I am guess that those are distro specific. So would that mean that the Debian maintainer might not be interested in the Devuan templates? Of course Debian users may very well want a Devaun containers. If so, then it would be nice if there was an LXC package for Devuan so we don't need to clone a git repo to have those templates. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/10/2016 05:35 PM, Simon Walter wrote: On 06/10/2016 05:11 PM, KatolaZ wrote: On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote: Hi all, I am wondering if it is a good idea to submit a modified version of the debian template to the upstream LXC project. I am not sure who wrote those scripts. It seems like that is part of LXC source. So I am guessing it has nothing to do with the Debian LXC package maintainer. Hi Simon, I think you might want to liaise with Greg Olsen on Devuan support for LXC. You probably know that there is already some material on the gitlab: https://git.devuan.org/gregolsen/lxc-devuan Nice. Thank you for pointing that out. I see Greg has already done most of this. Greg, on the page there is: $ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git For read access maybe it would work better if it was: $ git clone http://git.devuan.org/gregolsen/lxc-devuan.git I couldn't clone it using the git protocol (if that is what is called). I will give the templates a go now. I had some issues: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_US:en", LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Over ten times repeated, but more importantly: lxc_container: Failed to parse config: lxc.include = /usr/share/lxc/config/common.conf lxc_container: Failed to parse config: lxc.include = /usr/share/lxc/config/devuan.common.conf By the way, I have Devuan alpha4 installed. So maybe that is the issue there. Though, with my modified config and templates, I didn't have those errors. Let me know if there is anything I can do to help test etc. Many thanks, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/10/2016 06:16 PM, Jaromil wrote: On Fri, 10 Jun 2016, Simon Walter wrote: I will give the templates a go now. thanks! I am going to try Greg's template on the BETA release. My simple edit on the alpha4 worked fine, but Greg's templates didn't work as well. So I am trying with BETA. Do you have plans to include that into an upstream release? yes, especially if more than one person gets involved so we have some degree of peer review. Also please note we are in the process of setting up a builder server on the premises of our HQ in Amsterdam and all its setup is based on LXC. Hellekin is currently going through its configuration and I can hear little sounds of satisfaction and success across the day coming from his desk. But I'm not aware if Hk is using Greg's template. So you are bootstraped? Using Devuan to build Devuan? If so, then it would be nice if there was an LXC package for Devuan so we don't need to clone a git repo to have those templates. sure, if such a team forms and a .deb package is ready, made through a somehow collective process involving more than one developer, it will be certainly included in our repositories. OK, wonderful. I am doing lots of tests for my work too. So I will definitely be sending feedback around. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] secure boot
Hendrik Boom wrote: > How *do* we deal with secure boot? I am terrified of buying a new > machine because I'm afraid I won't get to install anything on it > wxcept for an OS from one of the big companies that have > sweetheart deals with Microsoft. Well (under UK law at least, other EU countries should have something equivalent, dunno about other places ...) you mention when buying it that you intend to install (say) Devuan Linux. If it can't run it, and the vendor didn't warn you at time of purchase, then you can insist that they : repair it, replace it, or refund it. That's basic consumer protection legislation, required by EU directive and implemented by national laws in each EU country. The new result is that you'll probably have to send it back - but then the seller has an opened & returned product and loses out. It is our duty to do this and make it a cost to sell "defective" products. Rowland Penny wrote: > I don't think that option will go away, if it did, then the EU would probably > heavily fine which ever motherboard maker that does remove the option, then > force them to put it back. *eventually* Note how long it took them to deal with the Internet Exploder and Media Player problems - the sanctions when they eventually came in were ineffective (and just confusing to users) as things had already moved on. MS could very easily "require" manufacturers to lock stuff down through dodgy "marketing incentives". By the time the EU got round to fixing things, the situation could very well have moved round to only "approved" Linux was usable on most hardware. We already have a signed Grub, it's only one more step for the signed grub to only boot a signed kernel, ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] secure boot
Didier Kryn wrote: > The dealer will just be instructed to not sell it to people who claim they > will do anything else than using the pre-installed Windows. Eventually yes. But it will make their management aware of us for them to issue the instruction. But bear in mind that a lot of the "sales" people at the big sheds will tell you it'll brew the tea and create world peace if it gets them one more sale towards their target. OK, I exaggerate a bit - but if people ask them if it runs Linux, and management have told them to say no, then that means they've at least heard of it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Edward Bartolo wrote: > I have been 'told' that any kernel can still be booted under UEFI > Secure Boot. For now, how long until that changes ? > Refer to forums.debian.net thread: > http://forums.debian.net/viewtopic.php?p=609579&sid=c65ab3dc5f980e0c1f79b7b7a5116511#p609579 And as pointed out there, it's hardly "drop in a disk and boot". For a very large percentage of users, it'll mean "Linux doesn't work" if the disk fails to boot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/10/2016 10:39 PM, Greg Olsen wrote: On 2016-06-10 08:59, Simon Walter wrote: [snip] > > I will give the templates a go now. I had some issues: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_US:en", LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Over ten times repeated, but more importantly: Simon, thanks for testing. I think the locale just isn't setup yet at that early point. Perhaps a Perl expert can opine? Maybe we can diff that? > ... This might be a bit surprising but I actually wrote lxc-devuan with *non-Devuan* OS's in mind. To not discourage people from running Devuan, it automatically downloads and uses the Devuan keyring. Without that capability it won't get past square one on a non-Devuan OS, and the user is likely to mumble some not so nice things about Devuan. Something to be avoided if at all possible. It seems to be fine with the 'auto' sub domain maybe because the keys are registered for that domain name. Are you saying that those keys are pre-installed on the image? If that's the case, I think we should make two versions, that are based on the same source - an include or something. One to be used on Devuan, one to be used by other distros that want to run Devuan containers. I also added a feature or two that other OS templates don't have, such as the ability to pre-assign the MAC address. I have absolutely no idea if that's of interest to anyone but me. But if it is, that's yet one more reason for people to choose Devuan over something else. Yes, I really like that. It is very useful. Of course, the paths won't end up correct on all distros until a version of it makes it upstream, and then back down again, and that could take quite some time. Therefore a script can/should be written to help install it. wget or maybe curl? What's on a base install? In the meantime, anyone with a mind to "clone" and use the template as is (without a proper package or script to install it) will have to adjust paths as needed to match their system. On the other hand there's nothing written anywhere that says we have to use the lxc-devuan that I wrote. Not that I want to give up on it, but If yours is already working correctly on Devuan Beta, we can always put it in a different branch and use that. We'll just have to see how things plays out. I've made an account on git.devuan.org (user: smwltr) How do you want to do this? Shall I fork your repo and apply a patch and then send you a pull request? After a look maybe the solution will present itself. I guess the .conf files too. Let see how it goes. Cheers, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan on Android
Hi all, I want to report that I've installed Devuan on a "rooted" Android device using DebKit. All I did was: 1. Change the package mirror to: auto.mirror.devuan.org/merged 2. After the debootstrap process is complete and under the chroot install the devuan-keyring package. I tried to use some other apps like LilDebian, DebianKit, and LinuxDeploy, but for some reason they didn't work for installing Debian. So I didn't try Devuan. It's nice to have Devuan on my portable computing device. Thank you, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Edward Bartolo wrote: > But I still am convinced with a signed kernel one can still use it to > boot any installed OS. My reasoning goes like this: once the signed > kernel boots, it would be in control of the machine. A running kernel > can be used to run any executable provided the latter is coded for the > same machine architecture. So, the boot procedure would first consist > of UEFI loading the signed kernel, the kernel then loads a bootloader > like GRUB*. > > What do you think? Yes, it can be done. No it's not something your average user could do on his own. What you point out is the weakness of signing code - if that code isn't itself "secure" then it defeats the point of signing anything. So long term, not this year, probably not next year, but sometime ... expect some pressure to extend the signing. The first step will be signing of kernel binaries in distros, then some extra code in Grub to only load signed kernels - and only versions of Grub built that way will get signed. So now we've reached the point of only being able to use a Grub that will only load signed kernels. And only 'clean' kernel binaries will get signed - so no "non-approved" drivers. And if that bit of wedge gets hammered in without too much pushback ... The next step will be to add kernel code to only run signed binaries - but it'll be OK for the likes of RH because you'll have no reason to run anything other than the binaries they supply for packages. Yes, you can build a Grub that will load any kernel - but the EFI won't load it as it won't be signed. And expect it to get harder to add your own sigs to EFI systems as well. And all in the name of "security". Rrriiight. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/14/2016 09:26 AM, Greg Olsen wrote: On 2016-06-13 01:28, Simon Walter wrote: [snip] > > This might be a bit surprising but I actually wrote lxc-devuan with > > *non-Devuan* OS's in mind. To not discourage people from running Devuan, > > it automatically downloads and uses the Devuan keyring. Without that > > capability it won't get past square one on a non-Devuan OS, and the user > > is likely to mumble some not so nice things about Devuan. Something to > > be avoided if at all possible. > > It seems to be fine with the 'auto' sub domain maybe because the keys > are registered for that domain name. Are you saying that those keys are > pre-installed on the image? If that's the case, I think we should make > two versions, that are based on the same source - an include or > something. One to be used on Devuan, one to be used by other distros > that want to run Devuan containers. The issue isn't the domain and there's no pre-installed image. It's a chicken and egg problem to bootstrap the keyring to validate the signed packages. Well, maybe I didn't say it correctly. Is there already a devuan-keyring package on the iso-image? If so, that would explain why it works fine when the "host" is a Devuan installation. My personal opinion is that keys should not be automatically downloaded and installed. But I am a bit paranoid. Assume install on a foreign OS. The foreign OS probably won't have a Devuan keyring. When running debootstrap, among the packages it will download is the keyring package. When it goes to validate the download (which includes the keyring package), it doesn't have a key to validate, so it fails with "Release signed by unknown key". Yes. So, perhaps we have one script maintained for the Devuan OS and another for non-Devaun OSes, and they have most things in common. [snip] > I've made an account on git.devuan.org (user: smwltr) How do you want to > do this? Shall I fork your repo and apply a patch and then send you a > pull request? After a look maybe the solution will present itself. I > guess the .conf files too. Hi Simon, For now we can work it that way. I just pushed an update that adds support for LXC <= 1.0.8. The README is updated to use ./config-1.0.8 for LXC <= 1.0.8 The existing ./config directory is for LXC >= 1.1.0 It'll be great if you'll test again. So if you've already forked, please fetch and rebase. Nice. Sure thing. I will be testing it out soon. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
Hi Greg, I've read had a look and a test. Please see my ramblings below. I am in no hurry. So please take your time. ;) On 06/14/2016 10:02 AM, Greg Olsen wrote: On 2016-06-14 00:39, Simon Walter wrote: > Well, maybe I didn't say it correctly. Is there already a devuan-keyring > package on the iso-image? It's a debootstrap install. There's no iso-image involved. I think that maybe you read my email too fast. So I will try to be verbose. I install Devuan on my hardware from an iso CD-ROM image file copied to a USB memory device. Next I install LXC. Next I modify the debian template lxc-debian - remove systemd stuff, rename a bunch a of things and change the mirror. When I use that modified template to lxc-create a container, I don't need to download any keys. I am guessing because devuan-keyring is already installed from the iso CD-ROM image on the initial installation on my hardware. Does that sound like the reason? Am I missing something? > My personal opinion is that keys should not be automatically downloaded > and installed. But I am a bit paranoid. I understand your reservations. However it does **not** trust the keyring on the user system. Does that mean that it does not trust the keyring on the host? Is there a good reason for that? I thought the template checks for /usr/share/keyrings/devuan-keyring.gpg on the host. It simply downloads it, issues a message it was downloaded, and then passes the keyring file to the debootstrap command for it to use validating packages. So it's completely safe. It downloads a keyring from a server. Is it in anyway possible to hijack those connections and download a different keyring to validate different packages from a different server? It would be a great big coordinated attack, but is it impossible? The template defaults to downloading and also to passing --no-check-gpg. I would suggest making the default to check for the devuan key and fail with an error message saying that the key was not found and telling the user that there is an argument they can specify to have it downloaded. That is IMHO the rule of least surprise. Forgive my criticisms and questioning. In a world where we have people planting questionable code into open source in order to create back doors, we should be able to answer to this kind of criticism - if only to aid ourselves (think rubber duck programming). Now on to the latest test I made: The locale is set early enough to not have those warnings spew all over the screen. Excellent. More importantly, the errors about the config files are gone. I had a look at the differences, and it all seems reasonable. Also I notice gcc-4.8-base is being removed towards the end. I am sure there is a good reason for this and I am interested to know. About the random MAC address feature, I see a comment: ## If there is exactly one veth network entry, ## make sure it has an associated hwaddr. How does veth get into the config file at this point? Should the user create the config file before creating the container? It seems like there are so many options on how one could create the network. However, if arguments were given for a few things: lxc.network.type lxc.network.link lxc.network.ipv4 lxc.network.ipv6 gateway network Then a simple network could be set up by the template - both the LXC config and the network inside the container. Otherwise it doesn't seem to work "out of the box." More complex configurations would require editing the config file. There are a few more things I wanted to discuss. - "Less bare bones than from debootstrap, however dependencies are kept minimal." - OpenDNS name resolvers are set. - The random password is removed. (I would suggest that if a password argument is not given, a random one is set.) These seem like they are useful. My criticism is not directly at any one of these ideas. I am thinking of the naive user who doesn't expect to find things set up this way. Maybe we need a bare template and then one with all the nice options. Or maybe we need this template to install the bare minimum if no arguments are given, and then when certain arguments are passed, we get OpenDNS, the password we want, and the nice set of packages, etc. If the arguments are available, then at least the user has an vague idea, without reading the template, of what is possible and what the container will be set up like. Because packages are removed after the root password is displayed, it gets pushed up the screen. It would be nice to have that as the last thing that is displayed. If you want me to hack on any of this let me know. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/15/2016 10:26 AM, Greg Olsen wrote: On 2016-06-14 09:22, Simon Walter wrote: > I think that maybe you read my email too fast. So I will try to be verbose. Hi Simon, If I misread then I apologize. No need to! ... > > Also I notice gcc-4.8-base is being removed towards the end. I am sure > there is a good reason for this and I am interested to know. I got that from the "Minimal Install Guide": https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide See section entitled "Removing unwanted packages". I will have a read. ... > How does veth get into the config file at this point? Should the user > create the config file before creating the container? The stock default.conf from Jessie: # cat /etc/lxc/default.conf.orig lxc.network.type = empty # So the default for everyone regardless of the template used is "no" network. The coin drops. I see. That is what is going on. ... My intent was not to teach how to use LXC. That's why the reference in the README "LXC Documentation" section. In hindsight I must admit, it will be better to show the default.conf file, as was used to arrive at the result in Example 7. I have another tweak planned for the README, so I can add that to the list. Nice. Thank you for explaining. I must admit, I didn't know that even file existed. Yep. A simple network could be set up "out of the box". However I must first ask, what happened to your "rule of least surprise" ? Yes, I stand by my suggestion that the default is minimal and everything else takes parameters. How does that contradict the rule of least surprise? If they are not specified, then no action is taken. By the way it's not *my* rule - just something I was taught similar to convention over configuration. IMHO it's unfair to state it doesn't seem to work when the default use case is, *no* network. Being the default is *no* network, I think we have the responsibility to also consider, the existing user base has good reason to expect no communications can occur unless they explicitly change their default.conf. Yes, please pardon my ignorance. Everything makes more sense in light of that file. > There are a few more things I wanted to discuss. > > - "Less bare bones than from debootstrap, however dependencies are kept > minimal." Package inclusion and exclusion is indeed open to discussion/debate. > - OpenDNS name resolvers are set. I thought about setting the IP's in variables with template options for override purposes. > - The random password is removed. (I would suggest that if a password > argument is not given, a random one is set.) New containers have root password = root, the same as lxc-debian provides. I simply kept with that expectation, and that people should change the root password. Beyond that I haven't given much time/consideration. What do all the other templates do with this? Do we want to depart from the expectations admins may already have from working with other templates? Hmmm... I am not sure which version you are using. I see this in lxc-debian: password="$(dd if=/dev/urandom bs=6 count=1 2> /dev/null | base64)" echo "root:$password" | chroot $rootfs chpasswd echo "Root password is '$password', please change !" I know some of the other templates to use 'root' as the password. I have seen this criticized: https://fedoraproject.org/wiki/LXC_Template_Security_Improvements > These seem like they are useful. My criticism is not directly at any one > of these ideas. I don't take any of what you said as criticism. I think tossing around ideas for improvement is a good thing. OK. Good. I don't want to piss anyone off, and my social skills are not that smooth. So I worry. I also see things as falling into a category: 1. Base functionality (priority, need it now) 2. Enhancements (nice to have) I think the immediate focus should be to get the base functionality correct, submit upstream, and make a package available. I think what you have so far is most of the way there. Work on enhancements can start anytime, including now if you're so inclined. A typical way to handle enhancements is for each developer to work in their own feature branch, for possible later inclusion in master branch. I am not familiar with gitlab. Does one join a project? Or should I create a new project? Or should I just hack locally and send a pull request? I am also wondering if some place on gitlab is better to discuss when I have a question for this project. Or right here on DNG? I don't want to start on adding things like some of those template parameters and then you've already done it. You seem pretty fast paced. I hope I can keep up! Cheers, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installer Devuan Jessie 1.0 fails
On 06/15/2016 06:21 PM, emnin...@riseup.net wrote: ... But if so: Shouldn't we investigate the installer? I mean, it's not really user friendly to have an installer subject to that kind of errors. And in my experience there are even other problems like the overheating problem for amd graphics based machines, at least for some of them. Or the fact, that the installer seems to not install the base system it brings itself but seems to pull it from the mirrors. Anyway, i'm well aware human ressources at Devuan are limited but the installer should be worth a major consideration (?) Since it is a universal OS. I would suggest we disable the graphical installer if it causing people to be put off. This may sound like heresy, but the text base installer is not minimal and it is fully functional. I remember back in the days when Debian got the graphical installer, it was to be treated as BETA quality and if it didn't work, to use the text base. I think the same applies here. Maybe we need to put a "use with caution" note. I think there was something like this on the original Debian graphical installer. We are not so spoiled that we need to use a mouse for everything, are we? Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] cosmetic installer issues
On 06/15/2016 08:16 PM, richard lucassen wrote: ... 1) Wishlist: a real PXE installer like Debian is providing. Just an intrd.gz and a vmlinuz that will guide you through the install process. No need for USB sticks or CD drives. Running a PXE installer together with an apt-cacher-ng saves time (internal network speed) and saves bandwidth usage for the Devuan community. I think this would be really useful and professional. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installer Devuan Jessie 1.0 fails
On 06/15/2016 08:52 PM, emnin...@riseup.net wrote: We are not so spoiled that we need to use a mouse for everything, are we? Simon My problem (the failure while installing the base system) happens in both, the graphical and the text mode installer. I'd suspect there's something wrong with the underlying routines (as also L. Nodden noted). A working and solid keyboard only installer would be fine for me - and i think for most users: It's all about being well explained, input error tollerant and solid ... (I could even live fine with an i3 based desktop, when it is well done ;) ). Aha! OK, then please disregard my comment. Because I thought the problem was only with the graphical installer. It seems it is something deeper. Do you get the overheating/CPU problem? I think that could be debugged, but it would have to be done on the problem machine. This is a good idea: On 06/09/2016 05:28 AM, Paweł Cholewiński wrote: > W dniu 07.06.2016 o 12:38, emnin...@riseup.net pisze: >> (How can i debug the installation?) > > You could use this document: > https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide > > Use debootstrap --variant=minbase --include=nano,nvi,procps jessie > /target http://auto.mirror.devuan.org/merged to add top command - You > could use top on another console i.e. ctrl+alt+F3 after chroot to /target Though maybe, while the installer is being perfected, there should be some tools for debugging available, rather than just busybox. Then people with problems can more easily help debug them and get the valuable info to the developers. I installed from the netinstaller. So maybe on the full CD there is top and other tools. Anyone know what programs are on about the full CD? Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/18/2016 10:31 AM, Greg Olsen wrote: ... In the meantime, I added Simon Walter as a Developer for lxc-devuan. Simon, As a developer you can push directly to the main development branch. I added a "draft" Contribution guide, and I'll be following the same process myself as outlined. Hi Greg, Thanks for that. I will dig in soon. I am pretty busy at the day job. So much so that I'm in the office on the weekend. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: > This is published here in the hope that it is useful for someting. > > The basic design of udev is similar to that of a forking server: There's > a parent process listening for uevents from the kernel on a netlink > socket which passes these events to worker processes for actual > processing. In case no idle worker process is found, a new one is > forked, up to a configurable limit (=> udevd(8)). > > One could argue if using more than one worker process is > actually sensible considering that uevent processing happens > mostly during startup and isn't going to take much time, > especially as this is a text book example of the simple, obvious > design one shouldn't be using if good performance is to be > achieved: The process which read the uevent from the socket is > already running and the CPU executing it has all the data in its > cache and kicking this to another CPU is a waste: The process/ > thread which received the event should process it and another > should be listening for more uevents while this is happening. > > A less-than-desirable side-effect of this model is that uevents causing > driver loads may end up loading the drivers in an order different from > the one the uevents came in. So it's suboptimal - perhaps why the systemd guys are so fond of it ! It also explains the "random" ordering that the systemd guys have "fixed" by making the names even more unfriendly. Personally, I've always just edited /etc/udev/rules.d/70-persistent-net-rules* to give user-friendly names to my interfaces. Typically I use things like ethint, ethext, and so on - far better than trying to remember that eth0 is the internal port, eth1 is the outside, and so on. * Don't know if that's "standard" or a Debian packaging thing. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/20/2016 07:28 AM, Greg Olsen wrote: Hi Simon, No rush. Unless I find some glaring bug, after a bit more testing I intend to refocus on pushing upstream and what's needed to make "lxc-devuan" packages for Jessie/Ascii/Ceres. It'll be the first .deb package I've made completely from scratch (suggestions are welcome, please). Disable --no-check-gpg as the fallback? No votes against this: +1 Simon Walter +1 Greg Olsen So when convenient, I may go ahead and disable that. Hi Greg, I've added a branch called add-netconf, which you have probably seen. I thought to just add one feature per branch so that review is easier. Let me know how you prefer to collaborate. I was not sure about what style/standards we are using. However, the hashbang tells me bash. I looked at the other templates, and most use bash. I wasn't sure if having all the settings in one argument or separate was better. The logic behind having them all in one argument is that all those are needed and cannot be derived from one another. So IP, netmask, and gateway are all in one comma separated argument. Maybe the parameter name should be "interface" or "ifconfig". For my next edit, I would like to add the password parameter and if not specified would set a random one. Then I was thinking of adding a parameter for MAC address, in case it should be explicitly set or not set or set to a random address. I would appreciate your comments on that and of course on the netconf parameter and it's functionality. One question, is --main-only the default? What is the default for the Devuan install? I am not sure, but I think the default is only main. If so, maybe we should reverse that argument to be something like --extra-repos. Or even --add-repos=main,non-free. That way the use can specify exactly the additional repositories on the command line. I think that would be very useful for orchestration tools such as vagrant or cdist for example. Cheers, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Steve Litt wrote: > Of all the escapades of FreeDesktop.Org, managers of Lennart and the > Redhats, these name thingies are some of the least onerous. I put a > shellscript on the list a few months ago that delivers the wifi device > name, and that script can be used in init scripts and the like. > > I mean, by all means use it as a talking point, but if it's actually > giving you trouble, look up my shellscript and use it. It's not giving me trouble, I'm still on Wheezy, and I use udev rules to rename interfaces to meaningful names anyway. But, I get the impression you only run "simple" systems. Once you start having firewalls (interface names in config file(s)), monitoring (interface names in config file(s)), data collection (interface names in config file(s)), ... it stops being something that you can "fix" with a script that will tell you what your interface is called today. Well, I suppose you can use the script to find out the name of the interface, and then expand that to hack all the other scripts/config file before the relevant services start ... hmm, isn't that the systemd way, create a mess and then create more mess to fix the problems caused by the first mess, and then ... So yes, for a "simple" desktop/laptop environment it might not be an issue, but for non-simple stuff it does matter. For the sort of stuff I work with, the old udev way works just fine, and I mean just fine. Interfaces don't change very often, and when they do it's a quick and simple fix (edit 70-persistent-net-rules) that only needs to be done in one place. Or TL;DR - the "new" way sucks big time. In fixing a non-problem for several classes of user, they've created a much bigger problem for them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] [Re: Studying C as told. (For help)
On 06/21/2016 05:28 PM, KatolaZ wrote: On Tue, Jun 21, 2016 at 08:22:41AM +0200, Edward Bartolo wrote: [cut] I studied 'and' and 'or' boolean operators back when I studied Delphi Pascal. I am embarrassed to have written such a stupid thing. It must be due to the fact I wrote the email just before going to bed. AND: requires ALL sub-expressions to be true to evaluate to true i.e. Q = A ^ B ^ C ^ D Q = 1 if and only if A = B = C = D = 1 OR: only requires ONE sub-exression to be true to evaluate to true i.e. Q = A v B v C v D Q = 1 if any Ai = 1 These properties are used by compilers to optimize on boolean expression evaluation. If I remember well, there are also specific Be careful, because conditional expressions in C are subject to "short-circuiting", meaning that only the minimum number of expressions sufficient to determine the value of a chain of && and || will be evaluated. In particular, a chain of || expressions will be evaluated until there is one that evaluates to TRUE (!=0), while a chain of && is evaluated until there is one of them which evaluates to false (==0). Isn't that how AND and OR work in most programming languages? Mind you, I am not familiar with that many. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] [Re: Studying C as told. (For help)
KatolaZ wrote: > Be careful, because conditional expressions in C are subject to > "short-circuiting", meaning that only the minimum number of > expressions sufficient to determine the value of a chain of && and || > will be evaluated. In particular, a chain of || expressions will be > evaluated until there is one that evaluates to TRUE (!=0), while a > chain of && is evaluated until there is one of them which evaluates to > false (==0). Indeed, and that is the whole point behind using them in this way. I use them a fair bit in shell programming : eg > [ ] && something_to_do_if_test_matches instead of > if [ ] > then > something_to_do_if_test_matches > fi or even on the command line as in : > apt-get update && apt-get upgrade There can be some situations that can trip you up, eg it might seem clever to do : > some_command && another_command && echo "It worked !" || echo "Failed" While a simple "echo" is unlikely to fail, if that step does fail (eg you are writing status to a file and there's a problem) then you could find both your 'success' and 'fail' commands being run. Used intelligently the && and || operators can both aid readability and improve performance - but equally can be used to obfuscate (either deliberately or accidentally). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] [Re: Studying C as told. (For help)
On 06/21/2016 06:09 PM, KatolaZ wrote: On Tue, Jun 21, 2016 at 05:47:59PM +0900, Simon Walter wrote: [cut] Be careful, because conditional expressions in C are subject to "short-circuiting", meaning that only the minimum number of expressions sufficient to determine the value of a chain of && and || will be evaluated. In particular, a chain of || expressions will be evaluated until there is one that evaluates to TRUE (!=0), while a chain of && is evaluated until there is one of them which evaluates to false (==0). Isn't that how AND and OR work in most programming languages? Mind you, I am not familiar with that many. I didn't say that short-circuiting is a peculiarity of C :) Aha! You certainly didn't. I was surprised that "non-short-circuiting" logical operators even existed. I simply said that short-circuiting is how C evaluates conditional expressions. There are many cases (such as that of FORTRAN) in which short-circuiting can be enabled or disabled at compile time, many other cases (e.g. most of the dialects of BASIC and some other esoteric languages) in which short-circuting does not exist, and many more cases in which the language supports both eager and short-circuit boolean operators (e.g., Java, Python, Perl, Ruby, etc.) Boolean expressions in C are always subject to short-circuting. Interesting. And here I was taking "short-circuiting" for granted. Well, you learn something new everyday. I will be sure to keep that in mind. Can you to point me to those other operators that do not "short-circuit" in Java, Python, Perl, and Ruby? Are the operators different, or do you have to change the behaviour with a switch? I am thinking we might use single ampersand or pipe (bitwise). Can we use bitwise operators as what would be a non-short-circuiting logical operator in C (or other languages)? Very interesting! Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] [Re: Studying C as told. (For help)
Irrwahn wrote: > We could. But it is a kludge, and very bad style. Is this the right time to introduce ... ... wait for it ... ... you're probably not going to like it ... ... no spoilers ... ... it is "safe for work" ... ... unless your work is writing C code ... http://www.ioccc.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Studying C as told. (For help)
An interesting task would be to look at the various algorithms offered, work out how the compiler is likely to handle them when turning into code (or even look at the code generated), and then work out the efficiency of the different methods in terms of CPU cycles/character. Of course, it's possible that different methods may come out best depending on the amount of whitespace to be removed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Steve Litt wrote: > Good point. Here in my house, I trust everyone with a physical console, > so individual computers have simple or no firewalls. I'm running servers where you have to assume everyone is out to get you. > My Internet > firewall is pFSense, and every once in a while I use OpenBSD/pf instead: > I long ago gave up dealing with iptables. I've done a little with iptables, but normally use Shorewall. The only systems I don't use Shorewall on are my Xen hosts where I run a small hand-crafted iptables setup. So each interface name appears there. And there's the systems doing PPPoE - so interface name embedded in PPP config. Then I have a fair bit of data collection (interface stats etc), mostly with shell scripts feeding into RRD databases (some of them Cacti, some outside of Cacti). So multiple mentions of interface names there. And finally I have Nagios doing a load of monitoring. Some of that involves using arping (which needs to be told which interface to use) to monitor MAC-IP mappings to detect added/removed devices, and more importantly, duplicated addresses (2 devices set on same address). All in all, it soon adds up. Just one more area where the freedesktop guys really don't have a 'kin clue how systems in the real world get used. Now some of these instances could use a "centrally provided" file by way of includes or similar (at least my custom scripts could) - but not all of these uses offers that facility, now do those that do support a single format. All in all, the easiest way by far is to use stable and user(admin) set names for interfaces ! > AFAIK, those merry jesters > from FreeDesktop.Org consider BSD not important enough to sabotage. :-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: >> All in all, the easiest way by far is to use stable and user(admin) >> set names for interfaces ! > > This is going to bite you in the posterior in case of canned OS > installations intended to be usable on a wide range of differently > configured 'servers' and not supposed to be maintained by anyhow > 'UNIX(*)-savy' personnel, IOW, appliance-type installations. I need > interface names which are stable, generally predictable (ie, if there > are two interfaces they'll end up as eth0 and eth1), machine and > NIC-independent and compatible with already existing software. The > kernel naming scheme provides pretty much exactly what I > need. Consequenstly, I'm determined to keep using it and software which > gets in the way will be changed. If you just use the default kernel naming scheme then you open yourself to the problem that udev was designed to solve - that of random device names. I do have personal experience of that - boot with a different disk (for maintenance) and eth0 & eth1 swap places (can't remember if it was "stable" when using just the main OS). And I've first hand experience of the "two disk controllers" problem where it really was random which disk was sda and which was sdb. But once you go down the route of udev (or equivalent, eg vdev) and persistent rules, then "eth0" is just a subset of "admin set interface name". I realise that in some cases, not using ethn will cause problems. I'll cross that bridge when I come to it. BTW ot all my systems have named interfaces - many do just have eth0 and eth1. But on a system with (IIRC) 7 interfaces, I'll take human readable over my memory every time ! > The nice thing about free software is that one may use it to solve real > problems the developers disapprove of. Yes, that's a good one. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Studying C as told. (For help)
Rainer Weikusat wrote: > Lastly, if the target system is Linux (as here), one can safely assume > that EBCDIC won't be used. > > None of this matter anyhow for solving algorithm exercises in an > entry-level book about a programming language. On the other hand, it might just give a newbie to C (and others) some hints that might save their bacon (or that of others) later. When I first learned any programming, we too got to work on the basis that "letters are A-Z and a-z" - which as has been pointed out breaks quite convincingly once you step outside the "basic ASCII" character set. I would imagine that such hardcoded assumptions have been behind many a problem when internationalising code. On 21 Jun 2016, at 18:50, Irrwahn wrote: >> An interesting task would be to look at the various algorithms offered, work >> out how the compiler is likely to handle them when turning into code (or >> even look at the code generated), and then work out the efficiency of the >> different methods in terms of CPU cycles/character. >> Of course, it's possible that different methods may come out best depending >> on the amount of whitespace to be removed. > > And results will differ depending on platform, toolchain, > compiler version, optimizer setting, and so on. > > Another aspect beyond just runtime efficacy is this: > > Source code is written for humans, not machines! Clarity and > simplicity can help minimize code maintenance cost, and thus > easily outweigh some slight runtime penalty. Whoever has found > himself in a situation where he had to spend a considerable > amount of time trying to grok what some "clever", "manually > optimized" code is supposed to do, knows what I'm talking about. I have no argument with that, or the rest of your response. However, I do think it is important for a programmer working in a high level language to have some concept of how changing (sometimes subtle) in code can impact on performance. I wasn't suggesting manually optimising code - but looking at how different algorithms and code arrangements impact how the end result runs. Having no idea at all - or worse, not giving a s**t - leads to the scourge of "performance by throwing hardware at it". I suspect we've all conversed with people who have approximately zero knowledge or interest in how "the greasy bits" of the machine ends up running their code. My first computer came with just 1k of RAM, and sockets for just 8k total. It's surprising what you can do with that ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: >> If you just use the default kernel naming scheme then you open >> yourself to the problem that udev was designed to solve - that of >> random device names. > > If you'll neither believe me nor the code wrt causes these 'random > device names', may I try some kind of authority? > > 7.4.3.7. Device naming order changes randomly after rebooting > > This is due to the fact that Udev, by design, handles uevents > and loads modules in parallel, and thus in an unpredictable > order. And ? Udev, at least on the Debian systems I'm used to, creates rules such that the interfaces will only be randomly named the first time they are encountered. After that, the naming is recorded so that each interface will have a completely stable name thereafter. OK, I may be misunderstanding some of the internals, in particular "what" is responsible for the random module loading order - but I certainly recall it being a problem before udev came along. And after udev, I have somewhere where I can fix the names of things. BTW - this is also an issue for video capture devices (TV tuners etc) as well as NICs. Comes up from time to time on the MythTV mailing list. Rainer Weikusat wrote: >>Udev solved the problem of the stability of device names: once one >> interface has been named eth0, the same interface will remain eth0 - >> without interference from the admin. > > Unless the admin transfers the installation to another system. Assuming > that everything used to work fine with eth0 - eth3, all hell will > break lose because the sole four interfaces are now called eth4 - eth7. But the point is, the admin can then, with one simple edit, return those to being eth0-3. That's just one step in transferring a system - along with partitioning disks, formatting filesystems, changing fstab if it's using ugly UUIDs, installing the bootloader, ... Not only that, but you can decide which interface you want to have which name. > The idea is already conceptually rotten as MAC addresses are usually > programmable and may even be randomly generated. True, MAC addresses are rubbish as an identifier - but they are there and for the sort of systems I'm used to, reasonably stable. Virtualisation changes that of course, but I set fixed MAC addresses for my guests for other reasons anyway. YMMV IMO, using MAC address is the worst option, apart from all the others. Now, if you as the admin decide to change your mAC address, then you can (at the same time) change the rule mapping interfaces. If anyone else is changing MAC addresses in your NICs then you have something of a problem ;-) As an aside, when developing IPv6, the IETF group working on it agreed that MAC addresses are terrible - and excluded them from the packets. They've since been forced to add a new option to carry the MAC address simply because so many people have workflows reliant on them - and DUIDs (DHCP Unique ID) simply don't work in the real world, they are less stable than MAC addresses in many situations. Until hardware manufacturers assign DUIDs at manufacture time, and provide somewhere to store it, and all OSs use that storage, and ... then that won't change. I switch OSs, change HD, re-install OSs, boot off CD/DVD/USB stick/etc far far far more often than I ever change NICs. >> But it does not solve the problem which Rainer adresses: to match the >> device name with the visual labelling, ie the need for a predictable >> matching between interface name and what is written on the box, so >> that instructions to the user make sense. > > That's something I specifically don't care about. Any mapping is good > provided it's possible to write software such that it doesn't have to > care about the hardware it's going to run on and that it's stable. > > There's no way to predict external wiring from the bus geometry, only > the hardware manufacturer knows about that. Indeed. But when creating a system, at some point you will have to configure "stuff" such that it uses the port on the back that you want it to use. You can accept what the system gives you, and go and find every reference to it in your config and alter that - or you can do as I prefer and do that mapping exactly once and in exactly one place, giving each interface a name you decide on (even if that is eth0, eth1, ...). And unless the new hardware is identical, something's going to change anyway - different chipset(s), different internal bus locations, different physical locations on back panel, physical labelling, ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
I wrote: >> Unless the admin transfers the installation to another system. Assuming >> that everything used to work fine with eth0 - eth3, all hell will >> break lose because the sole four interfaces are now called eth4 - eth7. > > But the point is, the admin can then, with one simple edit, return those to > being eth0-3. Just to add, coming back to a use-case you mentioned earlier. If you are building an appliance, where you will be deploying to multiple hardware by imaging the disk and having it self-configure out of the box, then there are other options. In this situation, you'll have known hardware (or at least, a limited set of known configurations) - such as using physical bus location. That's doable through udev rules without needing to have stupid and unwieldy device names. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: > In absences of post hoc driver shuffling, these names *are not* > random. But as that's clearly something you're not willing to believe > in, this discussion seems pretty pointless. I think we must be making assumptions about what each other are talking about - you appear to be thinking I'm thinking something different to what I am. You've posted a statement that says drivers are loaded in a non-deterministic order. Therefore, in the general case where not all interfaces are using the same driver, in the absence of something to deal with it, the order the interfaces get their driver's loaded in not deterministic. Eg, if I had (say) an Intel and a Broadcom NIC - then according to what you wrote, it's indeterminate which driver will load first. Thus it's indeterminate whether the Intel or Broadcom NIC would get to be eth0. The same thing with multiple SCSI interfaces - something I have personally suffered from in the past. Now, if you are saying that absent udev randomising things, the kernel will always load things in the same order - well I'll buy that. But it might have helped if you'd said that as it wasn't obvious from anything you wrote. Otherwise, I'm missing something - but that wouldn't be the first time ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: > Reportedly, Linux hotplug already had the same problem. OK, that's what I'd have been seeing in the past then. > During initialization, the kernel walks through the bus or busses it > finds in order to locate all devices and enables them by calling the > responsible driver init routines with information about the physical > devices which were found. This means the names will be stable if all > needed drivers are compiled into the kernel (in absence of deliberate > sabotage by the drivers themselves). > > If there's no compiled-in driver for some device, a so-called hotplug > event is generated Right. That explains a lot. So if the driver is built in then devices will be stable and determinate, if not then they won't. Which I guess means that a custom kernel with all drivers needed compiled in will have stable devices, but a general purpose one with loads of modules won't ? And as the vast majority of systems run generic modular kernels ... And udev comes along with a mechanism to remember device-name mappings and "unscramble" things in a determinate way. And then udev gets borged by the freedesktop lot and we're waiting for vdev to be ready to replace it ? > I've designed and implemented a complete hotplugging system for a > Linux-based UTM appliance which took care of preserving this order in > the past. But apparently, this idea doesn't have many fans. My suspicion is that your use case isn't all that common - well it's common enough, just a small fraction of systems. And people making "appliances" will have more control over what goes into the system - eg do their own kernels with all drivers included, and run on a limited range of hardware. Those will be far outweighed by the general purpose systems with random hardware. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Studying C as told. (For help)
On 06/23/2016 11:26 AM, Adam Borowski wrote: ... [1]. Actually, the English alphabet had more letters: þ, ð, ƿ[2] and ȝ, but they got dropped as early printing presses imported from Germany lacked these characters. Before the technology was copied and fonts could be manufactured domestically, the English suddenly had orders of magnitude more reading material lacking their letters than older handwritten works. (This is a gross simplification.) So let's have this in mind when you skip support for non-modern-English characters. Funny how this is now the other way around with ß. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: > That's you're preferred set of workarounds. I suspect that we're all in "violent agreement" that different users (or types of users) have different preferences and priorities. In the general case there is definitely an issue to be solved - just different approaches to doing it. You appear to be approaching it from the PoV of an appliance builder. You have known hardware, can compile in all required drivers, and so the interface names (just based on discovery order/bus location) are deterministic until you alter something yourself. I approach it from the PoV of an admin running "random" hardware (generally what I get as hand-me-downs from the Windows guys !). For me, using MAC addresses & udev rules works fine, and it's easy to manage - but I recognise why it won't work for your appliances and some other situations. For some, neither of these is acceptable - hence them forcing stupid bus-location based device names on people. For some, particularly those with just one wired NIC, it's probably a case of "Meh, what's all the fuss about, the kernel just calls it eth0". The main thing is - there are solutions for each of us, as long as we hold the freedesktop guys at arms length. But after this discussion, I have a better understanding of what goes on in the background for my NICs to appear and get a name :-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat wrote: > I can neither count on being 'in control of hardware' nor on 'people > editing configuration files'. Then apologies, it appears I misunderstood your position. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] some fun
On 06/29/2016 08:14 PM, emnin...@riseup.net wrote: Since we're so serious may be some fun is nice, making life easier ... :) I stumbled upon this by chance and i liked it a lot (I post the link although i think probably many of you know it already): http://systemd-free.org/img/systemd-can.jpg It made me laugh. Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] some fun
emnin...@riseup.net wrote: > Since we're so serious may be some fun is nice, making life > easier ... :) I stumbled upon this by chance and i liked it a lot (I > post the link although i think probably many of you know it already): > > http://systemd-free.org/img/systemd-can.jpg That lightened up my day, while I was trying to get my head round some (old) software (to manage a phone system) written in Java that doesn't run with a current JRE, and trying to stop a service on an old Windows 2003 Server. One service just wouldn't stop, so I thought "I'll just kill it in task manager" - but there was no similarly named process. Checked the properties of the service, and it's one of many that are a run by svc - and in task manager there were 11 instances of this svc ! I guess that'll be the end goal for the systemd guys, when they can achieve that level of obfuscation, it'll stop people bypassing their service manager tools ! Had to reboot the server in the end - but then that's the Windows way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] inittab question
emnin...@riseup.net wrote: > Dealing with a login (manager) problem, i looked into my /etc/inittab > and i found this: > > --- > # Note that on most Debian systems tty7 is used by the X Window System, > # so if you want to add more getty's go ahead but skip tty7 if you run > X. # > 1:2345:respawn:/sbin/getty 38400 tty1 > 2:23:respawn:/sbin/getty 38400 tty2 > 3:23:respawn:/sbin/getty 38400 tty3 > 4:23:respawn:/sbin/getty 38400 tty4 > 5:23:respawn:/sbin/getty 38400 tty5 > 6:23:respawn:/sbin/getty 38400 tty6 > --- > > Is that correct? > > I'd have expected any line to be: > > --- > 1:12345:respawn:/sbin/getty 38400 tty1 > 2:12345:respawn:/sbin/getty 38400 tty2 > ... Yes, on Debian the default runlevel is 2, and that's how they set the console logins. I guess they reckon that if anyone wants to use the other runlevels then they'll have enough knowledge to adjust this as required. No idea why they don't just set them all as 2345 - that's probably one of those "someone knew, eons ago - and it probably seemed like a good idea at the time" things. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UPdate error
On 07/07/2016 08:02 AM, Paweł Cholewiński wrote: Hi, during "apt-get update" error appear "Error http://auto.mirror.devuan.org jessie-security/main amd64 Packages Undetermined Error". When I looked at "http://auto.mirror.devuan.org/merged/dists/jessie-security/"; address has changed to "http://amprolla.devuan.org/merged/dists/jessie-security/"; and another error appeared "The page isn't redirecting properly Pale Moon has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies." With another browser I can see similar error. I think, amprolla admin action is needed. Ja, I see the same thing since morning (+9GMT). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UPdate error
On 07/08/2016 08:13 AM, Daniel Reurich wrote: On 08/07/16 03:28, Jaromil wrote: On Thu, 07 Jul 2016, hellekin wrote: On 07/06/2016 11:02 PM, Paweł Cholewiński wrote: Hi, during "apt-get update" error appear "Error http://auto.mirror.devuan.org jessie-security/main amd64 Packages Undetermined Error". Same here: W: Failed to fetch tor+http://devuanfwojg73k6r.onion/merged/dists/jessie-security/main/binary-amd64/Packages Maximum (10) redirects followed don't worry its Nextime working on the amprolla pipes this is expected its called "the beta rumble" I believe this issue is fixed now. Was an issue with the redirects. I love it. I can feel Devuan is alive! Thanks guys! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd==bad
On 07/08/2016 09:23 AM, Hughe Chung wrote: Who was the organizer of the conference? How they allowed frequent interruption by the idiot during the presentation? It was a real video footage. A drunken idiot went to the stage at the end of presentation carrying a bear bottle on one hand. I posted the video link to other FOSS forum. Action outweighs thousands words of the person. The time will tell how much damage would systemd cause on FOSS ecosphere overall. Empty promises of systemd. Absolutely. Lennart's attitude of "it's free, so don't complain" and "no one is forcing you to use it" is deceptive. If I make a calculator and release it under an open source license, I might be able to use that line. You can't have that attitude when you are making (what should be) inter-operable components of an operating system. He continually commits logical fallacies and says "You should know..." He seems very snobby. The beer part was over the top. They should have never given him a microphone. He's obviously a bully and therefore insecure. He has something to prove. This is why I am horrified. The Debian Technical Committee let themselves be bullied and by doing so have proven that they cannot be trusted to protect our freedom. You would think that Michael Tiemann would speak out, but I guess he has to be careful with his meal ticket. Shall we make a web site that documents sellouts in the tech industry? I think "name and shame" is appropriate with this level of depravity. If we can't trust them, word should get out the their opinions are bought. That is my free opinion ;) Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng