Re: [DNG] Vote for/against netman name change
On 2016-02-04 07:03, Edward Bartolo wrote: > > Do you agree to renaming netman? NO -- al3xu5 / dotcommon Say NO to copyright, patents, trademarks and any industrial design restrictions. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
+1 SWS On Feb 5, 2016 7:46 PM, "aitor_czr" wrote: > On 02/05/2016 07:18 PM, Go Linux > wrote: > > Every name I came up with was already in multiple use. I also thought of > netbarx which is completely unique. Kinda like it actually. > > golinux > > > IMO, netbarx is the best choice :) > > Aitor. > > ___ > 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] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 09:38:10PM -0500, fsmithred wrote: > On 02/05/2016 08:48 PM, Joel Roth wrote: > > Didier Kryn wrote: > >> > >> The ability to brick the motherboard is brand new. Therefore admins > >> should be seriously protected and warned against this eventuality, at least > >> until it percolates into the general culture. > > > > IIUC, this means malware will now be able to not only > > erase, but to render its targets unbootable. > > Also creating a new hardware recovery business. > > It seems somewhat bleak. Am I overreacting? > > > > > > Go with the flow, dude. It's worth the risk of malware for the benefit of > having your vendor push firmware updates whenever they want. (Did I get > that right?) > > Actually, I think you're underreacting. I would edit your statement to > say, "...render its targets unbootable or worse." Malware authors and > others who might have bad intentions for your hardware generally want it > to keep working. Perhaps not in warfare. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 02/05/2016 08:48 PM, Joel Roth wrote: > Didier Kryn wrote: >> >> The ability to brick the motherboard is brand new. Therefore admins >> should be seriously protected and warned against this eventuality, at least >> until it percolates into the general culture. > > IIUC, this means malware will now be able to not only > erase, but to render its targets unbootable. > Also creating a new hardware recovery business. > It seems somewhat bleak. Am I overreacting? > > Go with the flow, dude. It's worth the risk of malware for the benefit of having your vendor push firmware updates whenever they want. (Did I get that right?) Actually, I think you're underreacting. I would edit your statement to say, "...render its targets unbootable or worse." Malware authors and others who might have bad intentions for your hardware generally want it to keep working. fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Didier Kryn wrote: > > The ability to brick the motherboard is brand new. Therefore admins > should be seriously protected and warned against this eventuality, at least > until it percolates into the general culture. IIUC, this means malware will now be able to not only erase, but to render its targets unbootable. Also creating a new hardware recovery business. It seems somewhat bleak. Am I overreacting? -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On 02/05/2016 07:18 PM, Go Linux wrote: Every name I came up with was already in multiple use. I also thought of netbarx which is completely unique. Kinda like it actually. golinux IMO, netbarx is the best choice :) Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On Fri, Feb 05, 2016 at 09:47:45PM +0100, shraptor wrote: > On 2016-02-05 21:12, Edward Bartolo wrote: > >Hi, > > > >I will NOT name the project after myself; I even abstained from > >voting. My project was written to HELP; I am not after > >self-appraisal... > > That's too bad cause I honestly think netbarx is a real good name. > I urge you to reconsider, at least let it be included in vote. I never associated barx with the author's name. I thought of my dear late dog, who was always exploring everything he encountered. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On Fri, 2/5/16, shraptor wrote: Subject: Re: [DNG] Change netman into another name. To: "Edward Bartolo" Cc: "dng" Date: Friday, February 5, 2016, 2:47 PM On 2016-02-05 21:12, Edward Bartolo wrote: > Hi, > > I will NOT name the project after myself; I even abstained from > voting. My project was written to HELP; I am not after > self-appraisal... That's too bad cause I honestly think netbarx is a real good name. I urge you to reconsider, at least let it be included in vote. It is NOT named after you, Edward Bartolo, but does incorporate part of a nick you use elsewhere. I'm sure that there are plenty of people on this list that do not know about edbarx. netbarx is a bit of a play on words - barks > barx which makes it fun and unique IMO. If enough people like it and it wins the naming contest, would you nullify the vote? Just curious . . . golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 02/05/2016 01:20 PM, Steve Litt wrote: > On Fri, 5 Feb 2016 18:33:44 +0100 > Didier Kryn wrote: > >> People have always expected rm -rf / to destroy the OS. They >> also know that, from the keyboard, with root priviledge, they can >> destroy the partition table of the disk. All this is repairable by >> the admin her/himself. >> >> The ability to brick the motherboard is brand new. > > Not only brand new, but an entirely new level of consequence. > > > With a well backed up machine, there is absolutely no comparison > between loss of the system disk formatting and bricking of the mobo. > >> Therefore >> admins should be seriously protected and warned against this >> eventuality, at least until it percolates into the general culture. > > Yes. > > > SteveT > Along those lines, we should probably be taking notes on what motherboards are susceptible to this. Is there some way to test a motherboard to see if it's brickable this way without actually bricking it? Did anyone get the model number of the MSI notebook in the original thread at the Arch linux forum before that thread disappeared? fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On 2016-02-05 21:12, Edward Bartolo wrote: Hi, I will NOT name the project after myself; I even abstained from voting. My project was written to HELP; I am not after self-appraisal... That's too bad cause I honestly think netbarx is a real good name. I urge you to reconsider, at least let it be included in vote. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Vote for/against netman name change
YES ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
> > > > El 04/02/16 a las 21:17, edward Bartolo escribió: > >> El 04/02/16 a las 21:17, edward Bartolo escribió:Hi > All, > >> > > >> >I did a google search for netman but I was presented with several > >> >pages of results always pointing to other similarly named commercial > >> >projects. Therefore, I am thinking about changing netman's name into a > >> >unique name so that users would be able to be directed to the proper > >> >sites. > >> > > >> >I am suggesting this name: > >> >nm-devuan for network manager Devuan. > >> > > >> >I am open to other suggestions. > >> > > >> >Edward > > I did a google search of *NetBat* and it doesn't exist. > > *Bat* means *One* in basque language. > > Do you like it? > > Gero arte! > > Aitor. > --- NetBat would be interesting. NetBarx is good also. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Vote for/against netman name change
> -- > > Message: 6 > Date: Fri, 5 Feb 2016 07:28:32 +0100 > From: Edward Bartolo > To: dng > Subject: Re: [DNG] Vote for/against netman name change > Message-ID: > ju5r...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > Till now: (voting still open) > Voted YES: 5 > Voted NO: 4 > > I am abstaining from voting. > > Edwad > > > > YES ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
Hi, I will NOT name the project after myself; I even abstained from voting. My project was written to HELP; I am not after self-appraisal... In fact, after just two days back in August I had already a functioning backend and GUI, but I continued to listen to what others wanted. I could have stayed with what just worked for me but I didn't. This interpretation by some that I am after self gratification is wrong. Working for Devuan and free software does not earn me money: it only earns me more fatigue and less free time. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On 2016-02-05 18:15, Go Linux wrote: Every name I came up with was already in multiple use. I also thought of netbarx which is completely unique. Kinda like it actually. golinux I vote for netbarx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
Hi, This is a short list of possible future names for netman with a google suggestion count below 3. a) wifiwaverider -> 1 google suggestions b) netgalloper (instead of netrunner) -> 2 google suggestions c) ostiumreticulum (network door in Latin) --> 2 google suggestions d) easynetaid -> 1 google suggestion Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn wrote: > People have always expected rm -rf / to destroy the OS. They > also know that, from the keyboard, with root priviledge, they can > destroy the partition table of the disk. All this is repairable by > the admin her/himself. > > The ability to brick the motherboard is brand new. Not only brand new, but an entirely new level of consequence. With excellent backups, rm -rf / or even dd if=/dev/zero of=/dev/sda1 is correctable with a few hours of work, on the premises, with only resources on the premises. Bricking the mobo means buying a new mobo, and in all likelihood a whole computer. Unless the mobo is still being sold, this means a brand new hardware cost/benefit analysis. If you don't live near a good computer store, it could mean mail order, with the several days' shipping and the RMA nonsense, while your business languishes. I could see an rm -rf causing a business to be down for a couple weeks, complete with angry threats and counterthreats between business and computer vendor. Anybody who's ever had to buy a computer to fix a current outage, instead of as a planned process, knows you're going to get an inferior computer for an inflated price, and incur the kind of pressure that makes mistakes more probable. It's not a whole lot different than having to buy a car tonight because your old car blew up this afternoon and you'll get fired if you don't drive to work tomorrow. With a well backed up machine, there is absolutely no comparison between loss of the system disk formatting and bricking of the mobo. > Therefore > admins should be seriously protected and warned against this > eventuality, at least until it percolates into the general culture. Yes. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, 5 Feb 2016 11:39:15 + Simon Hobson wrote: > KatolaZ wrote: > > > I don't get why any of those occasional "sysadmin-wannabe" users you > > have described above would ever need to mess around with their UEFI > > by hand. > > They don't. But certain tasks they run apparently can do - did > someone mention Grub updating it ? New kernels and corresponding initramf files are created every couple weeks, and there's a need to seemlessly get the system to boot the latest. I imagine there are solutions for this that don't involve mods to EFI vars. One I imagine is that grub is permanently set to kernel kernel.symlink with initramfs initramfs.symlink, so that changing kernels is nothing but changing symlinks. I think hard links would work too. If that doesn't work in such a low level of boot (and I don't know what it wouldn't), just name the latest kernel kernel.latest. As far as poettering's necessary-to-life-itself thing of telling the EFI what to boot next, I'm pretty sure this could be done a little farther from the EFI. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 05/02/2016 16:33, Rainer Weikusat a écrit : "Rainer H. Rauschenberg" writes: On Thu, 4 Feb 2016, Simon Hobson wrote: [...] Besides that I don't think mounting EFI-vars r/w is a good idea as a system default and I don't think the user not having read all the relevant documentation (spread out over various places) is to blame when system behaviour *changes* in such a drastic way (bricking hardware by deleting "files"). 'Virtual filesystems' have existed since at least 1985 (SunOS 2.0) and Linux has supported various types of virtual filesystems for a really long time. Consequently, there's no "system behaviour which changed in a drastic way" here. What precisely happens when some program executes an unlink system call depends on the filesystem implementation. Even leaving this aside, there's a very simple rule-of-thumb here, namely, "if you don't know what it's good for then *don't* delete it" (unless you're making an experiment and you're willing to accept that the outcome was caused by you and not by the universe being nasty to you). People have always expected rm -rf / to destroy the OS. They also know that, from the keyboard, with root priviledge, they can destroy the partition table of the disk. All this is repairable by the admin her/himself. The ability to brick the motherboard is brand new. Therefore admins should be seriously protected and warned against this eventuality, at least until it percolates into the general culture. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
On Fri, 2/5/16, aitor_czr wrote: Subject: Re: [DNG] Change netman into another name. To: "Edward Bartolo" , "Teodoro Santoni" , dng@lists.dyne.org Date: Friday, February 5, 2016, 10:41 AM El 05/02/16 a las 17:14, Teodoro Santoni escribió: > Although I'd prefer butplug, I suggest netrunner, netvan, igign, ethcable. > Netbarx is a cool name, though. I also thought in Netrunner, but there is a distribution with this name: Netrunner OS. Aitor. Every name I came up with was already in multiple use. I also thought of netbarx which is completely unique. Kinda like it actually. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
El 05/02/16 a las 17:14, Teodoro Santoni escribió: Although I'd prefer butplug, I suggest netrunner, netvan, igign, ethcable. Netbarx is a cool name, though. I also thought in Netrunner, but there is a distribution with this name: Netrunner OS. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: > But "the hardware" didn't "break". Certain vendor-supplied software > reportedly ceases to function if certain EFI variables are deleted. That is the sort of linguistic gymnastics that vendors use to get out of accepting responsibility for stuff. I think most people would equate with "it used to work", "X happened", "it now doesn't work" as being "X broke it". It no longer works, it's broken. Using linguistic gymnastics to try and call it something else doesn't change the fundamental fact that "it no longer works, therefore it's broken". It is true that the "true hardware" didn't "break", but in this context, "the hardware" is the sum of the physical hardware, the firmware it runs, and the configuration files for that firmware. I see your argument that it's "the user broke the firmware" - but the end result is still that "the hardware no longer works" - ie it's broken. I also agree 100% that the firmware writers have royally f***ed up on this. Deleting files off a disk can be recovered from (at least in terms of, you can re-install an OS on it) and you still have working hardware. Having a "software" system where deleting a file makes it unrecoverable is inexcusable. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 04:14:49PM +, Rainer Weikusat wrote: [cut] > > It's not really that simple: This really an interesting multi-level > fuck-up. > > - the systemd people shouldn't just mount the efivarfs r/w > because that's convenient for them and tell people to get lost > if they think otherwise > > - someone who runs rm -rf on a group of mounted filesystems > should understand that whatever was affected by that didn't > chose to unlink itself > > - the people who implemented the firmware shouldn't have > implemented that such that it ceases to work if userspace > software performs perfectly legitimate operations such as > deleting unprotected variables > > [- the issue shouldn't be generalized until the answer becomes > 42 ] > I agree that it's surely a mixture of different fuck-ups, but there is no reason to make it easier for people to accidentally brick their laptops. To the best of my knowledge, you can't brick your laptop by unlinking any file in any other virtual filesystem. The most you can get is a kernel panic, in a few very specific situations. You reboot and you are fine. With UEFI is apparently a completely different story, so users should have been told, IMHO. 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
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
KatolaZ writes: > On Thu, Feb 04, 2016 at 10:02:51PM +, Simon Hobson wrote: >> Arnt Karlsen wrote: >> >> > ..me, I do not see any point in keeping it mounted at all. >> > Whenever such a need arises, it should be mounted read-only. >> > If a need to write to /sys/firmware/efi/efivars should happen, >> > the machine should first be taken off-line, backed-up etc out >> > of production and into a maintenance mode, where mounting >> > /sys/firmware/efi/efivars read-write, _may_ be warranted. >> >> >> Yes, in an ideal world where everyone is a "full time admin". But in >> the real world, more systems are used by "average users" who just >> expect "stuff to work". So IMO, you either build stuff that works (or >> at least is up-front about what's wrong), or you leave these people >> stuck with "stuff that's broken" and regardless of how right you are, >> the pi**ed off user will be moaning about how "rubbish and >> complicated this Linux is - best go back to Windows". >> > > I don't get why any of those occasional "sysadmin-wannabe" users you > have described above would ever need to mess around with their UEFI by > hand. If you need to do that, you should first *know* what you are > doing. It's not really that simple: This really an interesting multi-level fuck-up. - the systemd people shouldn't just mount the efivarfs r/w because that's convenient for them and tell people to get lost if they think otherwise - someone who runs rm -rf on a group of mounted filesystems should understand that whatever was affected by that didn't chose to unlink itself - the people who implemented the firmware shouldn't have implemented that such that it ceases to work if userspace software performs perfectly legitimate operations such as deleting unprotected variables [- the issue shouldn't be generalized until the answer becomes 42 ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Edward Bartolo writes: > The argument of those who support protecting the hardware against a > probable breakage are logically sound: I support them. But "the hardware" didn't "break". Certain vendor-supplied software reportedly ceases to function if certain EFI variables are deleted. And the vendor apparently couldn't be bothered with making these variables undeletable if they were intended to be undeletable. In an ideal world, this should be covered by warranty as that's obviously a technical defect, however, people working for said vendors will doubtlessly also prefer to blame someone else instead. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 06/02/16 00:18, Hendrik Boom wrote: On Fri, Feb 05, 2016 at 11:39:15AM +, Simon Hobson wrote: Of course, unless you physically remove support for the virtual filesystem, then there's nothing to stop any program with enough privileges to mount the filesystem when it wants. And that's the proble with the root model of administrative software. You either have all the privileges to do anything, or none. There's no mechanism to be granted jusst the provileges actually needed. hence the use of groups for specific purposes, with group ownership of certain things ... but the core idea that the person who buys the gear is not ultimately locked out of anything means that they cannot be protected from themselves if they really insist ... that is as it should be. But they should be warned, and not have nasty traps placed in front of them ... especially very nasty traps. This shifts significantly if the owner of the gear wants to leave it physically in the hands of a user they do not trust, then locking it down is reasonable. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
"Rainer H. Rauschenberg" writes: > On Thu, 4 Feb 2016, Simon Hobson wrote: [...] > Besides that I don't think mounting EFI-vars r/w is a good idea as a > system default and I don't think the user not having read all the > relevant documentation (spread out over various places) > is to blame when system behaviour *changes* in such a drastic way > (bricking hardware by deleting "files"). 'Virtual filesystems' have existed since at least 1985 (SunOS 2.0) and Linux has supported various types of virtual filesystems for a really long time. Consequently, there's no "system behaviour which changed in a drastic way" here. What precisely happens when some program executes an unlink system call depends on the filesystem implementation. Even leaving this aside, there's a very simple rule-of-thumb here, namely, "if you don't know what it's good for then *don't* delete it" (unless you're making an experiment and you're willing to accept that the outcome was caused by you and not by the universe being nasty to you). Random story which fits in nicely here: Once upon a time in the past, I witnessed a Real Man[tm] being conquered by a computerized spin dryer. Not happy with reading or even following the operating instructions, he chose to try to beat it into submission by hammering his fists onto the control panel instead. This caused the machine to display "Error". Apparently infuriated by that, he hit it more violently but the display just stubbornly showed this single word. After a while, the man would tire of the exertion and stop beating the appliance. The display then changed back to signal that the machine was ready for being used. He would then randomly press a few buttons but without the intended effect. Then go back to hitting it. And the display went back "Error". I witnessed a few cycles before before leaving laundromat. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
Good afternoon, 2016-02-03 8:05 GMT+01:00, Edward Bartolo : > Hi All, > > I did a google search for netman but I was presented with several > pages of results always pointing to other similarly named commercial > projects. Therefore, I am thinking about changing netman's name into a > unique name so that users would be able to be directed to the proper > sites. > > I am suggesting this name: > nm-devuan for network manager Devuan. > > I am open to other suggestions. > > Edward Although I'd prefer butplug, I suggest netrunner, netvan, igign, ethcable. Netbarx is a cool name, though. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 11:39:15AM +, Simon Hobson wrote: > > Of course, unless you physically remove support for the virtual > filesystem, then there's nothing to stop any program with enough > privileges to mount the filesystem when it wants. And that's the proble with the root model of administrative software. You either have all the privileges to do anything, or none. There's no mechanism to be granted jusst the provileges actually needed. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
El 03/02/16 a las 08:30, Edward Bartolo escribió: Hi All, I did a google search for netman but I was presented with several pages of results always pointing to other similarly named commercial projects. Therefore, I am thinking about changing netman's name into a unique name so that users would be able to be directed to the proper sites. I am suggesting this name: nm-devuan for network manager Devuan. I am open to other suggestions. Edward How about: netc-manager because it's written in C. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Change netman into another name.
El 04/02/16 a las 21:17, edward Bartolo escribió: El 04/02/16 a las 21:17, edward Bartolo escribió:Hi All, > >I did a google search for netman but I was presented with several >pages of results always pointing to other similarly named commercial >projects. Therefore, I am thinking about changing netman's name into a >unique name so that users would be able to be directed to the proper >sites. > >I am suggesting this name: >nm-devuan for network manager Devuan. > >I am open to other suggestions. > >Edward I did a google search of *NetBat* and it doesn't exist. *Bat* means *One* in basque language. Do you like it? Gero arte! Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
KatolaZ wrote: > I don't get why any of those occasional "sysadmin-wannabe" users you > have described above would ever need to mess around with their UEFI by > hand. They don't. But certain tasks they run apparently can do - did someone mention Grub updating it ? So one scenario (which I think is the most likely) goes like this : User instructs system to install updates (whether that's via cli "apt-get ..." or by clicking in a GUI). One (or more) of those updates triggers a Grub update. Grub runs update process, and for whatever reason wants to update UEFI settings. To cater for this, certain camps have set the default to "mount the virtual filesystem r/w all the time" - which has the dangers discussed. Some are suggesting that the user should have to manually mount it for these occasions. My feeling is that this puts an unnecessary technical burden on the less knowledgeable, some of whom will take the attitude that "it's broken" when updates don't install properly. My suggestion is to (re)mount r/w when this occurs - by default asking the user permission first - and either unmount or remount r/o afterwards. A config option could be provided (in a config file) so the utilities needing to do this could assume permission and do it transparently - *IF* the user/admin sets that option. Thos that don't want the filesystem mounted, ever, without them manually doing it can easily adjust fstab and settings to allow for that. IMO this caters for for those who want it to "just happen", for those that want to have to give permission each time, and those who want full manual control. Of course, unless you physically remove support for the virtual filesystem, then there's nothing to stop any program with enough privileges to mount the filesystem when it wants. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, Feb 04, 2016 at 10:02:51PM +, Simon Hobson wrote: > Arnt Karlsen wrote: > > > ..me, I do not see any point in keeping it mounted at all. > > Whenever such a need arises, it should be mounted read-only. > > If a need to write to /sys/firmware/efi/efivars should happen, > > the machine should first be taken off-line, backed-up etc out > > of production and into a maintenance mode, where mounting > > /sys/firmware/efi/efivars read-write, _may_ be warranted. > > > Yes, in an ideal world where everyone is a "full time admin". But in the real > world, more systems are used by "average users" who just expect "stuff to > work". So IMO, you either build stuff that works (or at least is up-front > about what's wrong), or you leave these people stuck with "stuff that's > broken" and regardless of how right you are, the pi**ed off user will be > moaning about how "rubbish and complicated this Linux is - best go back to > Windows". > I don't get why any of those occasional "sysadmin-wannabe" users you have described above would ever need to mess around with their UEFI by hand. If you need to do that, you should first *know* what you are doing. My2Cents 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
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer H. Rauschenberg wrote: > I think this is the road that led to systemd -- if you think Linux needs > to be "as easy as Windows" you tend to take away all the aspects that made > it superior (in my view). I think I didn't really express my position very well. I'm not advocating "taking all the good stuff away" - after all, I'm ready enough at work (a mostly MS shop) to describe the command prompt as "like Unix with all the useful stuff removed" :-) But if you ignore the needs of the majority, then you more or less consign the project to being "one of those obscure distros that few use". I'm not suggesting the Windows/SysemD route either - just lose the "guru or find somewhere else" attitude to users that some people seem to hold. And note that I proposed something that, IMO, treads the fine line between supporting those who want control, and those who are happy to let the system do it. One setting that defaults to control, but can be easily changed for those that are happy with the system dealing with it. And of course, for those that don't want it mounted at all, they can always remove it from fstab (or mark it as not automatically mounted). I believe that's the 3 use cases that will suit 99+% of users of all abilities. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
