How to avoid stealth installation of systemd?

Here you can discuss every aspect of Debian. Note: not for support requests!
Post Reply
Message
Author
timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#81 Post by timbgo »

edbarx wrote:
timbgo wrote:Command Line Interface. But I don't get it how it applies here?
If a fraction of those functions can be delegated to CLI programs, it should be possible to use those programs as backends. This is done in many situations, where a graphical frontend like synaptic, uses CLI backends.

Added Later:
Since in C/C++ main() is a function, I am suspecting, using a CLI backend is a matter of importing that function, essentially, making the backend program behave like a library. What I know for sure is that the OS calls main() to run a program.
Unabridged post above. edbarx, I'm more of a regular user in these terms. If you manage to, but with very probable prospects, put that to use so we can liberate our boxes, great.
But I don't even see, for lack of my understanding of these codes and aspects, clearly here, and have spent too much time already. Fatigue entering.
No, I think we desperately need help from debian-devel.
I work too slowly. Why can't anyone just send that notice to those developers?
(see previous posts if someone is reading this in parachuted fashion; search for, say Wookey, and search for mirabilos)
Miro
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#82 Post by timbgo »

While I have updated my private Gentoo mirror and my Gentoo boxes, I haven't prepared the issue for mailing to the developers yet (just pleaded if someone could help in that regard again, in the previous post), and in fact most of my work since I left here yesterday was with the issue of living systemd-free in Debian.

I decided I knew too little to be able to rid myself of the dbus dependency the way that edbarx suggested
( http://www.brain-dump.org/blog/entry/40 ... _in_Debian )

and went for the old general compilation way (configure, make, make install of the upstream sources).

I have discovered only that ffmpeg can be installed without any dbus/systemd/pulseaudio/oetteringware-generally, and that tells something doesn't it?

But tried quite a few times unsuccessfully to install mplayer.

With mplayer goes also mencoder. And I use my old command line to capture DVB from an old TV card on whichever of the Debian boxes that I install the TV-card in (physically in the PCI-slot). If I were able to get that mencoder to do the work, that would be a major breakthrough.

Yes, getting mencoder to work on my no-dbus, no-systemd, no-policykit, no-pulseaudio, no-any-poetteringware, would be a major breakthrough, because it would without much doubt prove that potteringware is really just an overhead on top of real programs, that can perfectly, although not at all easily at the current state of affairs, be done away with.

I plan to explain in detail what I've done since I left yesterday.
EDIT 2014-10-22: I remembered this promise of mine often later on, but it kept looming as too much work, and not pressing work, so I left it behind. Anyway, that was all compiling the LinuxFromScratch way, if you know LFS, or simply the configure; make; make install way which you (I'm always having newbies in mind as well, not the competent only who conversed with me here)...
And is not appropriate for methods in Debian distro...
What I did proved my point, and many others' points all over the internet: that those dependencies are unnecessarily introduced and can be done without.
I am currently exploring, will be testing it these hours:
MirDebian “WTF” Repository
http://users.unixforge.de/~tglaser/debs/debidx.htm
which is soon to be on:
https://people.debian.org/~tg/
Pls. disregard other promises possibly in further posts down from here that I have to render void with this notice. Thanks!
Last edited by timbgo on 2014-10-22 00:22, edited 1 time in total.
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#83 Post by timbgo »

I untar'd the mplayer sources (it's upstream sources, so I don't think it mattered that I got them from m y local Gentoo mirror). and, as per the instructions in the README, I first tried:

Code: Select all

debian/daily-build.sh -b
And I got this result:

Code: Select all

root@mybox:/usr/local/src/mplayer-1.2_pre20130729# debian/daily-build.sh -b
dpkg-buildpackage: source package mplayer                        
dpkg-buildpackage: source version 2:1.0~svn
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by root <root@mybox>
dpkg-buildpackage: host architecture amd64
 dpkg-source -i -I.svn --before-build mplayer-1.2_pre20130729
dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input data in general section of control info file
dpkg-checkbuilddeps: Unmet build dependencies: ladspa-sdk libenca-dev libaa1-dev libasound2-dev libaudio-dev libcaca-dev libcdparanoia-dev | libcdparanoia0-dev libbluray-dev libdirectfb-dev libdts-dev libesd0-dev libfaad-dev libfribidi-dev libgif-dev libgtk2.0-dev libjack-dev libjpeg-dev liblircclient-dev liblivemedia-dev liblzo2-dev libmp3lame-dev libmpcdec-dev libopenal-dev libpulse-dev libschroedinger-dev libsdl1.2-dev | libsdl1.1-dev libsmbclient-dev libspeex-dev libsvga1-dev libswscale-dev libtheora-dev (>= 1.0~beta1) libvorbis-dev libvorbisidec-dev libx264-dev (>= 2:0.115~) libxinerama-dev libxv-dev libxvidcore-dev libxvmc-dev libxxf86dga-dev libvdpau-dev vstream-client-dev yasm
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
root@mybox:/usr/local/src/mplayer-1.2_pre20130729#
Ah, it's missing the dev packages. I figure that out only now, hours after the event. I said I was slow.

Can't try anything there now. I'm working on reporting my other attempts as well.

Next, I tried the following.

Code: Select all

./configure --prefix=/usr
It complained it needed yasm.

Code: Select all

apt-get install yasm
Installed.

I used redirection as below, to be able to report the state of affairs.

Code: Select all

./configure --prefix=/usr 2>&1 | tee /somewhere/mplayer_`date +%y%m%d_%H%M`_configure.txt
make 2>&1 | tee /somewhere/mplayer_`date +%y%m%d_%H%M`_make.txt
I won't be repeating those redirection to not clutter this report.

Then I ran:

Code: Select all

make
But mplayer could not compile, and the make ran very short.

Code: Select all

help/help_create.sh help/help_mp-en.h UTF-8
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o command.o command.c
In file included from libmpdemux/stheader.h:23:0,
                 from command.c:32:
libmpdemux/aviheader.h:25:30: fatal error: libavutil/common.h: No such file or directory
 #include "libavutil/common.h"
                              ^
compilation terminated.
Makefile:758: recipe for target 'command.o' failed
make: *** [command.o] Error 1
Another attmpet at mplayer. And my attempts here go from the start. Removing the antire untarred directory and going all over.

So this is the output of
configure --prefix=/usr:

Code: Select all

Checking for cc version ... 4.8 
Checking for working compiler ... yes
Detected operating system: Linux
Detected host architecture: x86_64
Checking for cross compilation ... no 
Checking for host cc ... cc 
Checking for CPU vendor ... AuthenticAMD (15:43:1) 
Checking for CPU type ...  AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 
Checking for kernel support of mmx ... yes 
Checking for kernel support of mmxext ... yes 
Checking for kernel support of 3dnow ... yes 
Checking for kernel support of 3dnowext ... yes 
Checking for kernel support of sse ... yes 
Checking for kernel support of sse2 ... yes 
Checking for kernel support of sse3 ... yes 
Checking for kernel support of cmov ... yes 
Checking for mtrr support ... yes 
Checking for GCC & CPU optimization abilities ... native 
Checking for byte order ... little-endian 
Checking for extern symbol prefix ...  
Checking for assembler support of -pipe option ... yes 
Checking for relocatable binary ... yes (fast PIC)
Checking for PIC ... yes 
Checking for .align is a power of two ... no 
Checking for ebx availability ... yes 
Checking for yasm ... yasm 
Checking for bswap ... yes 
Checking for xmm clobbers ... yes 
Checking for langinfo ... yes 
Checking for language ... messages: en - man pages: en - documentation: en 
Checking for enable sighandler ... yes 
Checking for runtime cpudetection ... no 
Checking for restrict keyword ... restrict 
Checking for __builtin_expect ... yes 
Checking for kstat ... no 
Checking for atanf ... yes 
Checking for cbrt ... yes 
Checking for cbrtf ... yes 
Checking for cosf ... yes 
Checking for expf ... yes 
Checking for exp2 ... yes 
Checking for exp2f ... yes 
Checking for isnan ... yes 
Checking for isinf ... yes 
Checking for llrint ... yes 
Checking for llrintf ... yes 
Checking for log2 ... yes 
Checking for log2f ... yes 
Checking for log10f ... yes 
Checking for lrint ... yes 
Checking for lrintf ... yes 
Checking for rint ... yes 
Checking for round ... yes 
Checking for roundf ... yes 
Checking for sinf ... yes 
Checking for trunc ... yes 
Checking for truncf ... yes 
Checking for atan2f ... yes 
Checking for ldexpf ... yes 
Checking for powf ... yes 
Checking for mkstemp ... yes 
Checking for nanosleep ... yes 
Checking for socklib ... yes 
Checking for netdb.h, struct addrinfo ... yes 
Checking for netdb.h, getaddrinfo() ... yes 
Checking for sockaddr_storage ... yes 
Checking for struct ipv6_mreq ... yes 
Checking for struct sockaddr_in6 ... yes 
Checking for struct sockaddr sa_len ... no 
Checking for arpa/inet.h ... yes 
Checking for inet_pton() ... yes 
Checking for inet_aton() ... no 
Checking for socklen_t ... yes 
Checking for closesocket() ... no 
Checking for networking ... yes 
Checking for inet6 ... yes 
Checking for gethostbyname2 ... yes 
Checking for SCTP ... no 
Checking for sys/poll.h ... yes 
Checking for inttypes.h (required) ... yes 
Checking for int_fastXY_t in inttypes.h ... yes 
Checking for malloc.h ... yes 
Checking for aligned malloc ... no 
Checking for memalign() ... yes 
Checking for posix_memalign() ... yes 
Checking for alloca.h ... yes 
Checking for fastmemcpy ... yes 
Checking for hard-coded tables ... no 
Checking for mman.h ... yes 
Checking for mprotect ... yes 
Checking for dynamic loader ... yes 
Checking for dynamic a/v plugins support ... no 
Checking for pthread ... yes (using -lpthread)
Checking for direct.h ... no 
Checking for windows.h ... no 
Checking for io.h ... no 
Checking for rpath ... no 
Checking for iconv ... yes 
Checking for soundcard.h ... yes (sys/soundcard.h)
Checking for termcap ... yes (using -lncurses)
Checking for termios ... yes (using termios.h)
Checking for shm ... yes 
Checking for strsep() ... yes 
Checking for vsscanf() ... yes 
Checking for POSIX select() ... yes 
Checking for audio select() ... yes 
Checking for gettimeofday() ... yes 
Checking for glob() ... yes 
Checking for setenv() ... yes 
Checking for setmode() ... no 
Checking for sys/sysinfo.h ... yes 
Checking for Apple IR ... yes 
Checking for pkg-config ... yes 
Checking for Samba support (libsmbclient) ... no 
Checking for /dev/mga_vid ... no 
Checking for tdfxfb ... no 
Checking for s3fb ... no 
Checking for wii ... no 
Checking for tdfxvid ... no 
Checking for xvr100 ... no 
Checking for tga ... yes 
Checking for md5sum support ... yes 
Checking for yuv4mpeg support ... yes 
Checking for bl ... no 
Checking for DirectFB ... no 
Checking for X11 headers presence ... yes 
Checking for X11 ... yes 
Checking for Xss screensaver extensions ... no 
Checking for DPMS ... yes (using Xdpms 4)
Checking for Xv ... no 
Checking for XvMC ... no 
Checking for Video Decode Acceleration (VDA) ... no 
Checking for VDPAU ... no 
Checking for Xinerama ... no 
Checking for Xxf86vm ... yes 
Checking for XF86keysym ... yes 
Checking for DGA ... no 
Checking for xmga ... no 
Checking for 3dfx ... no 
Checking for VIDIX ... yes 
Checking for VIDIX PCI device name database ... yes 
Checking for VIDIX dhahelper support ... no 
Checking for VIDIX svgalib_helper support ... no 
Checking for GGI ... no 
Checking for GGI extension: libggiwmh ... no 
Checking for AA ... no 
Checking for CACA ... no 
Checking for SVGAlib ... no 
Checking for FBDev ... yes 
Checking for DVB ... yes 
Checking for PNG support ... yes 
Checking for MNG support ... no 
Checking for JPEG support ... no 
Checking for OpenJPEG (JPEG 2000) support ... no 
Checking for PNM support ... yes 
Checking for GIF support ... no 
Checking for VESA support ... no 
Checking for SDL ... no 
Checking for SDL image ... no 
Checking for OpenGL ... yes (backends: x11 egl_x11)
Checking for MatrixView ... yes 
Checking for DXR2 ... no 
Checking for DXR3/H+ ... no 
Checking for IVTV TV-Out (pre linux-2.6.24) ... no 
Checking for V4L2 MPEG Decoder ... yes 
Checking for OSS Audio ... yes 
Checking for aRts ... no 
Checking for EsounD ... no 
Checking for NAS ... no 
Checking for pulse ... no 
Checking for JACK ... no 
Checking for OpenAL ... no 
Checking for ALSA audio ... no 
Checking for Sun audio ... no 
Checking for VCD support ... yes 
Checking for Blu-ray support ... no 
Checking for dvdread ... yes (internal)
Checking for internal libdvdcss ... yes 
Checking for libcdio ... no 
Checking for cdparanoia ... no 
Checking for bitmap font support ... yes 
Checking for freetype >= 2.0.9 ... yes 
Checking for fontconfig ... yes 
Checking for fribidi with charsets ... no 
Checking for SSA/ASS support ... yes 
Checking for ENCA ... no 
Checking for zlib ... yes 
Checking for bzlib ... no 
Checking for RTC ... yes 
Checking for liblzo2 support ... no 
Checking for mad support ... no 
Checking for Twolame ... no 
Checking for Toolame ... no 
Checking for OggVorbis support ... no 
Checking for libspeex (version >= 1.1 required) ... no 
Checking for libgsm ... no 
Checking for OggTheora support ... no 
Checking for mpg123 support ... no 
Checking for liba52 support ... no 
Checking for libmpeg2 support ... yes (internal)
Checking for libdca support ... no 
Checking for libmpcdec (musepack, version >= 1.2.1 required) ... no 
Checking for FAAC support ... no (in FFmpeg: no)
Checking for FAAD2 support ... no 
Checking for libilbc support ... no 
Checking for libopus decoding support ... no 
Checking for LADSPA plugin support ... no 
Checking for libbs2b audio filter support ... no 
Checking for Win32 codecs ... no 
Checking for XAnim codecs ... yes (dynamic loader support needed)
Checking for RealPlayer codecs ... yes (dynamic loader support needed)
Checking for QuickTime codecs ... auto 
Checking for Nemesi Streaming Media libraries ... no 
Checking for LIVE555 Streaming Media libraries ... no 
Checking for RTMPDump Streaming Media library ... no 
Checking for FFmpeg ... yes 
Checking for libpostproc ... yes 
Checking for libopencore_amr narrowband ... no 
Checking for libopencore_amr wideband ... no 
Checking for libdv-0.9.5+ ... no 
Checking for CrystalHD ... no 
Checking for Xvid ... no 
Checking for Xvid two pass plugin ... no 
Checking for x264 ... no (in FFmpeg: no)
Checking for libdirac ... no 
Checking for libschroedinger ... no 
Checking for libvpx ... no 
Checking for libnut ... no 
Checking for zr ... no 
Checking for libmp3lame ... no (in FFmpeg: no)
Checking for mencoder ... yes 
Checking for UnRAR executable ... yes 
Checking for TV interface ... yes 
Checking for DirectShow TV interface ... auto 
Checking for Video 4 Linux TV interface ... no 
Checking for Video 4 Linux 2 TV interface ... yes 
Checking for Radio interface ... no 
Checking for Capture for Radio interface ... no 
Checking for Video 4 Linux 2 Radio interface ... auto 
Checking for Video 4 Linux Radio interface ... auto 
Checking for Video 4 Linux 2 MPEG PVR interface ... yes 
Checking for ftp ... yes 
Checking for vstream client ... no 
Checking for OSD menu ... no 
Checking for Subtitles sorting ... yes 
Checking for XMMS inputplugin support ... no 
Checking for GUI ... no
Checking for automatic gdb attach ... no 
Checking for compiler support for noexecstack ... yes 
Checking for linker support for --nxcompat --no-seh --dynamicbase ... no 
Checking for linker support for --large-address-aware ... no 
Checking for linker support for --version-script ... yes 
Checking for joystick ... no 
Checking for lirc ... no 
Checking for lircc ... no 
Checking for DVD support (libdvdnav) ... yes (internal)
Checking for XML catalogs ... SGML catalog 
Checking for XML chunked stylesheet ... chunk.xsl 
Checking for XML monolithic stylesheet ... docbook.xsl 
Checking for XML DTD ... docbookx.dtd 
Checking for valid XSLT processor ... xsltproc 
Creating config.mak
Creating config.h

Config files successfully generated by ./configure --prefix=/usr !

  Install prefix: /usr
  Data directory: /usr/share/mplayer
  Config direct.: /usr/etc/mplayer

  Byte order: little-endian
  Optimizing for: native

  Languages:
    Messages/GUI: en
    Manual pages: en
    Documentation: en

  Enabled optional drivers:
    Input: dvdnav(internal) ftp pvr tv-v4l2 tv libdvdcss(internal) dvdread(internal) vcd dvb networking 
    Codecs: ffmpeg(internal) real xanim libmpeg2(internal) 
    Audio output: oss v4l2 mpegpes(dvb) 
    Video output: v4l2 matrixview opengl pnm mpegpes(dvb) fbdev xvidix cvidix x11 xover yuv4mpeg md5sum tga 

  Disabled optional drivers:
    Input: vstream radio tv-v4l1 tv-dshow librtmp live555 nemesi cddb cdda bluray smb 
    Codecs: libvpx libschroedinger libdirac x264 xvid crystalhd libdv libopencore_amrwb libopencore_amrnb qtx win32 libopus ilbc faad2 faac musepack libdca liba52 mpg123 libtheora libgsm speex libvorbis toolame twolame libmad liblzo gif OpenJPEG 
    Audio output: sun alsa openal jack pulse nas esd arts ivtv dxr2 sdl 
    Video output: zr zr2 ivtv dxr3 dxr2 sdl vesa gif89a jpeg mng svga caca aa ggi winvidix 3dfx xmga dga vdpau xvmc xv directfb dfbmga bl xvr100 tdfx_vid wii s3fb tdfxfb mga 

'config.h' and 'config.mak' contain your configuration options.
Note: If you alter theses files (for instance CFLAGS) MPlayer may no longer
      compile *** DO NOT REPORT BUGS if you tweak these files ***

'make' will now compile MPlayer and 'make install' will install it.
Note: On non-Linux systems you might need to use 'gmake' instead of 'make'.

Please check MTRR settings at /proc/mtrr (see DOCS/HTML/en/video.html#mtrr)

NOTE: Win32 codec DLLs are not supported on your CPU (x86_64) or your
operating system (Linux). You may encounter a few files that cannot
be played due to missing open source video/audio codec support.

Check config.log if you wonder why an autodetection failed (make sure
development headers/packages are installed).

NOTE: The --enable-* parameters unconditionally force options on, completely
skipping autodetection. This behavior is unlike what you may be used to from
autoconf-based configure scripts that can decide to override you. This greater
level of control comes at a price. You may have to provide the correct compiler
and linker flags yourself.
If you used one of these options (except --enable-menu and similar ones that
turn on internal features) and experience a compilation or linking failure,
make sure you have passed the necessary compiler/linker flags to configure.

If you suspect a bug, please read DOCS/HTML/en/bugreports.html.
The lines that strike me:

Code: Select all

Checking for ALSA audio ... no 
but later:

Code: Select all

    Audio output: sun alsa openal jack pulse nas esd arts ivtv dxr2 sdl 
I don't understand that.

And here's why, if anyone could explain to us. I'm still vague on it.

Code: Select all

From [b]config.log[/b] of the mplayer compilation in question:
##########################################

============ Checking for ALSA audio ============

#include <alsa/asoundlib.h>
int main(void) { return 0; }

cc -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize /tmp/mplayer-configure--6770/tmp.c  -fpie -DPIC -D_REENTRANT    -ffast-math -fpie -pie   -lncurses -lpng -lz   -lXext -lX11 -lpthread -lXxf86vm -lGL -ldl -lEGL -ldl  -o /tmp/mplayer-configure--6770/tmp -lasound -ldl -lpthread -lm
/tmp/mplayer-configure--6770/tmp.c:1:28: fatal error: alsa/asoundlib.h: No such file or directory
 #include <alsa/asoundlib.h>
                            ^
compilation terminated.


Result is: no 
##########################################
[1]

The fact is: truly no such file: asoundlib.h in directory alsa or any other on my crippled, experimented-with Debian air-gapped box (just rechecked).

Just checked in my Gentoo box, /usr/include/alsa/asoundlib.h is there. But this online Debian box doesn't have it:

Code: Select all

# find /usr/ -name 'asoundlib.h'
#
returns empty.

Even without figuring this our, I thought it must be mplayer will install if I manage to install ffmpeg.

I just check ffmpeg which I managed to install. I has too few formats supported, such as not x264 and not libvorbis (it reported it would install it but I couldn't encode into it), but I managed to convert audio from an elsewhere captured TV/DVB snippet from mp2 into a wav format, so probably can be gotten to work fine.

Why is it, that dbus has to be a requirement for ffmpeg? How immoral from whoever makes that a requirement for FFmpeg on Debian.

So, ffmpeg installed.

BTW, this is the ffmpeg configure line:

Code: Select all

./configure --prefix=/usr --enable-gpl --enable-x11grab
--enable-gpl is a requirement for --enable-x11grab, which I need for my screencasting:

Code: Select all

ffmpeg -f x11grab -s xga -r 25 -i :0.0 Screen_`date +%y%m%d_%H%M`_`hostname`.mkv
That line worked on my no-poetteringware experimental Debian.

Now mplayer will, as I will demonstrate, stop short again, but not so quickly at all!

In the meantime, lest I forget to say, I also upgraded that experimental box with this week's Jigdo Testing Branch. DVD's served from my local mirror.

Just one tip for people who might be reading this and anyhow thinking of compiling upstream packages (any packages) the the old configure/make/make install way:

If you do so, you have to keep track of the files that the package you are compiling installs on your system. Else, troubles looming over you box! If you some time in the future decide you want to remove it, how will you do i? And also, if you don't remove them, how do you know if a particular file does not belong to one of those that you compiled and install the old way?

I keep track of them this way:

Code: Select all

find /<my-system-partitions> -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt
<my-system-partitions> can be one sole, or can be all that is mounted on root if I unmount foreing filesystems, say from my SOHO.
And that line finds all the files that are at a particular time in my system partitions.

Run this separately from a command line to see what it does:

Code: Select all

date +%y%m%d_%H%M
It just puts into the name of that FIND_xxxxxxx_yourhostname.txt file the date and time when you take down the list of ALL files in your system partition(s).

The easiest way to know what a particular compiled program will install is to run that command after a successful:

Code: Select all

make
and then run:

Code: Select all

make install
and now run that find line from the command prompt again.
If you do the diff on those two before and after make install, and do some sed'ing on it, you can easily get the exact list of files that a program has just installed.

If you don't know how to use sed, you can edit the diff in some editor.

Anyway, this is the list of my ffmpeg install:

Code: Select all

/usr/share/ffmpeg
/usr/share/ffmpeg/examples
/usr/share/ffmpeg/examples/demuxing_decoding.c
/usr/share/ffmpeg/examples/Makefile
/usr/share/ffmpeg/examples/filtering_video.c
/usr/share/ffmpeg/examples/transcoding.c
/usr/share/ffmpeg/examples/metadata.c
/usr/share/ffmpeg/examples/transcode_aac.c
/usr/share/ffmpeg/examples/scaling_video.c
/usr/share/ffmpeg/examples/decoding_encoding.c
/usr/share/ffmpeg/examples/resampling_audio.c
/usr/share/ffmpeg/examples/README
/usr/share/ffmpeg/examples/filter_audio.c
/usr/share/ffmpeg/examples/filtering_audio.c
/usr/share/ffmpeg/examples/muxing.c
/usr/share/ffmpeg/examples/avio_reading.c
/usr/share/ffmpeg/examples/remuxing.c
/usr/share/ffmpeg/libvpx-1080p.ffpreset
/usr/share/ffmpeg/libvpx-720p50_60.ffpreset
/usr/share/ffmpeg/libvpx-1080p50_60.ffpreset
/usr/share/ffmpeg/ffprobe.xsd
/usr/share/ffmpeg/libvpx-720p.ffpreset
/usr/share/ffmpeg/libvpx-360p.ffpreset
/usr/share/man/man3/libavfilter.3
/usr/share/man/man3/libavutil.3
/usr/share/man/man3/libavformat.3
/usr/share/man/man3/libswscale.3
/usr/share/man/man3/libavdevice.3
/usr/share/man/man3/libavcodec.3
/usr/share/man/man3/libswresample.3
/usr/share/man/man1/ffprobe-all.1
/usr/share/man/man1/ffmpeg-codecs.1
/usr/share/man/man1/ffmpeg-formats.1
/usr/share/man/man1/ffmpeg-devices.1
/usr/share/man/man1/ffserver.1
/usr/share/man/man1/ffprobe.1
/usr/share/man/man1/ffmpeg-all.1
/usr/share/man/man1/ffmpeg.1
/usr/share/man/man1/ffmpeg-scaler.1
/usr/share/man/man1/ffmpeg-bitstream-filters.1
/usr/share/man/man1/ffmpeg-utils.1
/usr/share/man/man1/ffmpeg-protocols.1
/usr/share/man/man1/ffmpeg-filters.1
/usr/share/man/man1/ffserver-all.1
/usr/share/man/man1/ffmpeg-resampler.1
/usr/bin/ffserver
/usr/bin/ffmpeg
/usr/bin/ffprobe
/usr/lib/libswresample.a
/usr/lib/libpostproc.a
/usr/lib/libavcodec.a
/usr/lib/libswscale.a
/usr/lib/pkgconfig/libavfilter.pc
/usr/lib/pkgconfig/libavutil.pc
/usr/lib/pkgconfig/libswresample.pc
/usr/lib/pkgconfig/libavcodec.pc
/usr/lib/pkgconfig/libavdevice.pc
/usr/lib/pkgconfig/libavformat.pc
/usr/lib/pkgconfig/libswscale.pc
/usr/lib/pkgconfig/libpostproc.pc
/usr/lib/libavutil.a
/usr/lib/libavformat.a
/usr/lib/libavfilter.a
/usr/lib/libavdevice.a
/usr/include/libavutil
/usr/include/libavutil/frame.h
/usr/include/libavutil/threadmessage.h
/usr/include/libavutil/xtea.h
/usr/include/libavutil/adler32.h
/usr/include/libavutil/mem.h
/usr/include/libavutil/channel_layout.h
/usr/include/libavutil/dict.h
/usr/include/libavutil/opt.h
/usr/include/libavutil/random_seed.h
/usr/include/libavutil/ffversion.h
/usr/include/libavutil/time.h
/usr/include/libavutil/file.h
/usr/include/libavutil/timecode.h
/usr/include/libavutil/murmur3.h
/usr/include/libavutil/common.h
/usr/include/libavutil/log.h
/usr/include/libavutil/base64.h
/usr/include/libavutil/eval.h
/usr/include/libavutil/replaygain.h
/usr/include/libavutil/error.h
/usr/include/libavutil/bprint.h
/usr/include/libavutil/intreadwrite.h
/usr/include/libavutil/cpu.h
/usr/include/libavutil/blowfish.h
/usr/include/libavutil/display.h
/usr/include/libavutil/intfloat_readwrite.h
/usr/include/libavutil/avassert.h
/usr/include/libavutil/audio_fifo.h
/usr/include/libavutil/audioconvert.h
/usr/include/libavutil/version.h
/usr/include/libavutil/parseutils.h
/usr/include/libavutil/buffer.h
/usr/include/libavutil/lzo.h
/usr/include/libavutil/bswap.h
/usr/include/libavutil/hash.h
/usr/include/libavutil/pixfmt.h
/usr/include/libavutil/avstring.h
/usr/include/libavutil/avconfig.h
/usr/include/libavutil/avutil.h
/usr/include/libavutil/md5.h
/usr/include/libavutil/imgutils.h
/usr/include/libavutil/fifo.h
/usr/include/libavutil/ripemd.h
/usr/include/libavutil/attributes.h
/usr/include/libavutil/crc.h
/usr/include/libavutil/samplefmt.h
/usr/include/libavutil/intfloat.h
/usr/include/libavutil/aes.h
/usr/include/libavutil/downmix_info.h
/usr/include/libavutil/mathematics.h
/usr/include/libavutil/macros.h
/usr/include/libavutil/rational.h
/usr/include/libavutil/lfg.h
/usr/include/libavutil/sha.h
/usr/include/libavutil/sha512.h
/usr/include/libavutil/old_pix_fmts.h
/usr/include/libavutil/stereo3d.h
/usr/include/libavutil/hmac.h
/usr/include/libavutil/timestamp.h
/usr/include/libavutil/pixdesc.h
/usr/include/libavcodec
/usr/include/libavcodec/avfft.h
/usr/include/libavcodec/vda.h
/usr/include/libavcodec/vdpau.h
/usr/include/libavcodec/avcodec.h
/usr/include/libavcodec/dv_profile.h
/usr/include/libavcodec/old_codec_ids.h
/usr/include/libavcodec/version.h
/usr/include/libavcodec/dxva2.h
/usr/include/libavcodec/xvmc.h
/usr/include/libavcodec/vaapi.h
/usr/include/libswresample
/usr/include/libswresample/version.h
/usr/include/libswresample/swresample.h
/usr/include/libpostproc
/usr/include/libpostproc/postprocess.h
/usr/include/libpostproc/version.h
/usr/include/libswscale
/usr/include/libswscale/swscale.h
/usr/include/libswscale/version.h
/usr/include/libavformat
/usr/include/libavformat/avformat.h
/usr/include/libavformat/version.h
/usr/include/libavformat/avio.h
/usr/include/libavfilter
/usr/include/libavfilter/buffersink.h
/usr/include/libavfilter/buffersrc.h
/usr/include/libavfilter/avcodec.h
/usr/include/libavfilter/version.h
/usr/include/libavfilter/avfilter.h
/usr/include/libavfilter/asrc_abuffer.h
/usr/include/libavfilter/avfiltergraph.h
/usr/include/libavdevice
/usr/include/libavdevice/version.h
/usr/include/libavdevice/avdevice.h
which I got in the above described fashion.

These are the two full codecs-an-all-support outputs for the OLD (the dbus and systemd still on), and the experimental, the NEW (no-systemd-dbus-etAlia) Debian of mine at this time:

Code: Select all

$ ls -ABRgo Deb_140912-ffmpeg-h_full_???.txt 
-rw-r--r-- 1 300104 Sep 12 21:59 Deb_140912-ffmpeg-h_full_NEW.txt
-rw-r--r-- 1 310469 Sep 12 22:02 Deb_140912-ffmpeg-h_full_OLD.txt
$
To cut this presentation shorter a little, the NEW is missing stuff, like libvorbis, amr, vp8.

But this still proves that this what I long for must be possible. And also: that it really is not blocked at the upstream, desire like mine, to live with pure programs, without the multiseated ones, in the case of FFmpeg.

We are of cause talking of the real FFmpeg, who the "obsolete" one (It was touted, in Debian, and members of Debian team have nothing to do with politics?... It was, for quite some time, touted, by some members of the Debian packaging team, those who get the wording that newbies read such as in aptitude --I was back then a newbie in Debian-- it was touted as obsolete. Yes, when I tried to install FFmpeg, I was told that it was obsolete and that I had to use aconv. So much about politics. From me, who have been Offtopic'd quite a few times for speaking my opinion).

Back to Mplayer install.

Without dbus/systemd and any of poetteringware (if you've just parachuted in here).

I'm tired. I'll try and just find the final config.log or somesuch...

No. It's the make. Which failed.

After ./configure line as (much further) above, I ran:

Code: Select all

make
[2]

and this is the output, shortened:

Code: Select all

help/help_create.sh help/help_mp-en.h UTF-8
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o command.o command.c

...[snip]...

cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o stream/stream_bd.o stream/stream_bd.c
stream/stream_bd.c: In function 'get_clipinf':
stream/stream_bd.c:416:39: warning: variable 'end_offset' set but not used [-Wunused-but-set-variable]
     int langmap_offset, index_offset, end_offset;
                                       ^

...[snip]...

libmpcodecs/vf_screenshot.c: In function 'draw_slice':
libmpcodecs/vf_screenshot.c:161:9: warning: passing argument 2 of 'sws_scale' from incompatible pointer type [enabled by default]
         sws_scale(vf->priv->ctx, src, stride, y, h, dst, dst_stride);
         ^
In file included from libmpcodecs/vf_screenshot.c:41:0:
/usr/include/libswscale/swscale.h:226:5: note: expected 'const uint8_t * const*' but argument is of type 'unsigned char **'
 int sws_scale(struct SwsContext *c, const uint8_t *const srcSlice[],
     ^
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o libmpdemux/demux_lavf.o libmpdemux/demux_lavf.c
libmpdemux/demux_lavf.c: In function 'demux_lavf_fill_buffer':
libmpdemux/demux_lavf.c:659:5: warning: 'destruct' is deprecated (declared at /usr/include/libavcodec/avcodec.h:1156) [-Wdeprecated-declarations]
     if(pkt.destruct == av_destruct_packet && !CONFIG_MEMALIGN_HACK){
     ^
libmpdemux/demux_lavf.c:659:5: warning: 'av_destruct_packet' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3612) [-Wdeprecated-declarations]
libmpdemux/demux_lavf.c:663:9: warning: 'destruct' is deprecated (declared at /usr/include/libavcodec/avcodec.h:1156) [-Wdeprecated-declarations]
         pkt.destruct= NULL;
         ^
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o stream/stream_ffmpeg.o stream/stream_ffmpeg.c
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o sub/av_sub.o sub/av_sub.c
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o libmpcodecs/vf_fspp.o libmpcodecs/vf_fspp.c
libmpcodecs/vf_fspp.c:51:32: fatal error: libavutil/internal.h: No such file or directory
 #include "libavutil/internal.h"
                                ^
compilation terminated.
Makefile:758: recipe for target 'libmpcodecs/vf_fspp.o' failed
make: *** [libmpcodecs/vf_fspp.o] Error 1
I surely can't leave a 309K entire in here, but I can tell you that:

Code: Select all

# grep -i alsa <the-file-containing-the-entire-output-of-that-make>
#
returns empty string.

To alsa only through the intermediary, the Poettering's own pulseaudio! Why?

It I am not mistaken. Why?...
EDIT: This is part of the latest edit. Somewhat mistaken. I was missing some alsa*dev or such packages.

Actually the error reported at the end doesn't have any alse in it either, and I don't know what it means, that:

Code: Select all

make: *** [libmpcodecs/vf_fspp.o] Error 1
But alsa is conspicuously missing. Don't know what to do.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

[1] I think I get it. I need to install some *alsa*dev or such packages. They are missing. This is the latest EDIT.

[2] Just to demonstrate a previous point for poeple needing to compile programs from upstream, and not apt-get them, the command was actually:

Code: Select all

make 2>&1 | tee /somewhere/mplayer_140912_`date +%H%M`_make.txt && find / -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt && make install 2>&1 | tee /somewhere/mplayer_140912_`date +%H%M`_make_install.txt && find / -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt &
And then the diff get's me what it would install, but make failed, in this case. But that is my way to track what was installed.

The 2>&1 | tee I explained here:

How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php? ... 64#p552775

And I sadly keep misposting things, somewhat. I meant this for that topic not this. But I hope it's not such bad confusion. Just as I posted some talk which wasn't purely technical there, and meant it here. Sorry!
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#84 Post by timbgo »

timbgo wrote:With mplayer goes also mencoder. And I use my old command line to capture DVB from an old TV card on whichever of the Debian boxes that I install the TV-card in (physically in the PCI-slot). If I were able to get that mencoder to do the work, that would be a major breakthrough.

Yes, getting mencoder to work on my no-dbus, no-systemd, no-policykit, no-pulseaudio, no-any-poetteringware, would be a major breakthrough, because it would without much doubt prove that potteringware is really just an overhead on top of real programs, that can perfectly, although not at all easily at the current state of affairs, be done away with.
I made it.
But give me time to pull myself together first.
It was costly in nerves. Looked impossible. It would have been almost easy if I had been informed, and no one is.

Rest first.

Miro
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: How to avoid stealth installation of systemd?

#85 Post by keithpeter »

adenukolnis wrote:You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends.

Code: Select all

keith@kona:~$ dpkg -l *dbus* | grep ii
ii  libdbus-1-3:i386      1.8.6-2      i386         simple interprocess messaging system (library)
ii  libdbus-glib-1-2:i386 0.102-1      i386         simple interprocess messaging system (GLib-based shared library)
keith@kona:~$ dpkg -l *systemd* | grep ii
keith@kona:~$
Managed to keep it down to just a couple of the libdbus libraries on the 'init agnostic' desktop (see signature link). The wpasupplicant package depends on one of these, and I need my wpa2 wifi! Dbus is in base so you have to remove it.

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#86 Post by timbgo »

keithpeter wrote:
adenukolnis wrote:You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends.

Code: Select all

keith@kona:~$ dpkg -l *dbus* | grep ii
ii  libdbus-1-3:i386      1.8.6-2      i386         simple interprocess messaging system (library)
ii  libdbus-glib-1-2:i386 0.102-1      i386         simple interprocess messaging system (GLib-based shared library)
keith@kona:~$ dpkg -l *systemd* | grep ii
keith@kona:~$
Managed to keep it down to just a couple of the libdbus libraries on the 'init agnostic' desktop (see signature link). The wpasupplicant package depends on one of these, and I need my wpa2 wifi! Dbus is in base so you have to remove it.
But the quote doesn't contain (because it's in the signature) the page that put back the smile of on my face, as I've been recovering from some degree of exhaustion before my breakthrough (report still to be written):

An init agnostic old school desktop (Jessie)
http://sohcahtoa.org.uk/osd.html

On another note, I have to catch up with reading edbarx's thread:

The future with Systemd
http://forums.debian.net/viewtopic.php? ... 60#p552005

which also managed to slipped from my attention. Learned that it has grown much only from keithpeter's page above.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

User avatar
buntunub
Posts: 591
Joined: 2011-02-11 05:23

Re: How to avoid stealth installation of systemd?

#87 Post by buntunub »

As a long time Debian user, I have to say that I am floored by the efforts you folks are putting forth on this. I applaud you! It appears to me that there is widespread discontent with the Systemd Corporate takeover, and it begs the question... How was the decision for Debian to move to Systemd made? Was it done using the Debian guidelines on such things?.. I recall when the decision was made to move to GNOME3 that the reasoning foisted upon us all was that GNOME2 was going to be discontinued, and that may have been true, but is SysVInit being discontinued? If not, then WHY the wholesale move to Systemd?

Think on this. If Debian decided to stick with SysVInit, would that negatively impact Debian in any way? For instance, would dependancies become a problem in future Testing distros? I can see how that could become a problem in the very long term, but I do not think that is an excuse to abandoned the core Linux philosophy since its founding. Many big names in the Linux world have asked the questions, and to my knowledge, there has been no reasoned debate on the adoption of Systemd. There was just a dictatorial decision made on high. This is not the Debian way, and TBH, it is the Debian community that must bring this to heel.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: How to avoid stealth installation of systemd?

#88 Post by edbarx »

To add insult to injury, systemd was voted for, with the blessing of a casting vote! :shock:

systemd and similarly written software, is an attack on modularity, greatly harming the flexibility for which GNU/Linux is well known. systemd & co are clearly aimed at creating yet another Windows.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: How to avoid stealth installation of systemd?

#89 Post by keithpeter »

buntunub wrote:As a long time Debian user, I have to say that I am floored by the efforts you folks are putting forth on this.
In my case, just half a day's work and a couple of test installs on an old laptop. Edbarx and adenukolnis are doing a lot of mapping out and reading source code &c. I'm just testing their findings.

Keep an eye on the *BSD world, e.g OpenBSD, FreeBSD. They have no choice but to find a way out of this mud ball as they do not have the resources to fork whole desktop environments and sub-systems like dbus and even udev.
buntunub wrote:Many big names in the Linux world have asked the questions, and to my knowledge, there has been no reasoned debate on the adoption of Systemd.
Read Cathedral and Bazar (esr). I think the desktop environments started wiring systems together to make things slicker and allow plug and play. Then the systemd people sort of worked round what was there. The result is multiple intertwingling random walks. GNU/Linux does not have an overall design as such, just thousands of detailed decisions that edge one way then another, but which get 'frozen in' as we move forward. Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.

Interesting that the small projects (Slackware, *BSDs) are the ones taking an opinionated line on this based on overall architecture.
edbarx wrote:To add insult to injury, systemd was voted for, with the blessing of a casting vote! :shock:
Remember that we have 10 to 20 years of systemd because of the adoption in the EL world (RHEL, Centos, Oracle &c) with their 10 year support horizons. Irrespective of the Tech Committee's vote, systemd would be out there and upstream projects would be assuming its presence to some extent.

I think that the story is about supporting diversity and promoting modularity as ebarx and others keep saying.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: How to avoid stealth installation of systemd?

#90 Post by edbarx »

In 10 or 20 years, there will be developments, and the negative impact of projects like systemd, will be attenuated. GNU/Linux works much like biological systems: there is no centralised control, and yet, it worked for at least the time it existed. systemd and co. is an attempt at streamlining GNU/Linux, especially GNU desktops, but the great drawback of this approach is, this same strategy kills diversity at the core of the system. It also takes away modularity which allowed many diverse systems to be configured straight from the kernel upwards.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

goulo
Posts: 47
Joined: 2012-01-19 09:52

Re: How to avoid stealth installation of systemd?

#91 Post by goulo »

keithpeter wrote:Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.
Gentoo! (or maybe you're not considering it "major"?)

If down the road I find systemd becoming required (or too difficult to avoid) on my Debian, I'll switch to Gentoo or one of the BSDs...

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: How to avoid stealth installation of systemd?

#92 Post by keithpeter »

goulo wrote:
keithpeter wrote:Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.
Gentoo! (or maybe you're not considering it "major"?)
Apologies! I should have said 'high volume' rather than 'major', just number of users no implied comment on 'quality' :oops: I mean't the likes of RHEL/Fedora and the clones, SLES/openSUSE, Debian/Ubuntu/downstream distros.

A new twist on the Old School Desktop: installing cups with --no-install-recommends brings a systemd library called libsystemd-daemon0 which itself seems to have no dependencies on anything other than libc. Adding xpdf and the splix drivers gives me printing functionality and the poppler tools (pdfunite &c) which I use a lot.

https://packages.debian.org/jessie/libsystemd-daemon0

Back to edbarx's points about modularity. Why is this package a direct dependency of CUPS and not a dependency of one of the core systemd libraries if it is needed when using a systemd based init? I'll try and track that one through...

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#93 Post by timbgo »

Since the previous speakers talked a little of not-such-volume but the-most-diversity Gentoo GNU/Linux distribution, let me make good on a previous promise of mine.
timbgo wrote:Allow me to tell you that on Gentoo, quite a number of people decided to go without those multiseat[s].
Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-9 ... ight-.html
But we have a few developers there that openly care for the Fourth Amendment to the Constitution to the United States (such legislature is generally in all democratic countries' constitutions; for the less initiated in legalese, it's your right to privacy, secrecy, in your communications). Aarghh, this calls for a quote, and I can only promise I will try to be back to insert it here... wait...
Nope, haven't found the talk, but it's blueness, a Council Member https://wiki.gentoo.org/wiki/User:Blueness
( typoes corrected, quoted text cleaned a little )
And, since we have other academics around (keithpeter:

http://sohcahtoa.org.uk/
Keith Burnett
Teaching maths post-16 in Birmingham UK.

), let me tell you more about this guy (I couldn't talk like that of a Professor, or to a Professor back when I studied at the University of Zagreb in the late 1970s, and I like this change); oh dear, do I like Latin!:

Anthony G. Basile, Curriculum Vitae
http://opensource.dyc.edu/basile-cv

Here's Anthony defending privacy:

http://blogs.gentoo.org/blueness/2014/0 ... y-or-exit/

And next link is where you can best understand what eudev is.

In particular take notice of the discussion btwn ssuominen, the main implementer in Gentoo of udev (integrated with systemd, can't be separated from it, works only when systemd is in the system), and blueness, one of my heroes in the FOSS, the main developer of eudev, the free-from-systemd fork of udev, that just you-don't-ever-notice-it works.

eudev vs udev - current user perspectives
https://forums.gentoo.org/viewtopic-t-9 ... rt-25.html

I have been working on liberation-from-systemd-and-associates issues since I posted here last.

But I haven't yet started writing the planned report how I managed to get my box poetteringware-free and somewhat functional, because I went and read all on the other topic that edbarx started.

And do you think I didn't end up reading all that has been discussed anew on the systemd issue on debian-devel list?

I did, but only after having read other great blogs and webpages on the matter, and viewed a few very, very important videos (of course, I viewed them on a clone machine of my somewhat successful no-poetteringware Debian master machine), videos which are very much, although indirectly, on the subject (but from a broader view, from the big picture prospective).

What I will be able to share with you on the latter matters just above, just given a foretaste in this post you are now reading, is hard to tell. I've been reading, watching, thinking, weighing people's POVs, presentations, decisions (sic!) on this Debian-break-or-not, Debian-defeat-or-some-hope-left poetteringware-imposed-or-not issue for all this a day and more hours, and it's all so profoundly in my mind, but very unsorted...

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#94 Post by timbgo »

GNU freedom software users and developers are a very mixed crowd.

Looking back, to me, if love of knowledge is anything to be admitted among the most noble of virtues a man can possess, I am glad to remember how my first encounter with Grsecurity/Pax twin pack of programs back some three years ago, was love at first sight, just like the hatred of the NSA's SELinux, sadly holding onto the majority of GNU/Linux installations of today, was a guts feeling right from the very first encounter.

I can not tell how happy I am that my Tips page:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616

has had more views in the few recent days than previously in months...

I can not tell for certain, there is more to a man's life than his own knowledge of himself, more to his words than his own mind, but I have a similarly good feelings and hopes, or gut aversion and hatred, about other programs of the realm of GNU/Linux, and at this point BSD family and other *nix have to be taken into considerations.

I have just started this my new post in this "How to avoid Stealth Installation of systemd" topic in Debian Forums talking of programs good and evil, almost morally so; but sure it' the developers that are such: it's the author's honesty or lack thereof which is reflected in his programs, just as it is the artist which is (spiritually) seen in his picture or heard in his music.

I started on morality, and lack of, in the truly honest and moral GNU ground, where things can grow; they really can't, no, in proprietary swamps and deserts; those are aberration, abomination under nice looks and guises. Only GNU/BSD/other-free-licenses, they are the sole ground for growth of meaningful human works, and the sole ground of defence in the global Orwellian society, post-Snowden time, which is ticking on us.

And I started on morality because I see the following articles as honest and moral, as truthful, the following articles which were written by someone whom my hero Professor from the previous post of mine in this topic recognized as true developer and chose his work for his newest flavor in Gentoo, this one:

Project:Hardened musl
https://wiki.gentoo.org/wiki/Project:Hardened_musl

I am talking about articles by Rich Felker, developer whose integrity reflects in his work:

http://www.musl-libc.org/

These are the articles:

Broken by design: systemd
http://ewontfix.com/14/

Systemd has 6 service startup notification types, and they're all wrong
http://ewontfix.com/15/

I have nothing to add there, since these people are a few classes away in FOSS than me. I am a poor user fighting for his chances to securely use my conputers, poor user forced into never-ending research and finding his own technical solutions, else would have been owned.

But I did learn a lot in my quest, and I can tell other users (and I always have newbies at heart) a piece of advice here and another one there, thankfully.

On the above Rich Felker's perfect diagnose on the sick systemd program, my advice even to newbies very fresh, is: give it a read, take the little that you currently can out of it, and come back once you have grown bigger in GNU/FLOSS, that next time you read the pages of true knowledge like those, more insight descends into your spirit.

Let's now talk more of morality and immorality, of honesty and truth in the GNU/FLOSS works and societies.

Can I go straight to what even the great honest spy (being a spy doesn't have to mean being dishonest; there are moral people in every walk of life), what even the great honest spy Edward Snowden didn't know about:

http://video.fosdem.org/2014/Janson/Sun ... eport.webm

And I want to use the opportunity that Debian provides in its Social Contract:

https://www.debian.org/social_contract
3. We will not hide problems
We will keep our entire bug report database open for public view at
all times. Reports that people file online will promptly become
visible to others.
and hope that I won't be accused of copyright breach (

Really? The Surveillance Engine Terminated All My Videos
http://forums.debian.net/viewtopic.php?f=3&t=113059

) for taking literally down the sermon by Poul-Heening Kamp, as I will listen to that video, link further above, entitled "NSA operation ORCHESTRA Annual Status Report" on my no-poetteringware Debian box. A note. PHK is in his speech impersonating, as if representing, the NSA, "us", "we", means them in the transcription below:
Poul-Heening Kamp wrote: ...So, this is our poster boy: the Debian random number generator.

This is really beautifully executed.

This is due to {ascend in a path} [a guess, is unintelligle], you know, this gets Valgrind to complain, and I can't see it does anything sensible. You should just remove it.

And they did.

So for two years all the Debians had lousy random numbers which made bruteforcing SSL and stuff, like that...: done.

You earned a pretty good bonus.

OpenSSL is the crown jewel.

OpenSSL is the standard library if you want crypto.

Getting SSL to work against all browsers and all that stuff without using OpenSSL is very very tricky.

Reading the OpenSSL manuals or source code, is not tricky, that's close to impossible.

And that's 300,000 lines of code, so good luck with that!

The documentation is deficient and misleading, and the defaults are deceptive. They don't do what you think they do.

This saves so much money in the collection, you have no idea.

So the overall status of the Operation Orchestra. It's a resounding success.

We spend less than a third of a percent of the NSA budget.

And it'd probably cost the collection cost by something like 50 %.

It's kept most of the Internet in plaitext, and it has never been exposed (in the press).

Edward Snowden has no papers on Orchestra at all.

...[snip]...
Pls., gentle reader, go ahead, and have a listen (the link is further above now). You will understand that all the FLOSS (the GNU/Linux, the BSD as well!, other *nix distros as well!) are pretty infiltrated.

But not taken over. Not yet! I dare hope, am almost confident they never will be.

So the page where I got the link to the 2014 FOSDEM (Free and open source software developers' European meeting) conference, the page below, has a flawed title, but what can you? You live with your mistakes as well as with your successes:

Julian Assange: Debian Is Owned By The NSA
https://igurublog.wordpress.com/2014/04 ... y-the-nsa/

(pls. also notice further in the page that Wikileaks was officially denying, and previously to reaching that point in the page I listened to Julian's in the World Hosting Days 2014, specifically for that line and couldn't really hear such explicit statement at all)

That page however is so plausible about the reasons our GNU/Linux generally being owned by some particular entity.. Of which further below.

First let me transcribe what Julian said by video link from his exile in Equadorian Embassy in London.

The video was posted on Youtbe channel: "Даниил Иваньков" (which is Cyrillic azbyka, in Latin alphabet: Danyil Ivañkov, approximately)
Julian Assange wrote: That's one of the amazing things about encryption, that somehow the Universe has permitted the type of mathematics, the type of physics which permits the resistance against unlimited coercive force: it doesn't matter how many soldiers, how many guns, how many nuclear weapons you have, if your encryption system is right, it can pass through the United States, it can effectively create a channel through a hostile country the way you can send, political... economic and political information, bringing two greater societies together, in this case Latin America and Europe.
...[snip]...
BBC Click Online presenter wrote: Now, one of the big topics here is open source and I'm wondering whether the fact that you have an open system that everyone knows how it works would make encryption more secure than a closed system.
Julian Assange wrote: Oh, we know from experience that it does seem to be the case, that there's a vast number of closed source snake oil encryption systems being spread around.

Now we know that Open Source is not entirely a solution, e.g. there was an encryption bug in the Debian's version of the SSH in the Random Number Generator which existed for years, and that was all open source.

Now it was eventually found and revealed, and it was found and revealed also because it was open source.

But the way things are done now is through backdoors. So these are backdoors designed to look like bugs.

And, you know, what is the security of the programmers who are involved in some of these open sources. Can you, when they do, I say, update their code, can you plant what looks like a bug, even a typo, that carries through?

Or, say, look at a... a system like Debian, these units, the various kinds of unit systems, look at all the packages they include. look at the upstream libraries, dependencies upon dependencies upon dependencies, and all you need to do is compromise one of those dependencies and there's a flow through and {these are getting back} [a guess, is unintelligle].

Modern systems are assembleges of incredible intellectual content which is being developed all over the world over the past ten years by many different players.

But there's an age now [a guess, is unintelligle] in CPUs, there's few, you know maybe three different securities layers in these systems.

But when you pull together thousands of packages altogether, it's pretty hard to actually resist the security compromises that are engineered by nation states.

It doesn't mean it's not worth trying, increasing the cost of owning the world.
...[snip]...

And I'd like to write more.

Don't worry, I have all the logs (taken with "... 2>&1 | tee ...", as explained previosly, and stowed away, and enough of history lines, to most likely reconstruct pretty much exactly how I succeeded in getting my no-poetteringware Debian to work).

But I might possibly first want to finish on these points about infiltration of "friends of NSA" into FOSS and also first give my review on the recent discussions on systemd on debian-devel, similarly to the first report of mine with which I started this topic. If I make all of that. It's really complex. All of it one and the same big picture, and that is what makes it all so much more harder to grasp and even harder yet to explain.

I might first need some rest. Of, if I can, normal duration. Or else go almost sleeplessly on after very short break. Don't know yet.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#95 Post by timbgo »

PART 1

of my insight into debian-devel mail-list "Stealth Installation of systemd?" thread in September 2014, only under various retitles

this is (if I'm not Offtopic'd or banned from the forums, not that there's any reason for it, but I have been banned for too little or false reasons).

PART 2/and more? yet to be written.

Also, take heed of what I'll tell you now: I can access mostly anywhere on the internet now, except for I can't access the links below, such as:
https://lists.debian.org/debian-devel/2 ... 00087.html
and any starting with that string:
lists.debian.org/debian-devel/2014/09/msg
of course with the http and :// in front,
(and that state has been lasting for more than an hour on every connection).

which I anyway have all of them in Iceweasel cache, so I *can* write this post and hopefully the followup.

Just telling. Pls. do tell if the links don't point to the text reported.

################################################################################################
If anyone thinks that this:

How Covert Agents Infiltrate the Internet to Manipulate, Deceive, and Destroy Reputations
https://firstlook.org/theintercept/2014 ... ipulation/
by Glenn Greenwald

has nothing to do with these dictatorial changes in Debian Schlinux
( why schlinux? see here:
The future with Systemd
http://forums.debian.net/viewtopic.php? ... 05#p553351
)

than they are either autodeceiving or deliberately not telling the truth.

For the latter, and to minor extent for the former, there is one word in plain English. If I had to say it to myself about myself, like those should, I'd be ashamed. So I'm being considerate.

Have a look at this derising attitude:

https://lists.debian.org/debian-devel/2 ... 00087.html
Rens Houben wrote: In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell has been seen typing:
Svante Signell wrote: Some food for thought about systemd:
... I thought we'd all agreed to stop bringing up tired arguments that
nobody but the "systemd MUST DIE" crowd really wants to hear anymore.
Svante Signell wrote: You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/
"Open source Tea Party". That explains *so* much...
What does that explain, dear developer-and-systemd-impositioner on Debian users? Your sorrow for the United States not being under British Crown?

We could talk like that...
Rens Houben wrote:
Svante Signell wrote: Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
"If we keep systemd, people who want to boycott systemd will boycott
us." Seriously, can we stop with the circular arguments as well?
Yes, seriously, we will! Lots of users will *not* remain with systemd-only-Debian!
The circle will have an exit, and for many, dear developer-and-systemd-impositioner on Debian users.

Your only chances are hiding what is happening. But that is to greater users' outrage later! Everything comes out, eventually. Snowden, Assange, IgnorantGuru, are some of many. I hope we will know more on who and how has ruined g-NSA's Schlinux and Debian in particular.

And also read this:
Rens Houben wrote: On Mittwoch, 3. September 2014, Svante Signell wrote:
Svante Signell wrote: Some food for thought about systemd:
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
debian-devel@ is for the development of the Debian distribution, not for
ranting. Please take your rants elsewhere. It's tiring and a waste of your and
many other peoples time. But it wont change things. Code changes things in
Debian.
What ranting? You call this concerned call for reason ranting? Unbelievable.
So many users, it's true: only those that can phathom it despite of the corporate propaganda, wish for systemd-free Debian Jessie!

Despite the corporate, with all of their tentacles in Debian, propaganda, which turns around many and makes them dazed and confused as to what they even could remember and know because they learned it in previous experience, and which keeps so many plain ignorant on what is being planned with, really, their computers, but so many users' wish for systemd-free Debian Jessie, and there's a DD who cares, and you call his forsight of the certain outcome in case of sytemd-imposition, you call his few open words of care and caution ranting?

Look up the followups to that mail (not reporting those here). Rens Houben obtained even Swante's apology for having brought those links to DDs pseudo-corporate attention (because it's corporate in the shadows, Schmoogle/Red Hat/NSA, really looks like)! No, Swante, you had nothing to apologize for, and you should not have apologized.

And there was this explanation of, cough cough, Debian happy democracy happenings by Marco d'Itri.
https://lists.debian.org/debian-devel/2 ... 00095.html
Marco d'Itri wrote: On Sep 03, Svante Signell wrote:
Svante Signell wrote: Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.
And there Marco gives us the graph telling about (yes: as far as that complete post, eplanations afterwards come after) the democratic likes of Debian crowds:
Oh, you can't care for everybody's needs. You'll take all the fewer that witlessly or for their windoze mentality go for the systemd (my guess: less than say one in ten), and all the uninformed, the huge chunk of the Debian population now in systemd who are uninformed, and those are now in systemd because it was imposed on them, or soone is to be imposed, without them ever having given a choice, and which are probably around nine out of ten, and you keep disparaging, pushing aside, ignoring the mostly advanced and informed who are, my guess, maybe one in ten among the Debian users. (The ratios are very approximate guesses that I gave in this paragraph.)

And of all the mix, you couldn't care for whoever don't want systemd. It's systemd-or-die attitude.

Because I don't think there is any plausible denying that the thinking in among the Debian huge crowd are in their great majority against systemd, and there are also many who plain and open don't want to even stay with Debian if there is only systemd-Debian to be

And you can't accomodate for them?

How nice and clean of you! A great DD this one! Red Hat's and Schmoogle's will sure like this one!

Luckily, a DD whom I admire for his defence of FOSS and defence of Debian Social Contract, and a member of the Debian Technical Committee who voted against systemd as default in Debian, along with Ian Jackson, replied what was due to our dear Marco.

https://lists.debian.org/debian-devel/2 ... 00105.html
Steve Langasek wrote:
Marco d'Itri wrote: And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.

< link given above, not duplicated here >
Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

Code: Select all

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu dot com                       vorlon at debian dot org
If I have any hope left in the FOSS, it's people like Steve. And Cameron below.

Because there followed a great explanation, so pls. you people who are reading this, along with administrators who are assessing whether to maybe even throw me offtopic or ban my post, as you have done in the past, consider that I do not blame DDs as the community, just there is something wrong, probably corruption of some kind, some breaking of Debian Social Contract and Debian Free Software Guidelines, in the Debian hierarchy and in among the decision making high ranking Debianers...

And there followed a great explanation by Cameron Norman:
https://lists.debian.org/debian-devel/2 ... 00109.html
Cameron Norman wrote: El mié, 3 de sep 2014 a las 4:07 , Marco d'Itri escribió:
Marco d'Itri wrote: On Sep 03, Steve Langasek wrote:
Steve Langasek wrote: >
https://qa.debian.org/popcon-graph.php? ... beenhere=1
< link repeated for clarity, although already given further above, and it is by Marco, but quoting allowed only 3 deep >

Please stop using graphs showing how various teams have forced systemd onto users' systems as if it is somehow a democratic endorsement of the outcome.
I am not sure about how the concept of democracy applies to this, but the graph clearly shows that nobody is being forced to do anything and indeed about 4000 users choose to install systemd-shim and to not use systemd.
Ok, let me explain Steve's POV. Many packages depended on libpam-systemd before systemd-shim was ever in the archive, leading to systemd-sysv being installed by a normal dist-upgrade on Sid (and, although I am not sure, testing). The alternative was often to have GNOME or Network Manager removed, two very popular packages (and the latter quite important). Even after systemd-shim was uploaded to the archive (still at logind v204 here), libpam-systemd depended on "systemd-sysv | systemd-shim". This meant that users' systems would switch init systems on a normal dist-upgrade *unless* they manually intervened and knew which package they had to install to avoid that. Finally, systemd v208 was uploaded to unstable with an unconditional dependency on systemd-sysv. All of these actions led to users experiencing a change of init system before they had taken action to change init systems, which means that the graphs are not reliable in claiming that the majority of users wanted systemd as their init system.

I can not speak for Steve, but I recognize that some or all of those actions above were called for. The final one especially (systemd v208 upload), since their was ample warning and communication (something like one or two months I think), the move was a long time coming, and systemd was chosen as the default init system by then (not true for the other two actions).

I hope that helps you understand how the graph does not depict how many users elected to use systemd as their init system.

Best regards,
--
Cameron Norman
I understand most of it, and obviously systemd was imposed. It's use-systemd-or-die Debian decisioners telling us!

One of the really sincere and honest proposals also followed on the list.
Noel Torres wrote: On Wednesday, 3 de September de 2014 16:21:31 Svante Signell escribió:
Svante Signell wrote: [...]
should be allowed, and I'm trying to find out how many of debian users
and developers are interested in working together with me on such a
solution. Best would be to have an option in the installer (hidden by
[...]
I volunteer to test this, not for contributing (I am not a programmer), for a very simple reason: I do not want my long-running servers (and those of my clients) to be rebooted for something that should be so simple as upgrading a service or applying some non-kernel security patch.

I may have (I agree I have) some conservative thinking. I've been well against network-manager messing my interfaces
I also live without that windozed and windows-looking piece of software-maybe-spyware (don't know). A Linux user should know how to issue "ifconfig eth0", and having direcories or files (can't remember now, I've lived without it since 2013) in /etc with spaces in their names, that was more than I could bear.
and I'm against systemd as well, but I really think the Unix way, when properly implemented, is the way to go. And if it does not work, make it work instead of building a dinosaur and force dependencies into it (and yes, I'm pointing at you, Gnome Debian packagers, both for network-manager and systemd).

In resume: count on me to test and check and report bugs and triage.
Miroslav Rovis
Zagreb, Croatia,
http://www.CroatiaFidelis.hr
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#96 Post by timbgo »

No, the following is not for Debian-disparaging reason, but to show how things have been, sadly, swept under the carpet, sometimes, in Debian.
And...
And as an incentive that DDs don't repeat such mistakes:

Debian's OpenSSL maintainer (Kurt Roeckx) should be changed
http://www.gergely.risko.hu/debian-dsa1571.en.html
old stuff, 2008, must not be forgotten. Pls. see my previous posts in this topic, i.e. Julian Assange's and PHK's, and IgnorantGuru's recount on this story.

Miro
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

User avatar
/tmp
Posts: 437
Joined: 2011-12-31 08:39
Location: GNU Userlands

Re: How to avoid stealth installation of systemd?

#97 Post by /tmp »

So, would this situation be a legitimate reason to fork Debian GNU/Linux using sysvinit?

I love Debian GNU/Linux but if this keeps up I'm switching to FreeBSD.
Buster | Intel I5-3380M | Dell Latitude e6530 Laptop | 4 GB RAM | Intel HD Graphics 4000




"To check for updates, you must first install an update for Windows Update."

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#98 Post by timbgo »

/tmp wrote:So, would this situation be a legitimate reason to fork Debian GNU/Linux using sysvinit?

I love Debian GNU/Linux but if this keeps up I'm switching to FreeBSD.
I'm not a developer to reply to that question. I still hope in a few great Debian developers to save us from these frankestein changes, brother.

I love[d] G../Linux too. Can't call it that anymore:

The future with Systemd
http://forums.debian.net/viewtopic.php? ... 05#p553351

Sorry to have to tell the truth. I know this saddens many people. Believe me I am very sad to write that.

Miro
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

timbgo
Posts: 265
Joined: 2013-04-14 12:17

Re: How to avoid stealth installation of systemd?

#99 Post by timbgo »

Part 2

Pls., take heed of what I'll tell you now: I can access mostly anywhere on the internet now, except for I can't access the links below, such as:
https://lists.debian.org/debian-devel/2 ... 00111.html
and any starting with that string:
lists.debian.org/debian-devel/2014/09/msg
of course with the http and :// in front,
(and that state has been lasting for more than --since first part, see the time there-- on every connection).

which I anyway have all of them in Iceweasel cache, so I *was able* to write this second part.

Just telling. Pls. do tell if the links don't point to the text reported.

#########################################################################
The titles were mostly:

systemd, again (Re: Cinnamon environment now available in testing)

upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

and other

There was, first, announcement of Cinnamon, the Gnome fork, here:
https://lists.debian.org/debian-devel/2 ... 00111.html
Margarita Manterola wrote: ...[snip]...
cinnamon is now fully available in testing.
...[snip]...
And there followed simple questions and answers:
https://lists.debian.org/debian-devel/2 ... 00130.html
Adam Borowski wrote: On Thu, Sep 04, 2014 at 02:57:16PM +0200, Margarita Manterola wrote:
Margarita Manterola wrote: On Thu, Sep 4, 2014 at 9:43 AM, envite <envite at rolamasao dot org> wrote:
Adam Borowski wrote: Does this Cinnamon for Debian include systemd ?
Yes, for Linux it includes systemd. For kFreeBSD it should be able to
work without systemd, but some packages haven't compiled yet due to
missing dependencies.
If Cinnamon can work without systemd, why is it a hard dependency?
But that conclusion is corrected and clarified by Cameron Norman:
https://lists.debian.org/debian-devel/2 ... 00132.html
Cameron Norman wrote: TL;DR `sudo apt-get install systemd-shim`

You are mistaken, it is not. What I suspect happened is that something
depended on logind (libpam-systemd) and libpam-systemd depends on
"systemd-sysv | systemd-shim". This means that systems will have their
init system switched even if unneeded unless they predict the issue or
track down the dependency tree, then learn they have to install
systemd-shim (which does not exist on Wheezy, so you will have to
install systemd-sysv then another init after the upgrade). This bug
has been reported and marked as WONTFIX for reasons that have not been
fully explained (it is claimed people with init=/lib/systemd/systemd
in their kcmdline will experience breakage due to systemd-shim
conflicting with systemd-sysv, however this is actually not likely at
all according to the shim maintainer).
Which is more than I can grasp. Also because I have a sysvinit system, and have removed not only systemd, but also dbus and other poetteringware from my system. (still yet to document what I did).

I don't want anyhing systemd, not even systemd-shim. I could settle for some of the alternatives suggested in:

http://boycottsystemd.org/
boycottsystemd.org wrote: Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.
...[snip]...
systemd alternatives include runit, OpenRC, s6, monit, perp, supervisord, Upstart and GNU dmd.
Is there or will there be place for me at all as Debian user?

I don't see that my option, no-poetteringware, will be viable. Reminder: it is on my Gentoo box, really no poetteringware, and system functional there (not much of a desktop though, but I don't care for those; it'd be great is some simple DE were there for no-poetteingware-whatsoever users like me, but not essential; essential is: privacy, but really).

But I can only follow what information I can get from where our systems are done in Debian. Means: back to debian-devel mail-list.

https://lists.debian.org/debian-devel/2 ... 00145.html
Noel Torres wrote: On Friday, 5 de September de 2014 09:57:34 Josselin Mouette escribió:
Josselin Mouette wrote:> Noel Torres wrote:
Noel Torres wrote: So we are clearly failing to follow the least surprise (for the user)
path.

Should not logind depend on systemd-shim | systemd-sysv instead?
No. Systemd is the default init system. The default dependencies should
reflect that.

And from a purely functional point of view, it makes more sense to bring
by default the standard, upstream-supported, well-tested solution, than
the Debuntu-specific hack to use it with an inferior init system.

Cheers,
"Inferior" is your personal (and others) opinion. I do not think systemd being
clearly superior. It has better points that sysvinit but also worse points
(already extensively discussed). So that is not a reason to force users
install systemd when they are just upgrading their currently working systems.

So:
* standard: we chose so (against the opinion of a lot of people), nothing more
to discuss about that
* upstream-supported: not exclusive to systemd
* well-tested: not true. sysvinit is the well tested, and well known one
(including its quircks and lacks)
* superior: plain no
(This opinion was later, surely, attacked.)

If I remember correctly, Josselin Mouette was/is also one of the DDs that is preventing us users from having real so called "obsolete" FFmpeg in our systems, and it was all ready for inclusion last month. We would have been able to choose btwn FFmpeg and Avconv. Didn't happen (IIUC). Red Hat and Schmoogle must be happy!

https://lists.debian.org/debian-devel/2 ... 00184.html
The Wanderer wrote: Some, only some of the discussion that followed:

On 09/05/2014 at 03:44 PM, Cameron Norman wrote:
Cameron Norman wrote: On Fri, Sep 5, 2014 at 5:20 AM, Matthias Urlichs wrote:
Matthias Urlichs wrote: Thus, unless the user explicitly tells the apt{-get,itude}
subsystem not to switch to systemd (by whatever means, the
details of which I personally am not at all interested in), a
dist-upgrade should do so.
Currently, this is impossible, since systemd-shim DNE on Wheezy.
DNE=does not exist (IIUC)
But it should be possible to 'apt-get update ; apt-get install systemd-shim ; apt-get dist-upgrade', and AFAICT that should get the job done.

Alternately, it should be possible to pin systemd-sysv to "not installed", even when no such package as systemd-sysv exists - and then dist-upgrade should be able to figure out the necessary dependency resolution.
Which brings us to my issue again (and I hope other users will try and get a no-poetteringware-whatsoever system):

Will it be possible to pin down poetteringware (all of it), and install and use Debian, some basic packages, such as Iceweasel and, say, Mplayer/Mencoder and FFmpeg, less important: on some very basic DE?

I'm fighting for no-poetteringware not only for me, but for everybody, as an option in Debian.

One point I can't understand. It all worked up to now, but now there is this systemd-shim to save a user from systemd... Why can't it be viable to have a system without systemd-<whatever>, whatever=shim as well?

This fine analysis:
https://lists.debian.org/debian-devel/2 ... 00206.html
Adam Borowski wrote: On Sat, Sep 06, 2014 at 11:12:35AM +0200, Ansgar Burchardt wrote:
Ansgar Burchardt wrote: Noel Torres writes:
Noel Torres wrote: So, in your POV, forcing millions of sysadmins out there to take extra pain to keep their systems running as they expect is the way to go?
I think it's fair to expect the few hundred people[1] that want to run a non-default init system to do so, yes.

[1] I can also make up numbers :)
Ok, so let's quantify the view of sysadmins somehow. This can actually be done in a meaningful way: let's count posts on places where technically-minded folks gather. There's plenty of minor blogs that are biased, but let's choose big sites where we can have a reasonable chance of being unbiased. I chose Slashdot and it's fork, SoylentNews.

Counting only posts above the default threshold for a non-logged-in user:


http://soylentnews.org/article.pl?sid=14/09/01/1844249
(article about "Poettering's vision")

unrelated/no clear opinion: 3
anti-poettering: 10
anti-systemd in particular: 8
ambivalent: 1
pro: 0 !!!

http://soylentnews.org/article.pl?sid=14/08/19/0841221
(article about systemd)

unrelated/no opinion: 12
pro: 1
anti: 15

http://linux.slashdot.org/story/14/09/0 ... n-my-linux
(article about systemd-caused schism)

unrelated/no opinion: 33
pro: 2
anti: 22
ambivalent: 4
That fine analysis above didn't get any of the DD pro-Red Hat poeple budge. What can?

In the followup, which is, IMO, too sick to report it here, Axel Wagner even doubts the identity of the posters on Slashdot. Gimme a break!

https://lists.debian.org/debian-devel/2 ... 00207.html

I guess I wouldn't have been able to reply this nicely to that message:
https://lists.debian.org/debian-devel/2 ... 00208.html
Adam Borowski wrote: On Sat, Sep 06, 2014 at 03:02:06PM +0200, Axel Wagner wrote:
Axel Wagner wrote: Moreover, you would need to not count posts, but unique posters, which will be a very hard to get, because in a lot of flames there are people who get one spam-address after the other, when they get blocked, which would further skew the numbers towards whichever camp has more disrespectfull trolls.
That's Slashdot not 4chan. The discussion there is mostly civil, and spam-posters immediately get moderated into oblivion. If you want your posts to show up, you need an established account rather than something newly created. Heck, in the methodology I used, the threshold was high enough that even an old account would require at least one up-mod to get counted.

Thus, Slashdot post count is more meaningful than, say, counting posts here on unmoderated debian-devel.
And nothing can help those people understand (just if they were selling their skills for some grease; pretence better than of the best actors': cool, happy for the future grease, some already in their pockets; no, I'm not accusing them, just telling that they act like politicians stealing, and while stealing, talking honey and milk in alternation with threats and laws, to people; but they really couln't be just plain witless, could they?).

Here Matthias Urlichs
https://lists.debian.org/debian-devel/2 ... 00211.html
talks how "most people" ... "are OK with systemd".

More talk. But I have to bring one of the persons with "merits" for all of us not having real FFmpeg in Debian, IIUC.
https://lists.debian.org/debian-devel/2 ... 00291.html
Josselin Mouette wrote: Adam Borowski wrote:
Adam Borowski wrote: Ok, so let's quantify the view of sysadmins somehow. This can actually
be done in a meaningful way: let's count posts on places where
technically-minded folks gather. There's plenty of minor blogs that are
biased, but let's choose big sites where we can have a reasonable chance
of being unbiased. I chose Slashdot and it's fork, SoylentNews.
...[snip]...
...[snip]... Snip not shown in original. That is, Josslin is talking of the Slashdot and SoylentNews count done by Adam Borowski
Excuse me? Are you trying to use the fact that you and your stupid
friends are trolling about systemd all day long in order to justify your
own rants?

And I thought you couldn’t get any lower. You have a very good shovel.

Code: Select all

-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-
The logo should not be there. That's abuse of a fine honorable symbol, because this is hiding behind it. Red Hat and Schmoog must love her!

I too, signed underneath all my posts, I have lost terrible time trying to understand what I can do to keep my systems from poetteringware, which I hate, for reasons all around the net (reason not all around only if someone is either witless or in someone's pockets), and (which I hate) because it already cost me nerves hugely.

And I'm fighting for no-poetteringware options for all as well. Not just me.

What do you want, dismiss me as fool too? What kind of language is that? And from a DD?

She got a fine reply:
https://lists.debian.org/debian-devel/2 ... 00297.html
Jakub Wilk wrote: * Josselin Mouette, 2014-09-08, 10:58:
Josselin Mouette wrote: Excuse me? Are you trying to use the fact that you and your stupid friends are trolling about systemd all day long in order to justify your own rants?
And I thought you couldn’t get any lower. You have a very good shovel.
OTOH, a hydraulic excavator must have been involved in writing your mail.

Can we now all go back to the ground level? (Or higher?!)

This mail is so polite:
https://lists.debian.org/debian-devel/2 ... 00421.html
Martinx - ジェームズ wrote: Hi!
Yes, please... I vote +1 for not silently replace sysvinit by systemd, when upgrading from Debian 7, to 8.
...[snip]...
Also, the current Populatiry Contest is unfair, because it shows systemd winning, when it is being pushed.
...[snip]...
Also, providing two init systems during Debian 8 cycle (or until kFreeBSD remains around), will calm down people all over the world.
...[snip]...
But, those mentioned before, and others of their kind, will probably say that it is not representative.
That is by a non-expert user.

And here's one by an expert/advanced user.
https://lists.debian.org/debian-devel/2 ... 00360.html
Samuel Thibault wrote:
Ondřej Surý wrote: Ondřej Surý, le Tue 09 Sep 2014 13:10:48 +0200, a écrit :
And I'm saying that all we have is anecdotal evidence
Our uni lab has switched to systemd, 20% of the machines do not boot.
The admin is currently looking at what the difference could be between
them to expain such a difference (same hardware, supposed-to-be same
software installation).
But I remember as I make another example in my attempt at contributing to getting users more of a chance for remaining with freer Debian, I remember how that DD wrote previously. I hope I'll find it. It's very educational.

https://lists.debian.org/debian-devel/2 ... 00343.html
Samuel Thibault wrote:
Matthias Urlichs wrote: You cannot have an MTA without configuring it, and nobody even tried to
implement auto-migration of the old default mailer's configuration to the
new one. Also, we didn't switch to a different default mailer because the
new one offered a heap of features and infrastructure which the other
lacked.

None of this applies to systemd.
This does apply to systemd too.

When I got "upgraded" to systemd on july, my system was completely
misbehaving for several reasons related to my configuration:

- I had an ISO mount in my fstab, whose file didn't exist any more,
sysvinit never complained about it, systemd just stopped at boot.
- I had several bind mounts, forming loops, which has never been a
problem for sysvinit, but it made systemd take ages to boot & shutdown
because it'd crazily bring thousands of lines in /proc/mounts, details
in #755674.
- I had tweaks in /etc/inittab to get the gettys earlier than
daemon starts, in case those get stuck etc., this does not work any
more with systemd.
- I had tweaks in /etc/inittab to have more gettys on the text console,
this does not work with systemd any more.
- I had tweaks in /etc/inittab to shutdown instead of reboot when I
press ctrl-alt-backspace, this does not work with systemd any more.

If I had tweaks in /etc/inittab to enable serial consoles, would the
upgrade to systemd kept them working? I haven't found code about this.
This is *especially* important for servers, for which that might be the
only way to access the system without having to take the bike to get to
the datacenter.

Of course, these are all bugs that could be fixed in systemd. I however
doubt we can discover (and fix) them all for Jessie, and I strongly
doubt that the first item of my list (which is more a difference of
behavior than a bug) will be ever be fixed actually.

If it ain't broken, don't break it.
On which recount there were further followups.

https://lists.debian.org/debian-devel/2 ... 00347.html
Samuel Thibault wrote:
Ondřej Surý wrote: Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
And you are saying that you can do all those tweaks, but you cannot
pin systemd-sysv to not install?
No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I would have gotten all these changes all of a sudden without asking for them. That can be pretty bad for the serial console access.

And I'm saying that I don't think this is an isolated case, I believe most our users prefer to stay with sysvinit when upgrading from wheezy to jessie, at least to keep the behavior of their machine as it is, and then consider switching to systemd. Collapsing both is asking for regressions and angry users...
Are you reading this, DDs?:
Samuel Thibault wrote: ...(they already tell me bad Debian jokes about the upgrade to systemd).
You realy want to get Debian to become all the more the target of bad jokes?

And on and on it goes. Someone there is in the pockets of... This much is not being plain witless.

Time to quote IgnorantGuru...

I repeat my stance from a previous post in this topic that the title of this article below is flawed ("Julian Assange: Debian Is Owned By The NSA"). Not really untruthful, since not completely false, but neither completely right, I would certainly believe. That title was wrong tactically. Very few writers don't make such mistakes sooner or later.

The denial:
https://twitter.com/wikileaks/status/454246967124963328
WikiLeaks wrote:
Glyn Moody wrote: @wikileaks: a question - did you really say "Debian Is Owned By The NSA"? -
@glynmoody None of our people said this. Mr. Assange spoke about vulnerability of OS's to bribes and bugdoors in upstream components.
But most of IgnorantGuru's talk is just about right.

Julian Assange: Debian Is Owned By The NSA
https://igurublog.wordpress.com/2014/04 ... y-the-nsa/

Where reads how:
IgnorantGuru wrote: [Julian] discussed ...[snip]... how encryption can level the playing field between powerful governments and people, and about 20 minutes into his address, he discussed how UNIX-like systems like Debian ...[snip]... are engineered by nation-states with backdoors which are easily introduced as ‘bugs’, and how the Linux system depends on thousands of packages and libraries that may be compromised.
Then he recommends:
watching his 36 minute Q&A in its entirety, keeping in mind my recent warnings about how GNU/Linux is almost entirely engineered by the government/military-affiliated Red Hat corporation
That is:

Julian Assange - Q&A - 2014-04-02 (English)
https://www.youtube.com/watch?v=UFFTYRWB0Tk

He goes on to say:
Assange mentions how Debian famously botched the SSH random number generator for years (which was clearly sabotaged). Speaking of botched security affecting Red Hat, Debian, Ubuntu, Gentoo, SuSE, *BSD, and more, the nightmarish OpenSSL recently botched SSL again ...[snip]...
And he gave another recommendation, which I am thankful to have been given the opportunity to have, to learn more on the then latest matter.
For more on how OpenSSL is a nightmare, and why this bug is one among many that will never be found, listen to FreeBSD developer Poul-Heening Kamp’s excellent talk at the FOSDEM BSD conference.
and that is:

http://video.fosdem.org/2014/Janson/Sun ... eport.webm
IgnorantGuru wrote: From the start, my revelations on this blog about Red Hat’s deep control of Linux, along with their large corporate/government connections, hasn’t been just about spying, but about losing the distributed engineering quality of Linux, with Red Hat centralizing control.
Yet ...[snip]... as soon as I started using Linux years ago, I noted that all the major distributions used watered-down encryption ...[snip]... This told me then that those who controlled distributions were deeply in the pockets of intelligence networks.
And his conclusion is:
So it comes as no surprise to me that they jumped on board systemd when told to, despite the mock choice publicized to users – there was never any option.
To me, his conclusions sound plausible.

And yet, legally, if they are doing so, they are breaking the law. While my reproducing here his words is perfectly in compliance with the rights given to me as user, perfectly in compliance with Debian Social Contract, and the law, of the U.S.A. where Debian is based, and of EU where I live.

What can be done? Nothing without proof, and I have none. You can't get any proofs of mere maliciosness, let alone corruption, bribes, intimidation in matters of OpenSSL, and yet it all soooo stinks!!!

You can't get any proof of systemd and poetteringware programmers planting bugs.

A world class expert probably could, but surely with huge effort, only discover mere typoes and/or other mistakes of whichever kind, that, effectively, somehow backdoor your system; But even if you discovered those, you could not prove them to be by design.

Honest world class experts probably could uncover bugdoors in poetteringware, and such bugdoors will not be other than very likely to have been deliberately introduced, with the backdooring purpose, if such functionality of some of those bugs ends up backdooring you system...

But to discover and confirm that, we need work of honest people like Grsecurity devs, like PHK, also like some of our honest Debian devs, sorry I don't trust all, we need the work of people like those fine Finns from pages linked from IgnorantGuru's page above who uncovered the Heartbleed...

Still, even once the backdoors in poetteringware is discovered, which I'm confident it will happen, there wouldn't be any proof before the court of law. All that we would get, again, is just proof of "typoes" and "honest mistakes"!

And you can imaging who is throwing money and bying brains to create bugdoors on us. Not repeating those names.

What to say in the end of this two part recount of some of the discussions about our Debian machines of tomorrow, dear friend, on debian-devel mail-list?

Do something about it, dear reader.

I've so far really done as much as I could. I spent weeks on this, to try and contribute to preventing of these frankestein changes. I'm out of breath and exhausted and broken a little. And sad, very sad. Remember I believed in {G../Linux}, and I can't even call it that anymore.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Anyone can dismiss these: kernel hooks for rootkits
linux capabilities for intrusion?

User avatar
buntunub
Posts: 591
Joined: 2011-02-11 05:23

Re: How to avoid stealth installation of systemd?

#100 Post by buntunub »

Miroslav, your posts are too long, and they are repeated from the Offtopic rant. You do the movement to stop Systemd in Jessie no good service by posting like this. There is a growing movement afoot already, and from well seasoned and reasoned folks that are long time Debian users/developers. Really, there is no need to rant. Let's keep things moving in the right direction, please, and know that many Debian users feel as you do.

Post Reply