- Grml-devel - lists.mur.at

Research survey: Impact of Microsoft Acquisition of GitHub
by Asavaseri Natnaree 06 Aug '18

06 Aug '18

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545; min-height: 14.0px} Dear Grml contributors, I am Natnaree Asavaseri and currently undertaking a research internship at Nara Institute of Science and Technology, Japan. As a part of my research, I am analyzing the impact of Microsoft's acquisition of GitHub. I would like to conduct a survey to understand how developers perceive the Microsoft's acquisition of GitHub, especially from contributors to Linux distributions and BSD families. So please consider voicing your opinion by allowing us up to 5 minutes to complete our short survey. https://goo.gl/forms/lbIL5qsinDRQyTaK2 We would like to remind you that participation in this survey is completely voluntary and your identity is hidden for anonymity. Thank you in advance for your assistance. Natnaree Nara Institute of Science and Technology, Japan

1 1

Research survey: Impact of Microsoft Acquisition of GitHub
by Asavaseri Natnaree 09 Jul '18

09 Jul '18

Dear Grml developers, I am Natnaree Asavaseri and currently undertaking a research internship at Nara Institute of Science and Technology, Japan. Note that we are not biased to either GitHub or Microsoft, and this is purely from an empirical research perspective.Â As a part of my research in the field of Software Engineering (SE), my professors and I are analyzing the impact of Microsoft's acquisition of GitHub. The main purpose of my survey is understanding how developers perceive the Microsoft's acquisition of GitHub, especially from contributors to Linux distributions and BSD families. If the survey is successful, we will publish our findings at SE academic venues (journals or conference).Â So please consider voicing your opinion by allowing us up to 5 minutes to complete my short survey.Â https://goo.gl/forms/lbIL5qsinDRQyTaK2Â We would like to remind you that participation in this survey is completely voluntary and your identity is hidden for anonymity. Thank you for your time in advance.Â Best regards,Â NatnareeÂ Nara Institute of Science and Technology, Japan

1 0

Sponsoring request?
by Michael Prokop 22 Nov '17

22 Nov '17

Hi, we received the following request (quoting the original, german only sorry) via mail: | mein Name ist Leonie Kaiser, bin Redakteurin bei Betrugstest.com und bin hier auch fÃ¼r Outreaches und Kommunikation zustÃ¤ndig. | WÃ¤hrend dieser TÃ¤tigkeit bin ich auf die MÃ¶glichkeit grml zu sponsern gestoÃŸen. Da wir uns in letzter Zeit auf Open-Source-Projekte fokussieren, wÃ¤ren wir daran interessieren euch zu unterstÃ¼tzen. | Wie du hier sehen kannst hat auch schon Inkscape.org ihr Vertrauen geschenkt. Wir wÃ¼rden uns freuen, auch euch finanziell bei eurer Arbeit auszuhelfen. | Seid ihr an so einer Kooperation interessiert? So they are offering sponsorship for linking to Betrugstest.com - and Inkscape is doing this already, see: https://inkscape.org/en/support-us/sponsors/ Before clarifying any details I wanted to ask if there are any objections against doing that. If the amount is reasonable enough we could rent another server which would help us in refreshing/redoing our (currently quite stuck) infrastructure. Opinions? regards, -mika-

3 2

Suggestion for new Grml developer
by Michael Prokop 23 Jun '17

23 Jun '17

Hi folks, you might have noticed many contributions by my friend and working colleague Darshaka Pathirana over the last few months. Darsha did great work especially with regards to getting the systemd integration into a usable state and testing our daily ISOs and RC version. I'd like to have Darsha as a full Grml team member and therefore kindly ask for your feedback regarding addding him as a Grml developer. Please vote with your [N]ACK! :) regards, -mika-

6 6

Grml - new stable release 2017.05 available
by Michael Prokop 31 Mai '17

31 Mai '17

Hi, we said we'll release by the end of May, and here we are! The stable release of Grml version 2017.05 with codename 'Freedatensuppe' is available and just hitting our mirrors. More information about this release is available in the release notes of Grml 2017.05: https://grml.org/changelogs/README-grml-2017.05/ The (lots(!) of) changes between the release candidate version (2017.05-rc1) and the stable release are documented at: https://grml.org/changelogs/README-grml-2017.05/#changes-between-rc-and-sta… Grab the latest Grml ISO(s) and spread the word: https://grml.org/download/ If you should notice any bugs please let us know: https://grml.org/bugs/ We welcome constructive feedback, suggestions for improvement and your contributions, please just reach out to us: https://grml.org/contact/ Thanks to everyone contributing to Grml and this release! Happy Grml-ing, -mika-

1 0

First Release Candidate of Grml version 2017.05 available
by Michael Prokop 21 Mai '17

21 Mai '17

Hi, so *finally* we did it again, jey! The first release candidate of the upcoming Grml version 2017.05, code-named 'Freedatensuppe' is available. This Grml release provides fresh software packages from Debian testing (AKA stretch). As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release. For detailed information about the changes between 2014.11 and 2017.05 have a look at the official release announcement: http://grml.org/changelogs/README-grml-2017.05-rc1/ Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of May (2017 *cough* :)). Thanks to all contributors! regards, -mika- - for the Grml.org project

4 14

Any plans for a new release?
by Johan Kröckel 12 Dez '15

12 Dez '15

Hey, at first I wanna say: nice work! I love grml. Are there any plans for a new stable release, seeing that the current release is over one year old and predates the last Debian stable release? As an interim solution, one of the daily images with signed check sums would be great. Thank you very much and keep it up Johan

2 1

about grub for grml
by Gregory Amaudruz 17 Nov '15

17 Nov '15

I understand that on the grub file you need to put all of this, so that you can select the proper version when you boot. If I have a 8GB USB stick: 1 partition of linux of 4GB /dev/sdb1 * and 1 partition of win 95 4GB /dev/sdb2 then I put all the operating systems ISO files on /dev/sdb1 and make it bootable. The problem I have, is that if I boot the operating system then when it loads up and I want to have access to the hard drives, well I do not have access to /dev/sdb2 since it does some sort of a loop back on the entire USB stick or /dev/sdb. Well when you load it up it would be /dev/sda when you are installing the grub from linux onto the USB stick, it is /dev/sdb But is there any way that I could make the loop back just for the first partiton and have access to the second partion? I suppose I would have to mount the second partition to have access to it, but that is okay. But I want to have access to the second partition. How do I do that?? What do I need to put in the grub entry to have access to the second partiton??? Because I do not have access to it. The grub entry loop back is for the entire USB stick! Could you give me the 3 Grub Entries??? the GRML 64 full , the GRML 64 small and the GRML 32 small ? # Begin /boot/grub/grub.cfg set default=0 set timeout=8 insmod ext2 set root=(hd0,1) submenu "grml64-full " { set isofile="/boot/iso/grml64-full_2014.11.iso" menuentry "Grml Rescue System 64bit" { iso_path="/boot/iso/grml64-full_2014.11.iso" export iso_path loopback loop (hd0,1)$iso_path set root=(loop) kernelopts=" ssh=foobarbaz toram " export kernelopts configfile /boot/grub/loopback.cfg } ... } submenu "grml64-small" { set isofile="/grml/grml64-small_2014.11.iso" menuentry "Grml Rescue System (grml64-small_2014.11.iso)" { insmod part_msdos msdos insmod diskfilter mdraid1x insmod xfs set root='mduuid/4223' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='mduuid/4223' 666 else search --no-floppy --fs-uuid --set=root 666 fi iso_path="/grml/grml64-small_2014.11.iso" export iso_path kernelopts=" ssh=secret nobeep toram ip=10.0.2.15::10.0.2.2:255.255.255.0:grml:eth0:off dns=10.0.2.3 live-media=/dev/sda1,/dev/sdb1,/dev/md127 " export kernelopts loopback loop "/grml/grml64-small_2014.11.iso" set root=(loop) configfile /boot/grub/loopback.cfg } ... } submenu "grml32-small " { set isofile="/grml/grml32-small_2014.11.iso" menuentry "Grml Rescue System (grml32-small_2014.11.iso)" { insmod part_msdos insmod ext2 set root='hd1,msdos2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 --hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2 d0e82ae9-cb7a-4dd5-859c-b375daa9cb2f else search --no-floppy --fs-uuid --set=root d0e82ae9-cb7a-4dd5-859c-b375daa9cb2f fi iso_path="/grml/grml32-small_2014.11.iso" export iso_path kernelopts=" " export kernelopts loopback loop "/grml/grml32-small_2014.11.iso" set root=(loop) configfile /boot/grub/loopback.cfg } ... }

2 1

Mailinglisttest
by Alexander Wirt 17 Aug '15

17 Aug '15

This is just a test for our jessie mailman. Alex

1 0

Re: [Grml-devel] Shared screen locking solution for live distributions in Debian
by Klaus Knopper 13 Jan '15

13 Jan '15

Hello Sajolida, On Wed, Dec 31, 2014 at 02:03:15PM +0000, sajolida wrote: > Hi, > > I'm part of the people working on Tails, a live distribution that aims > at preserving privacy and anonymity: https://tails.boum.org/. Tails is > currently lacking a screen locker and this has been a frequent feature > request. See https://labs.riseup.net/code/issues/5684. > > For example, as Tails is been adopted more and more by journalists, > they want to be able to leave their computer unattended in their > office to go to the toilets for a minute and have their screen locked. > > I'm writing this emails to various Live distributions based on Debian > (Knoppix, Grml, Jondo, Kali, Debian Live, and Tanglu). I'm also > putting Micah Lee in copy as he has shown particular interest in this > feature. > > I've been investigating the screen locking mechanism of those various > Debian based live distributions, and I found out that none of them had > a real mechanism to do so. They either: > > - Do not provide any screen locking mechanism (Knoppix, Grml, > Jondo Live). Actually, Knoppix disables/circumvents the standard Debian screen locking mechanism because there is no unlocking possible once the screenlock is active. All passwords are invalid and locked. > - Either rely on their default password to unlock the screen (Kali, > Tanglu, Debian Live). > > The purpose of this email is to know whether you would be interested > in working on a common Debian package to provide a generic screen > locking solution for Debian based live distributions. > > The core usability issue that we are facing here is the one of the > unlocking password. As we are live distributions, there either is no > password or a default one. "no password" in the sense of "there is no valid authentication password", i.e. no backdoor. Sometimes, people mean "ANY password" if they say "no password", which is not the case for Knoppix. Again, all passwords are invalid and locked. > Still, screen locking only make sense if > the user is able to use a custom password. Also, screen locking makes only sense if there is the apparent possibility that someone else has physical access to the computer while the user is not paying attention. Why would I lock the screen if I'm the only one using the computer in a safe environment, and shut it down and remove the live medium when I'm done with my work. > As an interesting exception, > note that in Jondo Live, the user is prompted for a user password on > boot. Knoppix design is not to ask anything from the boot screen till the running graphical desktop, with the possible exception of an encrypted personal overlay. > In Tails the user can set up an administration password but this > is disabled by default for security reasons so we cannot rely on this > for screen locking. > > During our last monthly meeting we came up with the idea of asking for > a custom password *in the process of locking the screen* for the first > time. So, when is the right time to lock the screen? Debian does this by default when the computer goes to standby or the notebook lid is closed. In this case, the user will hardly pay attention to a dialog asking for a password. > For example, in GNOME, when doing Meta+L for the first time, the > user would be prompted to enter a screen locking password, then only > the screen would get locked. If she locks the screen again, the same > password would be reused. A "voluntary screenlock button", asking for a new screenlock (not necessarily a login) password could be worth a try. Regards -Klaus

2 1