Re: Debian Programming languages

[Alex Mestiashvili]

On 5/24/19 11:19 PM, Christian Groessler wrote:
> On 5/24/19 10:03 PM, Alex Mestiashvili wrote:
>> On 5/24/19 7:28 PM, Christian Groessler wrote:
>>> On 5/24/19 6:51 PM, john doe wrote:
 On 5/24/2019 6:14 PM, ghe wrote:
> Perl is happily off on it's own. "There's more than one way..." Boy is
> there ever. Nice to write, but it's next to impossible to understand
> other people's code. Python, IMHO, seems to be creeping up to replace
> it.
>>>
>>> I'm typically referring to perl as a "write-only" language. :-)
>>>
>>> But don't get me wrong, I like it...
>>>
>>> regards,
>>> chris
>>>
>> That is not true. The freedom to write unreadable code doesn't mean that
>> the language is bad.
> 
> 
> I guess you didn't notice the smiley in my message...
> 
> I'm sometimes having hmm.. let's say "problems" ... understanding what I
> had written ~10yrs ago. Typically regexp-related. That's not a problem
> of the language, but a problem in my understanding as I don't use perl
> on a day-to-day basis.
> 
> I stated "I like it", and that's true. I dislike python on the other
> hand...
> 
> regards,
> chris
> 

I did notice the smiley. But the jokes that perl is unreadable, looks
like line noise, write only, and so on, are repeated way too often and
decline Perl's reputation.

Well, the problem you described, isn't the problem of the language :)
Perl is easy to use and write condensed code, so many people abuse it
and write messy code.
Regexps can be also written in pretty clean multiline format with
comments should one want it.

So I basically came here to say that Perl is cool! :)

Best regards,
Alex

Re: Debian Programming languages

[Dekks Herton]

Paul Sutton  writes:

> Hi
>
> As I am trying to promote contributing to Debian,  what programming
> languages are mostly used?  I am asking as it helps to give people an
> idea of what they need to learn or will learn as part of helping.

AFAIK Kernel + low level plumbing are primarily Assembly,C,C++,Rust 

> I am guessing as the default command line interface is bash, then bash
> and bash scripting would be useful to learn but on top of that what
> would people suggest I try and promote.
>
> Not just on the coding side of things as we have markdown / html / css
> perhaps LaTeX for documentation.

For apps there are no hard and fast rules as there are a multitude of
langs used. Best to enquire of the devs of the particular app your
interested in.

> Thanks
>
> Paul

-- 
Regards.
 
PGP Fingerprint: 3DF8 311C 4740 B5BC 3867  72DF 1050 452F 9BCE BA00

Recommmended IDE for C++ 17 (gcc8)?

[rhkramer]

Is anyone here using an IDE for working on C++ code at the revision 17 level 
(aka gcc8), iiuc.  

I'm looking for something that will work on Jessie.

I've been trying to use version 5.3.2 of kdevelop (from a flatpack or whatever 
they call it) and have been running into problems.  *Maybe* it is because some 
of the files are using features of C++ 17.

Re: Debian Programming languages

[Kenneth Parker]

On Fri, May 24, 2019 at 12:15 PM ghe  wrote:

> On 5/24/19 9:08 AM, Paul Sutton wrote:
>
> > As I am trying to promote contributing to Debian,  what programming
> > languages are mostly used?
>
> C, perl, java, ruby, python, bash, that I know of. And probably several
> others. I don't recall seeing any COBOL, though :-)
>

COBOL?  How about https://packages.debian.org/stretch/open-cobol ?

   > OpenCOBOL implements substantial part of the COBOL 85 and
   > COBOL 2002 standards, as well as many extensions of the existent
   > compilers. OpenCOBOL translates COBOL into C and compiles
   > the translated code using GCC.

I may even Install this on my Stretch System, to bring back memories of my
IBM Mainframe Days, where I programmed, often heavily in COBOL, from 1974
to 1986.



-- 
> Glenn English
>
> Kenneth Parker

Re: [DNG] Linux system can be brought down by sending SIGILL to Systemd

[arne]

On Fri, 24 May 2019 23:43:49 +0200
arne  wrote:

> On Fri, 24 May 2019 14:01:35 -0700
> Fred  wrote:
> 
> > Hello,
> > I subscribe to the Devuan Linux mailing list.  This posting just
> > arrived and it appears quite important to Debian.
> > 
> >  Forwarded Message 
> > Subject:[DNG] Linux system can be brought down by sending
> > SIGILL to Systemd
> > Date:   Fri, 24 May 2019 22:04:34 +0200
> > From:   Martin Steigerwald 
> > To: DNG 
> > 
> > 
> > 
> > Hi!
> > 
> > Today in a Linux training a participant attempted to bring down
> > Debian workstation with Systemd by sending signals to PID 1 as I
> > invited them to try to bring down PID 1 while thinking for myself
> > that this would not be possible from my past experiences about
> > trying to bring down PID 1 – init – myself.  
> 
> # while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done
> ...^C
> 
> no problem here
> kernel 5.1.4 stretch amd64 with systemd
> 

Perhaps that test was a little too short so I let it run a little
longer:

# while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done
..^C

again no problem here.

I had no fear to run the script as I use systemd, so I know how to
use the SysReq keys very well ;)

Re: Debian Programming languages

[ghe]

On 5/24/19 3:19 PM, Christian Groessler wrote:

> I dislike python on the other hand...

I did too, when I looked at it a few years ago. But Python3 looks
reasonably civilized.

And so the interpreter replaces 4 spaces with a semicolon. I think I can
live with that...

-- 
Glenn English

Re: [DNG] Linux system can be brought down by sending SIGILL to Systemd

[arne]

On Fri, 24 May 2019 14:01:35 -0700
Fred  wrote:

> Hello,
> I subscribe to the Devuan Linux mailing list.  This posting just
> arrived and it appears quite important to Debian.
> 
>  Forwarded Message 
> Subject:  [DNG] Linux system can be brought down by sending
> SIGILL to Systemd
> Date: Fri, 24 May 2019 22:04:34 +0200
> From: Martin Steigerwald 
> To:   DNG 
> 
> 
> 
> Hi!
> 
> Today in a Linux training a participant attempted to bring down Debian
> workstation with Systemd by sending signals to PID 1 as I invited them
> to try to bring down PID 1 while thinking for myself that this would
> not be possible from my past experiences about trying to bring down
> PID 1 – init – myself.

# while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done
...^C

no problem here
kernel 5.1.4 stretch amd64 with systemd

Re: Debian Programming languages

[Michael Lange]

Hi,

On Fri, 24 May 2019 19:45:23 +0200
"Thomas Schmitt"  wrote:

(...)
> (Astounding how few languages are mentioned there.
>  No Piet ? http://www.dangermouse.net/esoteric/piet/samples.html
> )

seems like Piet isn't really a Debian programming language.
At least Debian seems to have some support for Brainfuck :-)
(https://curlie.org/Computers/Programming/Languages/Brainfuck)

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There comes to all races an ultimate crisis which you have yet to face
 One day our minds became so powerful we dared think of ourselves as
gods.
-- Sargon, "Return to Tomorrow", stardate 4768.3

Fwd: [DNG] Linux system can be brought down by sending SIGILL to Systemd

[Fred]

Hello,
I subscribe to the Devuan Linux mailing list.  This posting just arrived 
and it appears quite important to Debian.


 Forwarded Message 
Subject: 	[DNG] Linux system can be brought down by sending SIGILL to 
Systemd

Date:   Fri, 24 May 2019 22:04:34 +0200
From:   Martin Steigerwald 
To: DNG 



Hi!

Today in a Linux training a participant attempted to bring down Debian
workstation with Systemd by sending signals to PID 1 as I invited them
to try to bring down PID 1 while thinking for myself that this would not
be possible from my past experiences about trying to bring down PID 1 –
init – myself.

While sending SIGKILL to Systemd did not have any effect, sending SIGILL
– illegal instruction – to it brought the machine to an halt. I
reproduced it with

while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done

on my training workstation (Debian 9.9 with Systemd 232 and 4.9.0-9
Debian Kernel with MDS mitigation).

The mouse pointer froze and the machine did not even respond to ping
anymore! According to participants about 4 to 5 times sending the signal
would be enough to bring down a workstation with Systemd as PID 1.

Despite all the bugs and issues I have seen or read about with Systemd I
was very surprised about that result.

Curiously I attempted the same with the Debian on my laptop that I
switched to SysVInit and elogind. As the elogind stuff mostly works I
think I will switch it to Devuan once I come around to it.

I am able to run

while true; do kill -ILL 1 ; echo -n "." ; done

against SysVinit's "init" process without any issue for minutes (Debian
Sid with sysvinit 2.93-8 and self-compiled 5.1.2 kernel, also with MDS
mitigation). It is even running while I write this mail normally now.

Also the participants found in the manpage kill(2):

NOTES
   The  only  signals  that  can be sent to process ID 1, the init
   process, are those for which init has explicitly installed sig‐
   nal handlers.  This is done to assure the system is not brought
   down accidentally.

So if that is actually true, then it appears that Systemd initiates a
signal handler for SIGILL for whatever reason.

I pondered about writing a bug report to Systemd developers, but
honestly from my past experiences with upstream feedback about bug
reports regarding Systemd I then decided not to bother about it. I am
not willing to take in and deal with any more "this is by design, go
away" or "this works as intended, go away" kind of responses. I am not
interested in Systemd to a larger extent than teaching participants of
my training what they need to know about it, when they have to deal with
it due to distribution choices made at their employer. And yes, I also
have a slide that summarizes critique about it, complete with links, so
they can make up their own opinion. And no, for me it is not black and
white, but my own decision is to go without Systemd.

This is another reason for me to start to provide Devuan VMs in the
Proxmox VE environment I use to provide VMs of various distributions to
the participants of my trainings. So participants can have a look at it
and do exercises with it if they like. I already started to incorporate
information about Devuan in some of my slides.

I share it here not to invite another bashing about Systemd, we really
do not need to go there, but instead can focus on strengthening the
alternatives. But I share it here to provide another reason to use a
Systemd-free distribution like Devuan. I also share it as an example of
the robustness of the SysVInit init process!

Thanks,
--
Martin


___
Dng mailing list
d...@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: Debian Programming languages

[Christian Groessler]

On 5/24/19 10:03 PM, Alex Mestiashvili wrote:

On 5/24/19 7:28 PM, Christian Groessler wrote:

On 5/24/19 6:51 PM, john doe wrote:

On 5/24/2019 6:14 PM, ghe wrote:

Perl is happily off on it's own. "There's more than one way..." Boy is
there ever. Nice to write, but it's next to impossible to understand
other people's code. Python, IMHO, seems to be creeping up to replace
it.


I'm typically referring to perl as a "write-only" language. :-)

But don't get me wrong, I like it...

regards,
chris


That is not true. The freedom to write unreadable code doesn't mean that
the language is bad.



I guess you didn't notice the smiley in my message...

I'm sometimes having hmm.. let's say "problems" ... understanding what I 
had written ~10yrs ago. Typically regexp-related. That's not a problem 
of the language, but a problem in my understanding as I don't use perl 
on a day-to-day basis.


I stated "I like it", and that's true. I dislike python on the other hand...

regards,
chris

Re: Debian Programming languages

[Thomas Schmitt]

Hi,

Joe wrote:
> geda-gschem and related electronics tools rely on Guile. I have Guile
> libraries 1.8, 2.0 and 2.2 installed, and they increase in size from
> 2.6MB to 11.8MB to 45MB. So something must still be going on...

It is still the official glue language of GNU. (To my luck its use does
not get enforced in any way.)
There is Guix, a distro and/or package manager which makes heavy use of
Guile.

But as said, the Debian source line counter probably adds it to the Lisp
basket.


Have a nice day :)

Thomas

Re: Debian Programming languages

[Alex Mestiashvili]

On 5/24/19 7:28 PM, Christian Groessler wrote:
> On 5/24/19 6:51 PM, john doe wrote:
>> On 5/24/2019 6:14 PM, ghe wrote:
>>> Perl is happily off on it's own. "There's more than one way..." Boy is
>>> there ever. Nice to write, but it's next to impossible to understand
>>> other people's code. Python, IMHO, seems to be creeping up to replace
>>> it.
> 
> 
> I'm typically referring to perl as a "write-only" language. :-)
> 
> But don't get me wrong, I like it...
> 
> regards,
> chris
> 

That is not true. The freedom to write unreadable code doesn't mean that
the language is bad.

Just as an example, look on Perl Dancer[0] framework. It's so damn easy
and clear, one can start using it just after going through the tutorial.

Best,
Alex

[0] https://metacpan.org/pod/Dancer2::Tutorial

Re: Debian Programming languages

[Joe]

On Fri, 24 May 2019 16:08:44 +0100
Paul Sutton  wrote:


> 
> Not just on the coding side of things as we have markdown / html / css
> perhaps LaTeX for documentation.
> 

I've done practically all my coding for the last ten years in php. With
a disparate collection of computing devices, web applications make
sense for me. But I'm a hobbyist, not a professional, and have never
done any system programming.

-- 
Joe

Re: Debian Programming languages

[Joe]

On Fri, 24 May 2019 20:28:04 +0200
"Thomas Schmitt"  wrote:

> Hi,
> 
> Glenn English wrote:
> > LISP was the first high level language I
> > learned. Thought I was going to die...  
> 
> Yeah. Why ain't there no Debian package with Guile ?
>   https://www.gnu.org/software/guile/
> 
>
geda-gschem and related electronics tools rely on Guile. I have Guile
libraries 1.8, 2.0 and 2.2 installed, and they increase in size from
2.6MB to 11.8MB to 45MB. So something must still be going on...

-- 
Joe

Re: kvm errors with 4.9.0-9 kernel.

[Reco]

Hi.

On Sat, May 18, 2019 at 09:22:19PM -0600, John J. Rushford wrote:
> Greetings,
> 
> I recently updated my debian 9.9 machine which installed the 4.9.0-9
> kernel.  With this kernel,  the kvm_intel modules fail to load due to
> the following
> errors:
> 
> kernel: [    6.234764] kvm_intel: Unknown symbol cpu_tlbstate (err -22)
> kernel: [    6.235463] kvm_intel: Unknown symbol mds_user_clear (err 0)
> kernel: [    6.330732] kvm_intel: disagrees about version of symbol 
> cpu_tlbstate

A mismatch between a kernel version and kvm_intel module version is the
most likely reason for this. Should not happen at all, and does not
happen for me, for instance.
Can you please post the output of:

uname -v
/sbin/modinfo kvm_intel
dpkg -l linux-image*

Reco

Re: kvm errors with 4.9.0-9 kernel.

[Étienne Mollier]

Good Day John,

I tried to reproduce the problem on my side, using KVM
accelerated with the module kvm_intel from Debian native kernel
4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13).

I encountered the following trace in my `dmesg` output, which is
only remotely related to kvm_intel:

[   89.389480] kvm: zapping shadow pages for mmio generation wraparound
[  120.924745] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x1c9
[  120.928959] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x1a6
[  120.933429] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x1a7
[  120.938123] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x3f6
[  120.942968] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x3f7
[  120.971155] kvm: zapping shadow pages for mmio generation wraparound
[  121.498463] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x64e
[  121.503585] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x34
[  125.592208] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x606
[  126.334166] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x611
[  126.339807] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x639
[  126.345627] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x641
[  126.351708] kvm [1716]: vcpu0, guest rIP: 0xaea5a602 
unhandled rdmsr: 0x619

While you were seeing:
> > >   [6.234764] kvm_intel: Unknown symbol cpu_tlbstate (err -22)
> > >   [6.235463] kvm_intel: Unknown symbol mds_user_clear (err 0)
> > >   [6.330732] kvm_intel: disagrees about version of symbol cpu_tlbstate

On my side, my messages did not prove to be fatal.  I have been
able to start virtual machines.

Using upstream kernel 4.19.45 on another machine did not show
any issues at all.  I don't know if that could be eligible to
additional material or not to the bug report (well if you
issued one :).  I thought it might have been worth mentioning
anyway.

Perhaps the CPU model has it's importance, I used an Intel Xeon
W-2104 for my test with the native Debian kernel, and an Intel
i7 of 7th generation for my test with upstream kernel.

Kind Regards,
-- 
Étienne Mollier 

Re: What to buy for Buster?

[David Christensen]

On 5/24/19 1:15 AM, Erik Josefsson wrote:

On 5/24/19 5:12 AM, David Christensen wrote:


If you get a major brand computer with 64-bit Intel Core technology 
(ca. 2006) or newer, Debian should run on it.


Great! Thanks!

The HP Compaq 8200 Elite SFF that I'm about to grab has a Intel Core 
i5-2400S processor.


The Intel i5-2400S processor supports both 32-bit and 64-bit software:

https://en.wikipedia.org/wiki/Intel_x86

https://ark.intel.com/content/www/us/en/ark/products/52208/intel-core-i5-2400s-processor-6m-cache-up-to-3-30-ghz.html

Advanced Technologies

Intel® 64 ‡ Yes


I browsed the Debian installer pages and as far as I understand I should 
use "other images (netboot, USB stick, etc.)" for the installation, but 
to me it is not obvious if I should use the image for the amd64 or the 
i386 architecture:


https://www.debian.org/devel/debian-installer/

My typcal problem. I should know basic stuff like that.

Is the "Debian Designation" for the Intel Core i5-2400S processor "Intel 
x86-based" or "AMD 64 & Intel 64"?


(I am looking at the table "2.1.1. Supported Architectures" in the 
Debian GNU/Linux Installation Guide on the pages of d-i.debian.org/manual/)


Best regards.

//Erik


Either Debian "i386" (32-bit) or Debian "amd64" (64-bit) will work on 
the above computer.



I usually run Debian i386 on processors that are 32-bit only (e.g. 
socket 478 Pentium 4 and earlier) and Debian amd64 on processors that 
support 64-bit.  I would suggest that you use amd64:


https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.9.0-amd64-xfce-CD-1.iso


David

Re: Debian Programming languages

[Thomas Schmitt]

Hi,

Glenn English wrote:
> LISP was the first high level language I
> learned. Thought I was going to die...

Yeah. Why ain't there no Debian package with Guile ?
  https://www.gnu.org/software/guile/

  https://codesearch.debian.net/search?q=guile
yields (after choosing a package)

  
https://sources.debian.org/src/supertux/0.6.0-1/tools/levelconverter-0.1.3_0.2.0.scm/?hl=1#L1
  #!/usr/bin/guile -s

Probably Guile and Scheme are counted as Lisp.


Have a nice day :)

Thomas

Re: Debian Programming languages

[James H. H. Lampert]

On 5/24/19, 11:00 AM, ghe wrote:

I forgot about LISP too. LISP was the first high level language I
learned. Thought I was going to die...


(CLUTTER CLUTTER (CDR CLUTTER)) is probably the only s-expression I 
still remember from over half a lifetime ago. (It's a line of code from 
the "Blocks World" exercise in my old (LISP) textbook).


--
JHHL

Re: Debian Programming languages

[Christian Groessler]

On 5/24/19 6:51 PM, john doe wrote:

On 5/24/2019 6:14 PM, ghe wrote:

Perl is happily off on it's own. "There's more than one way..." Boy is
there ever. Nice to write, but it's next to impossible to understand
other people's code. Python, IMHO, seems to be creeping up to replace it.



I'm typically referring to perl as a "write-only" language. :-)

But don't get me wrong, I like it...

regards,
chris

Re: Debian Programming languages

[ghe]

On 5/24/19 11:45 AM, Thomas Schmitt wrote:

> 1,122 lines of code in Buster.

Oh. So that's what's wrong with Buster :-)

> (Astounding how few languages are mentioned there.
>  No Piet ? http://www.dangermouse.net/esoteric/piet/samples.html

I forgot about LISP too. LISP was the first high level language I
learned. Thought I was going to die...

-- 
Glenn English

Re: Debian Programming languages

[Tom Browder]

On Fri, May 24, 2019 at 12:43 Jonas Smedegaard  wrote:
...

> That's plain wrong: Debian has perl at its core, and Python not.
>
> Also, your simplification of Perl is common among folks ignorant about
> Perl but is wrong as well: You _can_ write difficult-to-read code in
> Perl by by no means do you need to, and most Perl code in Debian - i.e.
> the thousands of CPAN modules, does not use a difficult-to-read coding
> style.


To add support to Jonas' reply:

Perl 6 development is definitely NOT stalled. We have four GSoC students
working on serious projects for the Perl 6 community. We welcome all to
visit  and join the fun! (We did have some server
problems recently which may have led you to think development has stalled.)

Warmest regards,

-Tom

#perl6, #perl6-dev alias: tbrowder
github: tbrowder

Re: Debian Programming languages

[James H. H. Lampert]

Just out of morbid curiosity: what about a full ANSI PL/I?

--
JHHL
(And the mere fact that I'm asking ages me.)

Re: Debian Programming languages

[ghe]

On 5/24/19 11:21 AM, mick crane wrote:


>> On 5/24/19 9:08 AM, Paul Sutton wrote:

> What goes on with Perl ?

Can you say "Python"?

Perl was great a while back, but it leaves something to be desired today.

-- 
Glenn English

Re: Debian Programming languages

[ghe]

On 5/24/19 11:42 AM, Jonas Smedegaard wrote:

> That's plain wrong: Debian has perl at its core, and Python not.

Please note the word "creeping." Perl is used a lot -- it's a very
powerful language, but its syntax and data structures are less than optimal.

I've written a lot of Perl, but I've become a Python convert. Python has
its warts too, but it sure is easier to live with than Perl is.

-- 
Glenn English

Re: Debian Programming languages

[Jonas Smedegaard]

Quoting mick crane (2019-05-24 19:21:33)
> On 2019-05-24 17:14, ghe wrote:
> > On 5/24/19 9:08 AM, Paul Sutton wrote:
> > 
> >> As I am trying to promote contributing to Debian,  what programming
> >> languages are mostly used?
> > 
> > C, perl, java, ruby, python, bash, that I know of. And probably several
> > others. I don't recall seeing any COBOL, though :-)
> 
> > Perl is happily off on it's own.
> 
> What goes on with Perl ?
> There is Perl6 but development is stalled ?

Perl is alive and well.

Perl6 (a different thing derived from perl) is progressing, not stalled.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian Programming languages

[Thomas Schmitt]

Hi,

ghe wrote:
> I don't recall seeing any COBOL, though :-)

1,122 lines of code in Buster.
See
  https://sources.debian.org/stats/#sloc_current


(Astounding how few languages are mentioned there.
 No Piet ? http://www.dangermouse.net/esoteric/piet/samples.html
)


Have a nice day :)

Thomas

Re: Debian Programming languages

[Jonas Smedegaard]

Quoting ghe (2019-05-24 18:14:42)
> On 5/24/19 9:08 AM, Paul Sutton wrote:
> 
> > As I am trying to promote contributing to Debian,  what programming
> > languages are mostly used?  
> 
> C, perl, java, ruby, python, bash, that I know of. And probably several
> others. I don't recall seeing any COBOL, though :-)
> 
> > I am asking as it helps to give people an
> > idea of what they need to learn or will learn as part of helping.
> 
> The *nix kernels, and most of the command programs, are written in C, so
> C's a must. Java and python look like a kinda fixed up, OOP C, so
> they're not too hard to deal with once you know C.
> 
> I don't know what ruby is like, but I see a lot of it in the mirrors and
> stuff.
> 
> Perl is happily off on it's own. "There's more than one way..." Boy is
> there ever. Nice to write, but it's next to impossible to understand
> other people's code. Python, IMHO, seems to be creeping up to replace it.

That's plain wrong: Debian has perl at its core, and Python not.

Also, your simplification of Perl is common among folks ignorant about 
Perl but is wrong as well: You _can_ write difficult-to-read code in 
Perl by by no means do you need to, and most Perl code in Debian - i.e. 
the thousands of CPAN modules, does not use a difficult-to-read coding 
style.

You don't need to learn _any_ specific language in order to help out 
with Debian: https://www.debian.org/intro/help


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian Programming languages

[Paul Sutton]

On 24/05/2019 17:51, john doe wrote:
> On 5/24/2019 6:14 PM, ghe wrote:
>> On 5/24/19 9:08 AM, Paul Sutton wrote:
>>
>>> As I am trying to promote contributing to Debian,  what programming
>>> languages are mostly used?
>> C, perl, java, ruby, python, bash, that I know of. And probably several
>> others. I don't recall seeing any COBOL, though :-)
>>
>>> I am asking as it helps to give people an
>>> idea of what they need to learn or will learn as part of helping.
>> The *nix kernels, and most of the command programs, are written in C, so
>> C's a must. Java and python look like a kinda fixed up, OOP C, so
>> they're not too hard to deal with once you know C.
>>
>> I don't know what ruby is like, but I see a lot of it in the mirrors and
>> stuff.
>>
>> Perl is happily off on it's own. "There's more than one way..." Boy is
>> there ever. Nice to write, but it's next to impossible to understand
>> other people's code. Python, IMHO, seems to be creeping up to replace it.
>>
>> Bash reminds one of the syntax of the 1950s. The pits, but necessary.
>> And it's often the best way to make something happen right now.
>>
> '/bin/sh' on Debian is Dash.
>
> So I would say, general shell scripting ability and POSIX compliance
> (Dash/Posh).
>
> Avoiding Bashism if Bash is to be used.
>
> --
> John Doe
>

Thank you for this, very helpful and useful information, I (well others
too) hopefully have something to go on when trying to tell people about
contributing to Debian. 

Granted not everyone (including me) is at developer level or may want to
get that far.

Question now is how to turn all this in to something that will hopefully
attract people to help with Debian or other free software projects that
are related.

Thanks again


Paul


Paul


-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

Re: Debian Programming languages

[mick crane]

On 2019-05-24 17:14, ghe wrote:

On 5/24/19 9:08 AM, Paul Sutton wrote:


As I am trying to promote contributing to Debian,  what programming
languages are mostly used?


C, perl, java, ruby, python, bash, that I know of. And probably several
others. I don't recall seeing any COBOL, though :-)



Perl is happily off on it's own.


What goes on with Perl ?
There is Perl6 but development is stalled ?

mick


--
Key ID4BFEBB31

Re: Debian Programming languages

[john doe]

On 5/24/2019 6:14 PM, ghe wrote:
> On 5/24/19 9:08 AM, Paul Sutton wrote:
>
>> As I am trying to promote contributing to Debian,  what programming
>> languages are mostly used?
>
> C, perl, java, ruby, python, bash, that I know of. And probably several
> others. I don't recall seeing any COBOL, though :-)
>
>> I am asking as it helps to give people an
>> idea of what they need to learn or will learn as part of helping.
>
> The *nix kernels, and most of the command programs, are written in C, so
> C's a must. Java and python look like a kinda fixed up, OOP C, so
> they're not too hard to deal with once you know C.
>
> I don't know what ruby is like, but I see a lot of it in the mirrors and
> stuff.
>
> Perl is happily off on it's own. "There's more than one way..." Boy is
> there ever. Nice to write, but it's next to impossible to understand
> other people's code. Python, IMHO, seems to be creeping up to replace it.
>
> Bash reminds one of the syntax of the 1950s. The pits, but necessary.
> And it's often the best way to make something happen right now.
>

'/bin/sh' on Debian is Dash.

So I would say, general shell scripting ability and POSIX compliance
(Dash/Posh).

Avoiding Bashism if Bash is to be used.

--
John Doe

Re: Backports and upgrade to buster

[Cindy Sue Causey]

And hi! :)

On 5/23/19, Michael Lange  wrote:
> Hi,
>
> On Thu, 23 May 2019 11:44:14 +0300
> Georgios  wrote:
>
>> Hi there!
>> I'm thinking installing debian on a new laptop. The problem is that the
>> current version is stretch that comes with an old kernel that doesn't
>> support my wifi card.
>> I was thinking about using backports to install the latest kernel.
>>
>> I have the following questions.
>>
>> When I install stable and use a kernel from backport when you install it
>> you upgrade a couple of packages like libglib, firmware-linux-free etc
>>
>> When the buster is released what happens when i try to upgrade the
>> system from stretch to buster?
>> Do I have to remove backports from sources.list?
>> What happens to the packages that were upgraded from backports? Are they
>> replaced by the new stable packages?
>
> before starting an upgrade from stretch to buster (or any oldstable to
> stable) you should remove backports from the sources.list at any rate. In
> my own personal experience the best bet is to remove anything except the
> line
>
> deb http://ftp.de.debian.org/debian/ stretch main contrib non-free
>
> from the sources.list prior to the upgrade. Usually this gives you a
> smooth upgrade procedure. Packages from backports (or multimedia or
> whatever one may use in addition to plain debian) will be replaced by the
> new stable packages if these are newer. If you need (or just want)
> anything from backports (or multimedia or whatever) just re-install these
> packages after the upgrade.


Because of the speed of dialup, I go the extra step of backing up
/var/lib/apt/lists, too, just in case that directory's contents
somehow get zapped in the process. Afterward, I run a quick "diff"
comparison to see if anything notable needs put back in place.

Most times nothing needs changed after previously favored
/etc/apt/sources.list lines are put back in place. If something does
need replaced, it's most likely due to a mistake on my part.

Backing up that lists directory is just a precautionary step I have to
take relative to my usage circumstances. It only takes 2 seconds to
both create and then later delete. In return, the step can save (and
HAS SAVED) many HOURS of wear and tear on my computer, my Internet
service provider's servers, AND MOST IMPORTANTLY (*to me*), whatever
VOLUNTEER Debian repository host(s) might be affected each time.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Debian Programming languages

[ghe]

On 5/24/19 9:08 AM, Paul Sutton wrote:

> As I am trying to promote contributing to Debian,  what programming
> languages are mostly used?  

C, perl, java, ruby, python, bash, that I know of. And probably several
others. I don't recall seeing any COBOL, though :-)

> I am asking as it helps to give people an
> idea of what they need to learn or will learn as part of helping.

The *nix kernels, and most of the command programs, are written in C, so
C's a must. Java and python look like a kinda fixed up, OOP C, so
they're not too hard to deal with once you know C.

I don't know what ruby is like, but I see a lot of it in the mirrors and
stuff.

Perl is happily off on it's own. "There's more than one way..." Boy is
there ever. Nice to write, but it's next to impossible to understand
other people's code. Python, IMHO, seems to be creeping up to replace it.

Bash reminds one of the syntax of the 1950s. The pits, but necessary.
And it's often the best way to make something happen right now.

Python rules, this week (it's written in C too).

They all do things differently. Knowing several of them (and investing
in a pile of O'Reilly books) is a big help.

-- 
Glenn English

I help about Development.

[Ale Frataslafra]

Hi I'm Alexandria F., I'm working in a DebianCustomCD( 
https://wiki.debian.org/DebianCustomCD ), I'm a software developer, i have all 
versions of your distributions of debian jessie and 
stretch(gnome,kde,xfce,cinnamon,lxde) downloaded, but im start in contact with 
you because i have some questions about debian live cd, for be specific(Jessie 
8.0.0), my questions are:

1. It's posibly to boot a debian live cd from a raw disk (.img) with ext2 or 
ext3 or ext4 format with grub2, not in a iso9660 file?

example:
MySomeRawDisk(ex4format).img
 /boot
 /isolinux
 /live
 /filesystem.squashfs
 /vmlinuz
 / initrd.img
...

grub2 menuentry example:
menuentry "RawDiskBoot" {
set imgname="MySomeRawDisk(ex4format).img"
set imgpath="/"
set image="${imgpath}/${imgname}"
loopback loop $image
linux (loop)/live/vmlinuz boot=live root=/dev/loop0 boot=live
initrd (loop)/live/initrd
}

2. How i can do run correctly my debian custom livecd boot from a raw disk 
MySomeRawDisk(ex4format).img, modifying the initrd.img, if is not possible boot 
a .img only with grub2.

I'm trying to boot using these few commands:
mount -t ext4 -o rw,data=ordered /dev/sda10 /MyMountPoint
mount -t ext4 -o loop,data=ordered "/MyMountPoint/MySomeRawDisk(ex4format).img" 
${rootmnt}

And these command are inside my initrd.img/scripts/init-premount/CustomScript, 
but unfortunately this not works, when the boot starts of this CustomScript, 
the initramfs-tools could not detect the /dev/sda10 partition, and log return 
with this message:

mount -t ext4 -o loop,data=ordered "/MyMountPoint/MySomeRawDisk(ex4format).img" 
${rootmnt}, No such file or directory

In other words, could not detect the /dev/sda10 for mount, and it happens too 
when i try to mount a loop device like (/dev/loop0)

Here a stackoverflow reference of what im trying to do, 
https://superuser.com/questions/412028/booting-an-ext4-image-file-from-grub2

Note: please not confuse this with, How to boot a livecd.iso file inside a ext4 
raw disk .img.

Thanks, i wait your answer...

Re: Debian Programming languages

[Jonas Smedegaard]

Quoting Paul Sutton (2019-05-24 17:08:44)
> As I am trying to promote contributing to Debian, what programming 
> languages are mostly used?  I am asking as it helps to give people an 
> idea of what they need to learn or will learn as part of helping.
> 
> I am guessing as the default command line interface is bash, then bash 
> and bash scripting would be useful to learn but on top of that what 
> would people suggest I try and promote.
> 
> Not just on the coding side of things as we have markdown / html / css 
> perhaps LaTeX for documentation.

Debian excells in not being a monoculture.  Therefore I think it is 
doing Debian a disservice to try emphasize which has "majority" use.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Debian Programming languages

[Paul Sutton]

Hi

As I am trying to promote contributing to Debian,  what programming
languages are mostly used?  I am asking as it helps to give people an
idea of what they need to learn or will learn as part of helping.

I am guessing as the default command line interface is bash, then bash
and bash scripting would be useful to learn but on top of that what
would people suggest I try and promote.

Not just on the coding side of things as we have markdown / html / css
perhaps LaTeX for documentation.


Thanks

Paul

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

Re: Verifying Debian 9.9 with SHA and SHA.signatures

[Thomas Schmitt]

Hi,

> I've never found any terminal commands to use the checksums, or the
> signing key.

Have a look at
  https://lists.debian.org/debian-user/2019/04/msg00214.html
  https://lists.debian.org/debian-user/2019/04/msg01149.html

The first one gives an overview. You already seem to know most of this.
It also shows examples of verification commands.

The second one is about john doe's proposal, which for now is the
best candidate for a SHA512 checksum verification command:

  sha512sum -c --ignore-missing SHA512SUMS

and about my proposal to verify the GPG signature directly on the remote
keyring:

  gpg --keyserver keyring.debian.org --verify SHA512SUMS.sign SHA512SUMS


> Please could Debian create some extra documentation on using commands to
> verify Debian's isos' with SHAs and signatures?

The need is known.
In
  https://lists.debian.org/debian-user/2019/04/msg01147.html
we see the announcement of improvement by the web team.


Have a nice day :)

Thomas

Verifying Debian 9.9 with SHA and SHA.signatures

[Stefan.schultz19.5.1991]

Hello Debian support,

I'm quite new to open source, so learning lots, especially verifying os 
downloads. I can use the SHAs and SHAs.sign in various distros, but I hit a 
wall in Debian. I've read a lot on various Debian web pages like 'Verifying 
authenticity of Debian CDs', and scoured the 120 page Debian Jessie manual.

https://www.debian.org/CD/verify

I understand I have to use the SHAs to check the iso image. and the .sign to 
check the checksums.

I've imported one gpg key from

gpg --keyserver keyring.debian.org --recv-keys 0x673A03E4C1DB921F

But I've never found any terminal commands to use the checksums, or the signing 
key.
I've only managed to check the checksums in the Debian 9.9 iso, by doing it my 
Tails usb, by clicking on the properties of the iso, and then click on the 
'Digests' feature. The SHA256SUMS and SHA512SUMS, are the same as the 
downloaded checksums.

Unless my sonar for commands is malfunctioning, I cannot find any! If my sonar 
is defunct, please tell me!

In comparison, this is how Ubuntu and Mint describe checking isos. Two 
different presentations, but a novice like me can have piece of mind, that the 
downloads are correct. I will not be complacent, by assuming that they are 
perfect. A few times they have not been.

Two years ago Ubuntu was very confusing, but now it's educational too. Follow 
the arrows to the right

https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#1

Mint explains everything on one page

https://linuxmint.com/verify.php

Question 1

Please could Debian create some extra documentation on using commands to verify 
Debian's isos' with SHAs and signatures?

Question 2

Is that a big ask for all the distros that Debian has available?

Being a Tails addict, I want to start using Debian.

Thank you in advance for any advice you have. I look forward to your replies.

Stefan

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

Re: /var trop gros

[David - DCPC]

Si c'est du lvm pourquoi ne pas plus logiquement retailler les partitions
en réduisant le home et augmentant le var ?

Sinon voir si c'est logique et utile ce qui remplit le /var, et par exemple
ajuster les logrotate si c'est bien /var/log qui grossit (genre ajouter la
compression des anciens logs, en garder moins longtemps,...)

David

Le mer. 22 mai 2019 à 09:43, Sébastien NOBILI  a
écrit :

> Bonjour,
>
> 20 mai 2019 15:21 "Daniel Caillibaud"  a écrit:
>
> > Tu as réglé le pb en montant ton ancienne partition /home avec le contenu
> > de /var sur /var, mais pour une autre fois ou pour qqun d'autre qui
> > tomberait sur ce fil, il me semble que mysql|mariadb n'aime pas les liens
> > symboliques (ou alors c'est apparmor, me rappelle plus), il suffit de lui
> > indiquer le vrai dossier source (dans ton cas c'était /home/lib/mysql/ à
> la
> > place de /var/lib/mysql) dans la configuration mariadb (variable
> datadir, +
> > éventuellement vérifier dans /etc/apparmor.d/ que c'est cohérent).
>
> Pour ce genre de cas, j'utilise un montage "bind" :
>
> mount /home/var/ /var/ -o bind
>
> Du côté de l'application, l'illusion est parfaite et pas besoin de modifier
> la conf.
>
> Sébastien
>
>

-- 
Salutations,
David CHALON

Re: What to buy for Buster?

[Dan Ritter]

Erik Josefsson wrote: 
> On 5/24/19 5:12 AM, David Christensen wrote:
> > 
> > If you get a major brand computer with 64-bit Intel Core technology (ca.
> > 2006) or newer, Debian should run on it.
> 
> Great! Thanks!
> 
> The HP Compaq 8200 Elite SFF that I'm about to grab has a Intel Core
> i5-2400S processor.

I have the next generation model of that sitting on my desk at
work. It's perfectly reasonable.

> I browsed the Debian installer pages and as far as I understand I should use
> "other images (netboot, USB stick, etc.)" for the installation, but to me it
> is not obvious if I should use the image for the amd64 or the i386
> architecture:

AMD64 is the name for the modern Intel-and-AMD 64-bit
instruction set; basically all non-antique desktops and 
laptops use it.

(History: Intel decided that 64-bit instruction sets should be
a new architecture, and built a system called Itanium. It was
expensive and slow. Meanwhile, AMD built a reasonable extension
to the existing Intel 32-bit architecture, and Intel eventually
adopted it.

For a while, the Itanium architecture was available as IA64,
which served mostly to confuse people who had bought Intel chips
and wanted 64-bitness.

> My typcal problem. I should know basic stuff like that.

No, you should know how to ask questions and do research. Then you get
to know stuff. That's how I got to know stuff, anyway.

-dsr-

Re: Debian 10 user accounts

[Francisco M Neto]

On Thu, 2019-05-23 at 20:07 +0100, Brian wrote:
> On Thu 23 May 2019 at 18:47:48 +0100, Paul Sutton wrote:
> Is this how it is meant to do things, or have I missed a step
> > somewhere ?
> 
> Being obliged to use sudo? No.

I feel I should point out, though, that there are a number of
advantages to this approach. Using sudo instead of logging in as root
(or rather using su to get access to a root prompt) is a safer approach
since it adds a layer of insurance against "accidents", not to mention
every command is logged (which is good in any case, but mandatory in
case of multi-user systems), avoids using the root shell and is overall
safer agains hacking/cracking.

Interesting reads:

https://unix.stackexchange.com/questions/291454/difference-between-sudo-user-and-root-user

http://www.linuxscrew.com/2007/10/11/why-use-sudo-instead-of-su/

Cheers!
-- 
[]'s,

Francisco M Neto 

GPG: 4096R/D692FBF0


signature.asc
Description: This is a digitally signed message part

Re: What to buy for Buster?

[Greg Wooledge]

On Fri, May 24, 2019 at 08:15:12AM +, Erik Josefsson wrote:
> The HP Compaq 8200 Elite SFF that I'm about to grab has a Intel Core
> i5-2400S processor.
> 
> I browsed the Debian installer pages and as far as I understand I should use
> "other images (netboot, USB stick, etc.)" for the installation, but to me it
> is not obvious if I should use the image for the amd64 or the i386
> architecture:

You want amd64.  That's the 64-bit version, also promoted as "x86_64" by
Intel's marketing forces trying to detract from the fact that AMD beat
them to the punch.

Re: Need help about development of your distributions.

[Jonathan Dowland]

On Fri, May 24, 2019 at 03:02:52AM +, Ale Frataslafra wrote:

Hello, I'm Alexandria F., I'm a software developer, i have all versions
of your distributions of debian jessie and
stretch(gnome,kde,xfce,cinnamon,lxde) downloaded, but im start in
contact with you because i have some questions about debian live cd,
for be specific(Jessie 8.0.0), my questions are:

1. It's posibly to boot a debian live cd from a raw disk (.img) with
ext2 or ext3 or ext4 format with grub2, not in a iso9660 file?

snip

Maybe you want to know why i need it?, this is the answer: Im working
in a custom livecd of debian, and i need save more time in the
debugging of the livecd, requires minus time and minus resources, the
replacement of the filesystem.squashfs inside a .img ext4 than replace
a iso9660 .iso file, and even sometimes the modifying of the .iso file
can damage the filesystem.


It might be worth talking to one of the Debian Live developers to see
whether they have a useful workflow to recommend. One such developer is
Jonathan Carter , but you may also consider
contacting the  mailing list.


--
  Jonathan Dowland
✎	 j...@debian.org 
	https://jmtd.net

Re: What to buy for Buster?

[Erik Josefsson]

On 5/24/19 5:12 AM, David Christensen wrote:


If you get a major brand computer with 64-bit Intel Core technology 
(ca. 2006) or newer, Debian should run on it.


Great! Thanks!

The HP Compaq 8200 Elite SFF that I'm about to grab has a Intel Core 
i5-2400S processor.


I browsed the Debian installer pages and as far as I understand I should 
use "other images (netboot, USB stick, etc.)" for the installation, but 
to me it is not obvious if I should use the image for the amd64 or the 
i386 architecture:


https://www.debian.org/devel/debian-installer/

My typcal problem. I should know basic stuff like that.

Is the "Debian Designation" for the Intel Core i5-2400S processor "Intel 
x86-based" or "AMD 64 & Intel 64"?


(I am looking at the table "2.1.1. Supported Architectures" in the 
Debian GNU/Linux Installation Guide on the pages of d-i.debian.org/manual/)


Best regards.

//Erik