I broke telnetd
Hi, I was trying to install the latest version of telnetd. I thought that dpkg would stop the install if my dependencies weren't met. That didn't happen, however, and now telnetd is broken. This machine has not had upgrades for two years, so I'm scared to try updating things like libc6 and such (thinking other things will get broken). We are about to replace this server with a new one anyway. I noticed that I had version 0.12 installed previously. Can I find that version in a deb package anywhere? Please copy your answers to [EMAIL PROTECTED] Thanks, Joel
Re: apt + proxy
Andrea Balzi wrote: Hi, I have installed a PC in a LAN where is not web-proxy without problems. After I put the PC in to a LAn with a web-proxy (squid), I've create the apt.conf file in to /etc/apt directory with the following line: Acquire::http::Proxy "10.0.0.169:1428" try: Acquire::http::Proxy "http://10.0.0.169:1428"; HTH, joel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
make-kpkg problem
i tried to compile package a custom built kernel and encountered this error. - - - - - - - start [EMAIL PROTECTED]:/usr/src/kernel-dev/linux-2.5.6/linux$ make-kpkg clean dpkg: warning, architecture `i386-none' not in remapping table rm -f modules/modversions.h modules/ksyms.ver debian/files stamp-build stamp-configure stamp-source stamp-image stamp-headers stamp-src stamp-diff stamp-doc stamp-buildpackage stamp-libc-kheaders stamp-debian test ! -f .config || cp -pf .config config.precious test -f Makefile && /usr/bin/make ARCH=i386-none distclean make[1]: Entering directory `/usr/src/kernel-dev/linux-2.5.6/linux' Makefile:247: arch/i386-none/Makefile: No such file or directory make[1]: *** No rule to make target `arch/i386-none/Makefile'. Stop. make[1]: Leaving directory `/usr/src/kernel-dev/linux-2.5.6/linux' make: [clean] Error 2 (ignored) test ! -f config.precious || mv -f config.precious .config rm -rf debian/tmp-source debian/tmp-headers debian/tmp-image test -f stamp-building || test -f debian/official || rm -rf debian - - - end $ make-kpkg -version Version: $Revision: 1.39.2.1 $ Manoj Srivastava <[EMAIL PROTECTED]> $ uname -a Linux platinum 2.5.6 #1 Thu Mar 21 12:51:54 PHT 2002 i686 unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg problem
Ulf Rompe wrote: Your architecture seems to be misrecognized. do you have any idea how do I correct this? $ dpkg --print-architecture i386 If you aren't able to figure out why, you may want to force a correct name by setting it yourself: make-kpkg --arch i386 clean [x] ulf ok. but continuing... $ fakeroot make-kpkg --arch=i386 --revision=custom.1.0 kernel_image [ ... ] make[1]: Leaving directory `/usr/src/kernel-dev/linux-2.5.19/linux' test -f stamp-configure || /usr/bin/make -f /usr/share/kernel-package/rules configure /usr/bin/make ARCH=i386 \ CROSS_COMPILE=i386-linux- bzImage make[1]: Entering directory `/usr/src/kernel-dev/linux-2.5.19/linux' make[2]: Entering directory `/usr/src/kernel-dev/linux-2.5.19/linux/scripts' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/kernel-dev/linux-2.5.19/linux/scripts' scripts/split-include include/linux/autoconf.h include/config make[2]: Entering directory `/usr/src/kernel-dev/linux-2.5.19/linux/init' i386-linux-gcc -D__KERNEL__ -I/usr/src/kernel-dev/linux-2.5.19/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i686 -DKBUILD_BASENAME=main -c -o main.o main.c /bin/sh: i386-linux-gcc: command not found make[2]: *** [main.o] Error 127 make[2]: Leaving directory `/usr/src/kernel-dev/linux-2.5.19/linux/init' make[1]: *** [init] Error 2 make[1]: Leaving directory `/usr/src/kernel-dev/linux-2.5.19/linux' make: *** [stamp-build] Error 2 - - - - end thanks for the help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg problem
Colin Watson wrote: That looks like gcc isn't installed. $ gcc --version 3.0.2 thanks anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg problem
Colin Watson wrote: On Wed, Jun 26, 2002 at 09:25:28AM +0800, Joel wrote: Colin Watson wrote: That looks like gcc isn't installed. $ gcc --version 3.0.2 thanks anyway. Do you have the environment variable $CC set to something else? What does the following print? ${CC:-gcc} --print-libgcc-file-name OK. It was not set. [EMAIL PROTECTED]:~$ $ export CC=gcc [EMAIL PROTECTED]:~$ ${CC:-gcc} --print-libgcc-file-name /usr/lib/gcc-lib/i386-linux/3.0.2/libgcc.a then I rerun $ make-kpkg clean .SAME RESULTS Having gcc 3.0.2 as the default /usr/bin/gcc suggests you're not using Debian's normal gcc setup, so something may still be awry. You are right. I had originally installed potato rev 3. I have a very limited and slow internet connection and cannot do an upgrade via the NET. What I can do is download individual packages and sometimes copy somewhere other than a Debian source(for apt) and install them. So what I have now installed is $ dpkg --list | grep gcc ri gcc 2.95.4-6 The GNU C compiler. ri gcc-2.95 2.95.4-0.01090 The GNU C compiler. ii gcc-3.0 3.0.2-0pre0109 The GNU C compiler. ii gcc-3.0-base 3.0.2-0pre0109 The GNU Compiler Collection (base package). ri libgcc1 3.0.2-0pre0109 GCC support library. ri libgcc300 3.0-0pre010403 Shared libgcc. and I created a symlink /usr/bin/gcc -> gcc-3.0 Anyway, this is just an exercise for me(the "mk-kpkg" thing). Thank you so much for your patience. I am never giving up though. Any hints as to solve this is greatly appreciated. Thanks a lot, Colin Watson. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
subscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problem with my sound configuration!!!
I can't figure out how to make my sound hardware work. I am running potato. Compiled ALSA in my 2.5.9 kernel. Using xmms to play my mp3's reports no problem and the display shows normal playback but there is no sound output. I have made adjustments to my volume using the mixer. I am sure the volume is not zero. One thing I have noticed, my sound hardware uses IRQ 9 in Win2000 but it uses IRQ 9 here. Is this relevant to my problem? excerpt from dmesg: Advanced Linux Sound Architecture Driver Version 0.9.0beta12 (Wed Mar 06 07:56:2 0 2002 UTC). PCI: Found IRQ 10 for device 00:1f.5 PCI: Sharing IRQ 10 with 00:1f.3 PCI: Setting latency timer of device 00:1f.5 to 64 ALSA device list: #0: Intel ICH at 0xe000, irq 10 "Fun is the name of the game." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem with my sound configuration!!!
Joel wrote: I can't figure out how to make my sound hardware work. I am running potato. Compiled ALSA in my 2.5.9 kernel. Using xmms to play my mp3's reports no problem and the display shows normal playback but there is no sound output. I have made adjustments to my volume using the mixer. I am sure the volume is not zero. One thing I have noticed, my sound hardware uses IRQ 9 in Win2000 but it uses IRQ 9 here. Is this relevant to my problem? sorry. I mean IRQ 9 in Win2000 and IRQ 10 in Linux. excerpt from dmesg: Advanced Linux Sound Architecture Driver Version 0.9.0beta12 (Wed Mar 06 07:56:2 0 2002 UTC). PCI: Found IRQ 10 for device 00:1f.5 PCI: Sharing IRQ 10 with 00:1f.3 PCI: Setting latency timer of device 00:1f.5 to 64 ALSA device list: #0: Intel ICH at 0xe000, irq 10 "Fun is the name of the game." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Power control question
On Sun, Apr 29, 2001 at 03:23:53PM +0200, Viktor Rosenfeld wrote: > Hello, > > Joel Mayes wrote: > > > Just a quick question, how do i configure my Debian testing box so that > > the "poweroff" command actualy powers down my computer ? I'm using the > > standard > > 2.2.18pre21 kernel that come with debian. > > If the standard Debian kernel has APM enabled (wouldn't know, I always > compile kernels myself), then at the LILO prompt (provided you use > LILO), give it the parameter "apm=on". This should, at least on an ATX > machine, power off the computer on shutdown. > > Cheers, > Viktor > -- > Viktor Rosenfeld > WWW: http://www.informatik.hu-berlin.de/~rosenfel/ > Thanks, Victor That sounds like a good solution, APM is enabled but in the standard kernel but is turned off by default, ( or at least thats what my reading of boot logs tells me ) Cheers Joel Mayes >
Re: connect two hosts over wifi without router?
On Mon, Nov 27, 2023 at 02:54:44PM +0100, Hans wrote: > Hi folks, > > just before I am trying forever: > > Is it possible, to connect two hosts directly over wlan without using a > router? > > The background: I want to stream video from my drone using RTMP to my > notebook. > > This is already possible, when i am using a router. But in the fields, I got > no > router available (I have a portable router, yes, but I want to mimize and > ease > as possible). > > The goal of my project I am working of, shall be a bootable live-usb or live- > cd, which is preconfigured with the network address, a listening nginx for > RTMP, automatically started X with automatically started VLC. > > The user just has to start his drone software (or whatever) on a tablet or > mobile, input an IP in the streaming software and is ready. > > Everything shall be done without any router (because of avoiding as much > latencies as possible). > > At the moment I am stuck with the directly connection. > > If someone has running this already, I would be happy for any configurations, > or also with the help of some priciples. > > With an ethernet cable, this is easy (using a crossover ethernet cable), but > how do this with wireless? Is this technically possible at all??? > > Thanks for any help. > > Best regards > > Hans Probably there are a lot more knowledgeable people here than myself, but a naive search for "wifi adapter client host mode linux" brings up this page. https://woshub.com/create-wi-fi-access-point-hotspot-linux/ Most wifi adapters can operate as an access point, which is indicated by AP and AP/VLAN appearing in the output of `iw list`. Hope this helps -- Joel Roth
Re: Alpine/Gmail/Imap expert needed.
On Tue, Nov 28, 2023 at 02:06:13AM +0100, hw wrote: > On Mon, 2023-11-27 at 19:22 +0100, to...@tuxteam.de wrote: > > On Mon, Nov 27, 2023 at 06:57:51PM +0100, hw wrote: > > > On Sun, 2023-11-26 at 20:54 -0500, Karen Lewellen wrote: > > > > Your surprise is surprising given you are living no one's life but your > > > > own. > > > > as they say walk a mile in another person's shoes before you decide you > > > > know what solutions are possible for them. > > > > > > In that case, I suggest noone try to give any advice. > > > > Hey, hw: no need to get grumpy. The OP has been polite all the time, she > > just has special need. If you feel like that, better not answer. > > She has been the opposite of polite. I'm not offended at all by her manner, but at times find it hard to parse out what she wants/needs from her description. I don't blame her; certainly she writes as clearly as she knows how. Usually someone (in this case Gareth) gets what she wants. At least it's never dull ;-) > > Cheers > > -- Joel Roth
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote: > So, since for whatever reason Grub seems to be broken beyond repair, I today > tried to just replace it with rEFInd. Installation succeeded without any > trouble. But when I start my system, rEFInd just asks me if I want to boot > with fwupd or with the still very broken Grub. Am I missing something? Is > rEFInd really just something to select between different OSs (and not just > different distributions like Grub can very well do) and then gives the rest > over to their bootloaders or am I missing something so rEFInd will take over > all of Grubs jobs? I boot my debian-based system with rEFInd. Grub is not present. A couple big icons show on the boot screen. The small print at the bottom mentions hit F2 for more options. On my system, F2 offers a selection among all kernels present. rEFInd installs into EFI/refind/ in the EFI partition. I originally encountered it looking for something to boot debian on a Intel Mac. It's been trouble-free. > On 01.01.24 21:45, Richard Rosner wrote: > > > > > > On 01.01.24 21:20, Richard Rosner wrote: > > > > > > On 01.01.24 20:30, David Wright wrote: > > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: > > > > > On 01.01.24 18:13, David Wright wrote: > > > > > I can boot by hand, but since this is all archived anyways and it's > > > > > uneccessarily difficult to find some sort of guide how to even do > > > > > this, it might as well be a documentation for users having such > > > > > troubles in the future. > > > > > > > > > > Also, besides the way that I have no clue how it would have to look > > > > > like to set up a paragraph in the grub.cfg, I simply don't see > > > > > anything wrong with it anyways. So I can't even look at the grub > > > > > settings files grub.cfg is being generated from to check where the > > > > > error lies. > > > > You append the commands that you used to boot manually with into > > > > /etc/grub.d/40_custom, observing the comments there, and also into > > > > grub.cfg itself at the appropriate place (near the bottom). The > > > > former is so that Grub includes it in any new grub.cfg that you > > > > create. > > > Good to know. > > Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS > > menu after entering my password. At this point, I'm seriously > > considering slapping rEFInd on it and pray that it picks up on > > everything automatically and fix the situation. But so should Grub have, > > besides the fact that I can't even be entirely sure Grub is to blame and > > not something else. -- Joel Roth
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote: > In theory, it should > be as simple as refind-install. So the only reason I could guess to be the > reason would be that rEFInd might not be capable of handling LUKS, which > would be quite disappointing. My experiences are with vanilla filesystems only. LUKS obviously has specific requirements. Perhaps you could try having a root partition that is unencrypted? -- Joel Roth
Re: Printing the old way
On Tue, Jun 14, 2022 at 04:59:36PM -0400, pa...@quillandmouse.com wrote: > Folks: > > Back in the dark days of early Linux, before CUPS, we printed with > printers all the time. There was an infrastructure for doing this. Does > anyone remember how that worked? As in, what packages were needed, etc.? Using magicfilter with lprng lets you print a variety of file types. -- Joel Roth
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Fri, Jun 24, 2022 at 07:02:35AM +, Andrew M.A. Cater wrote: > There are a couple of useful habits to get into when removing things: > > There's an > > rm -i > Use the pwd command to check where you are in the > filesystem. (It may be short for "print working > directory"). > If you are deleting one file - change to the directory it is in, check that > it exists there first with the > > ls -al [filename] > > command. Since the file is in the current directory,you can use the > > rm ./[filename] > > [That's a period and a forward slash - limiting you to a file in the current > directory] > > Try and avoid using rm -rf and forced removal. The one exception is that > you have to remove a non-empty directory with -rf. If you first try -r > and it fails, that's a clue that you are actually about to delete a > directory. > > Again, if it's a single directory, change directories to the directory > that it is in and use the ./ The last suggestion, and it's the simplest: > > rm [filename] -rf ... > If you need to be doubly sure rm [filename] -irf will put in the interactive > prompt again. > > Some of this is learnt the hard way from administering one machine that > other people relied on :) All good suggestions, along with making backups. I list the files first: ls some-pattern then add a pipe to rm: ls some-pattern | rm or ls some-pattern | rm -rf I know the OP said they weren't asking advice, but I can't help putting in my two bits :-) cheers, > With every good wish, as ever, > -- Joel Roth
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Sat, Jun 25, 2022 at 09:45:58AM -0400, Greg Wooledge wrote: > On Fri, Jun 24, 2022 at 07:42:25PM -1000, Joel Roth wrote: > > I list the files first: > > > > ls some-pattern > > > > then add a pipe to rm: > > > > ls some-pattern | rm > > > > or > > > > ls some-pattern | rm -rf > > Those commands do not work. rm does not read a list of files from stdin. > > Even if you were to add xargs, those commands still would not work in > all cases. They would only work in the simplest cases, where none of > the filenames contain whitespace, single-quote characters, or double-quote > characters. > > That's because xargs does not split its input on newlines. It splits > its input on "quoted words". Like this: > > unicorn:~$ echo 'a list of "quoted words"' | xargs printf '<%s>\n' > > > > > > Any unbalanced single or double quote will cause an error: > > unicorn:~$ echo "I don't know.mp3" | xargs printf '<%s>\n' > xargs: unmatched single quote; by default quotes are special to xargs unless > you use the -0 option > > > And even if xargs *did* have some option to split its input only on > newlines, a filename that *contains* a newline would still break it. > > Finally, ls does not always reproduce filenames exactly. There are > some systems (I'm not sure about all versions of Debian, but definitely > some Unix systems) where certain characters will be printed as > question marks by ls. That means any file containing one of those > characters would make the ls|xargs rm construct fail. > > If you want to use ls as a preview for what will be removed, that's > perfectly fine. You just can't use "up arrow | xargs rm" as your > follow-up command. Instead, use "up arrow" and then use command editing > to replace the ls with rm. I was actually using 'xargs rm' in an alias. Thanks for pointing out the limitations. -- Joel Roth
Re: Converting an old Chromebook to pure Debian, was: OT, Recommendation for low cost laptop
On Mon, Jul 11, 2022 at 11:55:02AM +0100, Ottavio Caruso wrote: > Hi, inspired by: > > On 11/07/2022 08:32, john doe wrote: > > > I'm looking for something cheap (max would be around 300 bucks), do you > > have any suggestions/ideas? > > > My local Cash-Converter/Generator(s) have plenty of old-ish Chromebooks for > £50 or less. > > I know it's possible to run some sort of Linux with trickeries like Crouton > or similar. I wonder if it's just possible to nuke all Google related junk > and install native Debian or is it not technically possible? Crouton lets you install a native debian. You have to put the Chromebook into developer mode first. One problem I had (ten years back or so) was that every subsequent boot brings up a dialog to *leave* developer mode. Saying yes clobbers the system you painstakingly installed. cheers > > -- > Ottavio Caruso > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > -- Joel Roth
Re: No HDMI Audio
On Sun, Jul 24, 2022 at 01:37:34PM -0400, Timothy M Butterworth wrote: > All, > > I am not getting any sound through HDMI. I have an AMD Ryzen 7 4700U CPU > with integrated Renior Graphics. I checked the device and it is not muted. > Does anyone have any ideas? > > inxi -F > Audio:Device-1: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel > Device-2: Advanced Micro Devices [AMD] > Raven/Raven2/FireFlight/Renoir Audio Processor driver: snd_rn_pci_acp3x > Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio driver: > snd_hda_intel > Sound Server: ALSA v: k5.10.0-16-amd64 > > *aplay -l* > card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [HDMI 1] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287 > Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > *lspci* > 04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637 > 04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] > Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01) > 04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 10h-1fh) HD Audio Controller I would stop pulseaudio and test `aplay sample.wav` using the device option to target various alsa devices. Once you've found the HDMI device that works, you can set it as the default device. -- Joel Roth
Re: Issues with audio after updating
On Sun, Oct 09, 2022 at 10:37:18AM +0200, Maximiliano Estudies wrote: > After an update yesterday my audio stopped working. I'm currently on > Linux version 5.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 > (Debian 11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) > 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) > > The issue seems to be with pulseaudio, but I'm not really sure. > pavucontrol shows "no available cards for configuration" on the > configuration tab, and ```pactl list cards``` returns nothing but > ```pacmd list-cards``` does returns all the available cards. There is > a similar behavior when listing the sinks, pactl returns only the > dummy sink and pacmd returns the alsa sink, but with state: IDLE > > I have no idea how to debug this further so any tips are much appreciated! Hiya Maximiliano, That the two pulseaudio utilities disagree on what devices are present, it seems plausible that some part of pa is to blame. You may like to verify that your ALSA subsystem is working properly, and include this in your bug report. For that, disable pulseaudio[1], systemctl --user stop pulseaudio.socket systemctl --user stop pulseaudio.service test play an audio file with aplay, mpv, etc. to a device listed by aplay -l, or cat /proc/asound/cards To start pulse audio again: systemctl --user start pulseaudio.socket systemctl --user start pulseaudio.service 1. https://askubuntu.com/questions/8425/how-to-temporarily-disable-pulseaudio-while-running-a-game-under-wine I've not tested this myself. cheers, -- Joel Roth
Re: cpan oddity
f...@dnsbed.com wrote: Jude DaShiell wrote: > > I ran cpan and did quick configuration and chose sudo to elevate > > privileges when necessary. Unfortunately I don't have write access on > > /usr/local/bin so cpan is crippled. > try cpanminus? > $ sudo apt install cpanminus Please note that when installing via cpanminus to a unprivileged directory, such as $HOME/perl5, you must also include it in your environment. see 'man local::lib'. -- Joel Roth
Re: Is perl still the No.1 language for sysadmin?
Can't resist adding my 2c On Mon, Apr 03, 2023 at 11:20:26PM +0200, Eduard Bloch wrote: > Hallo, > * Emanuel Berg [Mon, Apr 03 2023, 02:15:10AM]: > > > > The reason Perl gives you more than one way to do anything > > > is this: I truly believe computer programmers want to be > > > creative, and they may have many different reasons for > > > wanting to write code a particular way. What you choose to > > > optimize for is your concern, not mine. I just supply the > > > paint—you paint the picture. > > > > I agree but I think maybe the success of Python, and its > > development speed, is actually because of some of that > > rigidness, yes, including the whitespace lack of freedom. Google adopting python early on has something to do with this, too. > I don't think so, Sir! Python has certain advantages but the "meaningful > whitespace" is IMHO not one of them. > > That said, I have been an active Perl user ~20y ago and for the last > couple of years slowly converting to Python for scripting purposes, > still using Perl here and there. > > Therefore, my recent impressions and reflections: > > Perl: > PRO: > - still excels on creating quick solutions in a one-liner for many > purposes where string/text input/output and some generic algorithms > count > - great cross-platform availability as long as you don't need CPAN, even > part of Git-Bash and therefore an "obligatory" component I'm surprised to hear this. What is not cross-platform about CPAN? > - IMHO clean lifecycle of variables. Means, you can set "strict" and > then be sure that you manage your variables correctly, without much > risk of strange runtime effects I'm not sure about the connection with managing variable lifecycles, perhaps you can explain. This pragma *does* catch a class of typos that python is vulnerable to. Perhaps python IDEs take care of this. > - flexibility in statement writing (although making them sometimes > looking strange and requiring more brackets than you initially wanted) > - a "friendly" API for users who just came from Bash or AWK scripting, > many things would look familiar and need only minor adaption, > especially when one knows "computer science" and understands what is > going on underneath anyway For writing any code it helps if you understand the underlying concepts. > NEUTRAL: > - true threads are possible... the last time I tried that was great but > unstable, but I think they have fixed it in a rewrite a while ago (not > tried again for years, cannot tell for sure) > CONTRA: > - OOP is awkward, has always been, it just sucks Well, it doesn't make much point to discuss it here, but I'll note that there are legitimate criticisms and solutions for those who want them. Also, I seem to recall perl borrowed its OO design from python. Checking... yes. "I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented."(*1) There is a new object system being cooked up, based on decades of experience with OO in perl and other languages. There is already more than enough OO goodness for me to get my work done :-) > - still sucky when it comes to complex data structures Well, maybe this is not the place to discuss it, but I'm curious if it's the syntax or the implementation that bothers you. > - ECO system unfortunately slowly fading away I would say the most highly depended-on distributions in CPAN are well maintained and new contributions continue. Sometimes I encounter a project (like Prima, a cross platform GUI) that has been around for years and only now come to my attention. As part of developing new perl releases, the entire of CPAN is checked to make sure new features do not break existing code. > - error handling (exceptions?) Of course this can be improved. The basic behaviors are sufficient, tho. > - sometimes too rigid ways of method calling Perl is rarely accused of this. Using it's the other way around-- too many ways. Do you have a specific example? Otherwise I don't really belong comparing the two languages as haven't done significant work with python. Have fun with whatever language :-) Joel > Python3: > PRO: > - HUGE and modern ECO system, and mostly good&useful documentation > - Developers listening to user's wishes, recognizing and completing > missing features and seeing modern developments > (things like string interpolation with f-literals) > - flexible ways of method calling with default/optional/... parameters > - a certain level of rigidness keeps your code understandable even if > you touch it a year later, and also for the code from your coll
Re: fetchamil / procmail as non root : unable to call script
On Tue, Jun 20, 2023 at 07:52:24AM +0200, BASSAGET Cédric wrote: > Hello > I'm using fetchamil / procmail to fetch mails from an POP server and parse > it then launch a script or system call : > > > # cat .fetchmailrc > set logfile fetchmail.log > poll imaps.dom.tld proto POP3 > user "u...@dom.tld" pass "xx" preconnect "date >> ~/fetchmail.log" > ssl > fetchall > keep > no rewrite > mda "/usr/bin/procmail ~/.procmailrc"; > > # cat .procmailrc > LOGFILE=procmail.log > VERBOSE=yes > :0 > * ^Message-ID: \/.* > #| /usr/bin/curl http://mail.dom.tld/script.php?messageid=$MATCH > | echo "whoami" > test.txt > > > This work fine when calling fetchamil as root with "fetchamil -f > .fetchmailrc". But when calling fetchmail from a dedicated user, the > external script in procmail is not called. It's written in the logfile that > : > > procmail: [25332] Mon Jun 19 16:20:28 2023 > procmail: Assigning "MATCH=" > procmail: Matched "<9088600d-446a-96b4-4043-29ecd0d5a...@dom.tld>" > procmail: Match on "^Message-ID: \/.*" > procmail: Assigning "LASTFOLDER= echo "whoami" > test.txt" > Subject: test > Folder: echo "whoami" > test.txt > 1824 > procmail: Executing " echo "whoami" > test.txt" > > but nothung happens. > Am I missing something ? > Regards > Cédric Are you sure that procmail is running the command in a shell? Could it be trying to execute a program named 'echo'. You might try creating a shell script you can call. -- Joel Roth
Re: FOSS tool to do general stats from text indata
On Fri, Jun 23, 2023 at 10:20:50PM +0200, Emanuel Berg wrote: > Is there a CLI and FOSS tool that creates stats from text > indata - e.g., > > $ txt2stats path/to/indata/*.txt > > I mean a general tool, but with options to tweak the report > included, of course. > > To produce neat stats, maybe even figures, and generate fun > facts of the kind > >The longest word that occurs more frequently than 0.01 ... > >The most common words to start a sentence ... > >Average paragraph length ... > >And even more crazy facts and stuff that you never think >about until the stats tell you! > > What do we have on that area? A basic search finds this web tool: https://www.usingenglish.com/resources/text-statistics/ Otherwise, I think you'll have to write your own -- or hire someone (like me :^) to write one for you. -- Joel Roth
Re: Recommended editor for novice programmers?
I'm dropping in late to say that running 'vimtutor' in a terminal is an easy way to interactively get to know how vim works. -- Joel Roth
Re: Rsync
Brian wrote: > I would take "base system" to mean what the installer means by it. In > which case, it is should not be associated with "standard system > utililites". They are different sets of packages. Generally it is up to the author of a liveCD distribution to include packages relevant for utility use and I think it's fair that the net installer focus on minimizing its own requirements. Equally, rsync is small, useful, and comprehensible, IMO a good target for teaching the command line literacy. cheers -- Joel Roth
Re: No Sound - Puzzle
A lot of folks (myself included) manage just fine without pulseaudio. ALSA is already complicated and capable enough for them. Some sophisticated users route pulseaudio through JACK, so that the pulseaudio daemon doesn't grab exclusive use of the ALSA device. Good luck! On Wed, Nov 15, 2017 at 06:21:07PM -0500, Thomas George wrote: > From a terminal run alsamixer, f6, select Xonar DSX > > On another terminal cd to a directory of ogg files, start a playback of a > file. > > Oh the desktop start pulse audio volume control. Monitor shows strong active > playback levels > > Switch to terminal running alsamixer, mute master front which mutes all > output channels. > > Return to desktop pulse audio volume control, monitor continues to show > strong active playback levels even though alsamixer thinks all output > channels muted! > > The music goes down and around and comes out nowhere! > > > On 11/15/2017 03:35 PM, Thomas George wrote: > >I just installed an Asus Xonar DSX pcie card. Alsamixer recognizes it and > >PulseAudio Volume Control show a strong signal level during playback but > >no sound from the speakers. The system works with the onboard Nvidia > >sound, no problems. > > > >I assume the problem is a missing linux driver for the Xonar but I have > >seen claims that Xonar works out of the box on linux systems. > > > >Does anyone have this working? > > > >I am using Debian Stretch. > > > > > > > -- Joel Roth
Re: Challenge to you: Voice your concerns regarding systemd upstream
issues as an assumption, if not specifying them directly. Which is very ironic. > Linux does indeed run the majority of the > web servers, so consider that if every major Linux Distro is working in > concert for a change, there has to be compelling reasons behind it, and that > we may not be privy to their reasonings for security's sake. If we can't read the code, we have problems. Linus himself told us that it is not safe to depend on him to warn us about intentional backdoors, but if we want to be able to get the warnings he and other developers want us to get, we have to be able to read the code. > The Net has > been proven to be as secure as Swiss Cheese lately, and that makes Linux > look very bad, if not half-assed. The essential nature of the net has not changed. That was why Microsoft's decision, in the mid-nineties, to start "enabling" their "Windows OSses" for the internet before they had properly secured both of them, and the repeated choice of features before security at the applications level was tantamount to criminal negligence. The fact that the monopoly suits ignored that negligences is evidence of either incompetence or collusion. I used to thing that the problem was judges and lawyers who didn't understand the tech. Groklaw was one of the things that taught me the reality: The industry itself was in collusion. And it still is. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ipxh644mzhaadcusby6xcpapk_3xyhr46mwttup_hk...@mail.gmail.com
Re: Suggestions? A small webserver for file upload
On Wed, Sep 24, 2014 at 10:53 PM, Ron Leach wrote: > List, good afternoon, > > What package would list members suggest for a small webserver that would > enable co-workers to upload files to us? > > We exchange files with people we work with through email and attachments - > that normally works well. During a recent weekend, a co-worker's email > service failed and we were unable to receive several files. Fortunately, > their email outage was repaired in 6 hours so we didn't lose too much time. > During the outage I did look around for possible solutions and determined > that we'd prefer to have: > > (i) our own webserver, preferably simple to set up and operate > (ii) able to present a few simple unscripted 'about us' type of pages > (ii) a file upload facility, but with some important (to us) restrictions, > including: > (a) access for upload only after entry of pre-assigned username and > password > (b) file upload into a nominated-by-us directory by that logged-in user, > and with write-only permissions, if that were possible, so that any access > breach through another method would not enable access to any uploaded files > (c) access by us to all uploaded files, for inspection and subsequent > transferring to appropriate file-system users or directories > (d) file upload facility to be able to be disabled by us - this would be > the normal state - and enabled solely on emergency occasions such as > counter-party email failures Are you sure you want an http server? Most ftp servers provide one index page per directory. Also, while they don't do all the url handling that http servers do, they can server simple html documents with no problems. ftp can handle authentication and use unix file permissions to provide write-only access for some users and full access for others. You can also prevent ordinary login for specific user accounts while allowing ftp for those accounts. There are numerous gui ftp clients to simplify both uploading and downloading. For downloading, most web browsers access ftp servers pretty much transparently. If you have heard that ftp transmits passwords in the clear, you can set them up not to. As another option, ssh access would also be a way to provide this kind of functionality with greater security, hiding not just the passwords, but the data transferred, as well. openssh provides sftp access, and I think there is at least one gui client somewhere, for file access. For the web pages, you'd need to set up an http server, as well, and I might suggest that it's a good idea anyway. It looks like you have some experience with that, so it shouldn't be a problem. As a third option, if you want to go all http, look at webdav. I personally thing webdav is overkill, but you might not. > As I understand it (I've previously prepared a few simple webpages so have a > rudimentary understanding of HTML) we would need a script to perform the > upload. A package that provided some scripting ability would be helpful, > most especially if the package documentation would also cover the scripting > aspects, that would be very helpful. Though there are alternative > well-known methods of providing remote file upload, most of our co workers > are using Windows systems equipped only with a browser and some office > suites. We do not want to enable SSH logins (the co-workers probably do not > have access to, nor know how to use, SSH; neither do we want to employ FTP > because of both the large number of inbound ports that may have to be > opened, and (again) possible difficulties for co workers in establishing an > FTP link from their Windows system, especially when behind a > partially-restricted FW and NAT. Email works well for them, and so does > http. Oh. Well, look at webdav. This is something regularly done with webdav. But I really think you should give both ftp and ssh a closer look. You can get ftp clients for MSWindows, of course. If you have firewall and NAT problems, think of it as a learning opportunity that will save you trouble in the future. I'm not sure whether you can get a graphical client for ssh file access for MSWindows boxes, but it's worth a look. > We have a couple of Debian machines we could run this application on, Wheezy > and Squeeze. What would people's preferred webserver package be for this > type of application? Not sure why you wouldn't want to use apache or lighttpd. -- Joel Rees Computer store is just fancy paper, the CPUs just fancy pens. All is text, streaming forever from the past into the future. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ioevwfws2kgdeifn9cdohy-rhgpar-lcop+a_dvsn7...@mail.gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ric Moore wrote: > Change is certainly needed when any pimple face kid can edit and hide his > doings from a text log with nano. I think the change is necessary to harden > up our systems. Otherwise, Microsoft will become the only secure server OS, > as they don't mind hiding things at all. > > Yes, it is a work in progress, but I think the main goal is signed binaries > that discourage the Black Hats ...at least for awhile. What is telling is > that no one is talking about that. Linux does indeed run the majority of the > web servers, so consider that if every major Linux Distro is working in > concert for a change, there has to be compelling reasons behind it, and that > we may not be privy to their reasonings for security's sake. The Net has > been proven to be as secure as Swiss Cheese lately, and that makes Linux > look very bad, if not half-assed. > :/ Ric Hi Ric, In my opinion, giving PID 1 to a large, complicated and unproven framework constitutes the greater security risk. Compared to sysvinit, systemd presents a huge attack surface that is difficult to audit and includes ample opportunity for security holes, accidental or otherwise. Any new technology of that scale is bound to face security issues. Many people, including desktop users, would prefer not to carry the inevitable risks of being an early adopter. Also obfuscated logfiles hardly seem like a major security innovation. Is this approach described or analyzed in security literature? In any case, I think logging belongs to a different domain than system initialization. Regards, Joel -- Joel Roth -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927003635.GA9031@sprite
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sat, Sep 27, 2014 at 8:08 AM, Ric Moore wrote: > On 09/26/2014 05:08 PM, green wrote: >> >> Ric Moore wrote at 2014-09-26 14:18 -0500: >>> >>> Change is certainly needed when any pimple face kid can edit and hide his >>> doings from a text log with nano. I think the change is necessary to >>> harden >>> up our systems. Otherwise, Microsoft will become the only secure server >>> OS, >>> as they don't mind hiding things at all. >> >> >> So, all other things being equal, binary logs are more secure than >> plain text logs. Is that actually what you are saying? > > > Yes. The benefit of using a binary log is the lesser vulnerability to an > external attack from an intruder. So attackers have access to pico but not hexedit? Editing log files with hexedit is not that much of a skill level above pico. Of course, dealing with checksums is a minor skill level above editing, likewise timestamps, but neither of those are made more or less difficult by making format binary or plaintext, at least not for the unskilled intruder. Some skilled intruders have said binary is actually easier, but they assume their bots carry certain tools with them. > That huge security flaw was mentioned on a > recent PBS video PBS? Well, okay, PBS is better than many commercial news sources, but surely you were aware of the problems before you saw that video? > regarding the new day Hackers and how simply they > removed/edited text-log files to hide their tracks of what they did. Have you never practiced this on your own system, just to get an understanding of where to find telltales or (better) how to set up whatever program you use to check for modified logs? > When I saw that mentioned the light bulb went off, since every major > commercial server distro has already changed over. And you complain about jumped-to conclusions of people who see conspiracies. Considering all the things that are happening at once, it's as easy to conclude a malevolent conspiracy as a beneficial one. But that's all not really relevant. Look at the tech itself. > So, on that point alone, > I'm switching our Debian Wheezy Proxmox cluster servers to systemd, toot > sweet. I guess that means I'll have to get some more edumaction. edumaction? I saw that and checked the headers, because what you are writing here seems a bit out of character. If this is a spoof, the headers are done better than I want to bother checking, unless you tell me so. > I'm also making the positive assumption that there may be something going on > above our pay grades. This might indicate a fundamental difference between you and me. > I find that more comforting than all of the wailing > and gnashing of teeth. I gave up on comfort long ago, perhaps a bit before I recognized that most people aren't out to get me, either. Fortunately, there are some people willing to help each other in the world, if they can. Unfortunately, there are others willing to take what they can for their own gain, if they think they can hide their actions. Higher pay grade seems to favor the latter at least as much as the former, over all. > Keep in mind that the NSA wouldn't sign off on > RedHat's use of systemd if it made a server less secure. Less secure against whom? Remember Clipper? > I tend to think > that they may have a hand in it's development. :) Ric I find neither comfort nor threat in that thought at this point. Business as usual. But I am not planning on using systemd on any box I plan to access my bank from, if I can help it. People going bad in the NSA may or may not be as rare as people going bad in the banks, but it is not just the NSA I'm worried about. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imiof+n7yqm9wbrtx6qbhljmnfdq3o4049hjoyp4n5...@mail.gmail.com
Re: Suggestions? A small webserver for file upload
2014/09/28 0:06 "Ron Leach" : > > On 27/09/2014 15:35, Miles Fidelman wrote: >> >> Joel Rees wrote: >>> >>> On Wed, Sep 24, 2014 at 10:53 PM, Ron Leach wrote: >>>> >>>> List, good afternoon, >>>> >>>> What package would list members suggest for a small webserver that >>>> would >>>> enable co-workers to upload files to us? >>>> >>> Oh. Well, look at webdav. This is something regularly done with webdav. >>> >> >> That's precisely what WebDAV is for - and it has the advantage that >> client support is pretty widely available (built into Windows, MacOS, >> readily available for linux). >> >> Server support is a bit harder to find. There's an apache module. But >> it might be easier to simply set up a subversion server - it comes >> with a built-in WebDAV server: >> apt-get install subversion >> plus some configuration. >> > > I don't know anything about WebDAV - I had seen reference to it in the context of shared diaries/appointments, I think, such as corporates use with their MS Outlook/Exchange systems. Both this suggestion of subversion, and another poster's suggestion of using a wiki, are new to me for this application, and I'll check them both out. > CGI, webdav, and subversion are underpinning technologies at different levels that are often used in wikis, blogging engines, and other sharing/authoring systems. You can use them directly or just use the larger, more functionally complete packages. Considering that bash is one of the interpeters used by CGIs, the posts you may have noticed about the recent vulnerabilities are something you should read for reference. All interpreters have weak spots, and these packages all use interpreters. > Several folk offered various webservers and, though I am sure those will work, apache and lighttpd being two well-known ones, when I looked around for CGI (or perl, apparently) scripts there were plenty of 'free' examples but I've nowhere near enough experience to take scripts off the web (and check that they are secure) for a file upload of work-related files. I didn't find any 'CGI for dummies' sort of sites, either. I'm hoping that subversion or a wiki may solve my need. > At least, set up a private network, either not connected, or carefully firewalled, to practice on, whether you try for a low-level solution or higher level solution. Keep that separate practice network after you go live, or you will be hating life sometimes. > And thanks, of course, to everyone who - very strongly, for good reasons - recommended ftp and SSH but my co-workers really are locked down to email, http, and https, and their IT systems are configured to bar installing of arbitrary software. (Apart from that, while they are perfectly competent in their work subjects, they are not in the least technical or geeky.) > Management needs to be apprised of the different kinds of impact that the different solutions have, and I would strongly suggest that they consider that solving these problems in stages is safer than suddenly deploying, say, Wordpress. You'll end up installing client software anyway, so they may prefer to bite the bullet now, harden the network, and start installing graphical ssh clients. Not allowing an ssh client to be installed on workstations is clear indication that the network has not really been hardened. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
funny text in bash history
Booted this morning, started my usual pattern of bringing the appropriate apt-get commands up from history. (I'm lazy, okay?) Had a bunch of unicode proxies and a reference to a backup directory that I haven't accessed in several months in my most recent three lines, then the history that should have been there. I can suppose that the arrow keys got accidentally pushed and brought up some really old line of history, but I'd like to hear if anyone else has seen history strangeness in the last several days. No time right now, so I shut it back down. I'll boot the rescue partition with the box off-line tonight and check things carefully. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Let's have a vote!
2014/09/28 7:33 "Ric Moore" : > > On 09/27/2014 02:49 PM, lee wrote: > >> Darac Marjal writes: >> > >> > It's a personal choice. If you require a crowd of support as moral >> > justification you're doing it wrong. >> Just ask yourself: Why would someone choose to download an ISO for >> Debian? > > > For me, it's the safest way to install/upgrade. I have had too many problems with interrupted live major migration to the next release level via an upgrade, or a live network total install. Owell, I'm not huge fan of cloud based services either. :) Ric > I think you missed Lee's point. Moral justification is not the only reason to want people to work together with. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: funny text in bash history
2014/09/28 20:17 "Cindy-Sue Causey" : > > On 9/27/14, Joel Rees wrote: > > Booted this morning, started my usual pattern of bringing the appropriate > > apt-get commands up from history. (I'm lazy, okay?) > > > > Had a bunch of unicode proxies and a reference to a backup directory that > > I haven't accessed in several months in my most recent three lines, then > > the history that should have been there. > > > > I can suppose that the arrow keys got accidentally pushed and brought up > > some really old line of history, but I'd like to hear if anyone else has > > seen history strangeness in the last several days. > > > I do A LOT of computing from terminals... and use arrow up and down > ALL THE TIME.. Autocomplete would so ROCK! Heh. Yeah, I have avoided autocomplete, in general, until this last year. Hitting tab on an empty command line turned me off when I first discovered it. Prefer globbing (shell regular expressions). Lately I seem to have a bit more trouble remembering what's in the path globbing will see, so I get lazy and use completion sometimes. > My history is inconsistently reflected because I open SO MANY windows > all day every day.. The most recent history that comes up seems to > depend on what terminal was closed last during the last session.. That's not the kind of funny text I'm talking about. I'm talking about things I've never typed at the comand line in any shell window I've opened logged in as that user, and unicode proxies I haven't seen in a shell window in any Linux I've used in more than ten years. > But that's every day, that's not *months* worth so it's not really any > help in your case.. Still thought I'd mention it with the thought > being it might help ease someone's mind out there as you discuss > what's going on with yours.. :) Thanks for the thoughts. :-) > Cindy > > PS A little tip: For anyone who hasn't discovered it yet, CTRL+SHIFT+T > is a keyboard shortcut to bring up a terminal in some Debian based > distros out there. > > -- > Cindy-Sue Causey > Talking Rock, Pickens County, Georgia, USA > > * runs with duct tape *
Re: funny text in bash history
2014/09/28 20:40 "The Wanderer" : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/28/2014 at 07:17 AM, Cindy-Sue Causey wrote: > > > On 9/27/14, Joel Rees wrote: > > > >> Booted this morning, started my usual pattern of bringing the > >> appropriate apt-get commands up from history. (I'm lazy, okay?) > >> > >> Had a bunch of unicode proxies and a reference to a backup > >> directory that I haven't accessed in several months in my most > >> recent three lines, then the history that should have been > >> there. > >> > >> I can suppose that the arrow keys got accidentally pushed and > >> brought up some really old line of history, but I'd like to hear > >> if anyone else has seen history strangeness in the last several > >> days. > > No, can't say that I have. I'm guessing that something has messed with > your ~/.bash_history file, but I can't think what might do it in that > way. And I'm a little worried about what would have done the messing. This happened just after updating for the recent vulnerability. [...] Doesn't look like anyone else is seeing this at this time. For the time being, that box is off-line. I'm doing post-mortem *practice* on it as I have time, just in case. Hoping I can tie it into something reasonable, like me dozing at the keyboard. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: systemd and server use
2014/09/29 23:21 "green" : > > Steve Litt wrote at 2014-09-28 22:04 -0500: > > On Sun, 28 Sep 2014 18:10:52 -0500 green wrote: > > > Microkernels, as I understand, aim to support a highly modular system > > > *design* but are themselves minimal (Minix 3 has about 4000 lines of > > > executable kernel code). This "core code" can be more easily audited > > > and maintained. Servers, eg. device drivers, are supervised and can > > > not bring down the system (in the context of the kernel). (See > > > <http://www.minix3.org/other/reliability.html>.) > > > > > > So yes, perhaps one major reason some people dislike systemd (too much > > > "core code") is the same reason some people like the microkernel > > > design. > > > > I don't think anyone had a problem with the concepts around > > microkernel. The problem is that nobody in the Free Software community > > could write a decent microkernel. > > NetBSD's "anykernel" and DragonFlyBSD's "hybrid" kernel designs could > be considered at least to incorporate parts of the microkernel design. L4, among others. It's worth looking at wikipedia's article on microkernels for starters, if you're interested in the subject. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Let's have a vote!
2014/09/30 20:24 "Miles Fidelman" : > > Mart van de Wege wrote: >> >> lee writes: >> >>> Stephen Allen writes: >>> >>>> So, Lee why are you even here complaining about Debian - You've admitted >>>> you don't use it?! >>> >>> My server runs on Debian. So technically, I'm using it, and I don't >>> feel like I'm using it. >>> >>> What difference does it make? Is there some sort of social contract you >>> need to sign which forbids you to mention any disadvantages Debian might >>> have and only allows you to praise its advantages? >>> >> No, but there is some sort of social contract that says that fouling up >> a mailing list with pretty much the same whine every post is just plain >> rude. >> > > And does that apply to folks who use every post to whine about topics they don't want other people to talk about? > Thank you, Miles. Although I'm afraid those who have been whining about the anti-systemd noise won't really be able to see that that is what they've been doing. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Fwd: Re: cron in UTC?
2014/09/30 21:41 "Henrique de Moraes Holschuh" : > > On Tue, 30 Sep 2014, Tony van der Hoff wrote: > > On 30/09/14 11:57, Henrique de Moraes Holschuh wrote: > > > On Mon, 29 Sep 2014, Don Armstrong wrote: > > >> On Mon, 29 Sep 2014, John Hasler wrote: > > >>> Tony van der Hoff writes: > > >>>> Believe me; I've beaten that man to death, but not found the answer. > > >>>> Perhaps you'd like to give a more detailed pointer into that manual? > > >>> > > >>> See the part about setting environment variables. You should be able to > > >>> set TZ=UTC . > > >> > > >> This sets the environmental variable for the shell forked by cron, but > > >> doesn't change the environmental variable for evaluating the crontab > > >> time specifications. [It's probably past time for cron to be replaced > > >> with fcron or similar, but cron+anacrontab seems to work well enough for > > >> most people that it hasn't happened. fcron used to be in Debian, but got > > >> removed because it was unmaintained in Debian (and upstream at the > > >> time).] > > > > > > I used to maintain fcron in Debian, however SELinux support was not upstream > > > yet, broke, and I had no time to fix it. Russell Coker tried to help giving > > > me an account on a SELinux box, but the real problem was that more human > > > power was needed, and the RFH bug received no response. > > > > > > So I ended up agreeing that it should be removed, because the package was > > > bitrotting fast. > > > > > > Reintroducing fcron in Debian will require some work to be done properly, > > > and past history tells me to not do it at all unless we have at least > > > *three* people willing to enter team maintainership commited to the effort. > > > > > > upstream is friendly, but fcron is in maintenance mode. If you want > > > anything done, you will have to write the code and submit upstream. > > > > I've just cloned the repository from upstream; it looks sensible, so if > > you're willing to coordinate it, I'm willing to devote some time to help > > maintain the Debian effort. > > I could do not much more than coordinate it at this point, so I suggest we > find a third person before any uploads are done. > > You'll want to get the last Debian fcron package to inspect the local > changes and parametrization, some of it will have to be modernized and > forward-ported to recent fcron. > > http://snapshot.debian.org/package/fcron/3.0.1-1.3/ > > We'll have to dig out the old bug reports from the BTS as well, some of them > have to be addressed before the package is reintroduced to unstable. > Unfortunately, since the bugs were "auto-closed" by the fcron removal, we > have to go over all of them and reopen those that would still apply. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=fcron;dist=unstable > Should I use this as my excuse to actually join the dev team, in spite of my misgivings about systemd and the API creep? Is your third going to need to run jessie with systemd? How much and what kind of hardware/OS resources does he or she need to be able to bring to the table? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Fwd: Re: cron in UTC?
2014/10/01 21:29 "Henrique de Moraes Holschuh" : > > On Wed, 01 Oct 2014, Joel Rees wrote: > > Should I use this as my excuse to actually join the dev team, in spite of > > my misgivings about systemd and the API creep? > > Only if you promisse me you are never going to mention systemd again on the > communication threads where fcron work is taking place, except for the bare > minimum actually related to fcron. Heh. No, that wouldn't really be a problem. > It will need a service file and an > initscript because it has to be started on boot by both systemd and > sysvinit. > > What is a lot more troublesome is that someone in the team will need to test > it SELinux mode. And if Debian ever adds AppArmor, fcron will have to > interface to it as well. cron-like daemons are security-sensitive packages. > > > Is your third going to need to run jessie with systemd? How much and what > > kind of hardware/OS resources does he or she need to be able to bring to > > the table? > > You will need an unstable chroot, and you must test the packages there, as > that's the maint target for integration. This doesn't mean your main system > must run unstable. IME chroots and VMs are enough to deal with this. > > And yes, it has to be tested with systemd and sysvinit, in both cases with > SELinux enabled. There's the real problem, and the one that has stopped me in the past -- hardware to set up the dev and test environments. The hardware I have might be able to handle chroots, but it won't do VMs. Too old. Guess I was thinking maybe there would be something I could do in an alternate boot partition on an older 32 bit machine. I have to do something about my hardware, but I don't have the extra money at this point. > So, it is a reasonable amount of work to do it properly. THIS is why I am > very upfront about the fact that it needs several maintainers with time to > spend on it, and that I won't be able to do much other than coordinate right > now. > > We can very reasonably expect the time sink to get a lot better after the > package shapes up, as fcron development is slow (and it looks like it has > picked up some, so it is out of maintenance-only mode!). It is also pretty > clear we have to track upstream development closely, and cherry-pick patches > from the ML. > > However, I do recall that maintaining fcron packages was a lot of fun. Yeah. > You > *really* grow as a maintainer when you take care of something like that. > And fcron is a real cool piece of software, although I expect that other > rather nice vixie-cron replacements must have matured in the last 10 years, > so it would also make sense to check the competition first, before spending > a lot of maintainer resources to reintroduce fcron in Debian. Well, maybe some one on the user list with more free resources than I could get up for some fun. Joel Rees
Re: Data from a serial port
On Sat, Oct 4, 2014 at 5:52 AM, Jerry Stuckle wrote: > On 10/2/2014 8:24 PM, Ethan Rosenberg wrote: >> [...] > > In addition to Dan's comments - is your cable OK? Do you need a > straight-through cable or a cross-over cable? Does the terminal > require/honor DSR/TSR and RTS/CTS? If so, are these lines active? > > You may need a breakout box on the cable to see what's happening on the > lines. If, for some reason, you can't get a breakout box, you may be able to do basic tests on the cable with a multimeter (ohm-meter or connectivity function), the pin diagrams, some patience, and maybe an extra pair of hands (if you can't find small-mouth alligator clips or pin clips). Just don't tell whoever handles requisitions/budget unless they understand that patience costs time and money when doing things like this. You have to be really careful to keep the leads from slipping, and not noticing a slipped lead can cost hours of unnecessary work.And there are tests you really don't want to try without a breakout box or the equivalent. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iohya7gjhudkv+me16soneuhpnbzptlbwtcbv_bzjq...@mail.gmail.com
Re: Data from a serial port
On Sat, Oct 4, 2014 at 9:54 AM, Jerry Stuckle wrote: > On 10/3/2014 8:19 PM, Joel Rees wrote: >> On Sat, Oct 4, 2014 at 5:52 AM, Jerry Stuckle wrote: >>> On 10/2/2014 8:24 PM, Ethan Rosenberg wrote: >>>> [...] >>> >>> In addition to Dan's comments - is your cable OK? Do you need a >>> straight-through cable or a cross-over cable? Does the terminal >>> require/honor DSR/TSR and RTS/CTS? If so, are these lines active? >>> >>> You may need a breakout box on the cable to see what's happening on the >>> lines. >> >> If, for some reason, you can't get a breakout box, you may be able to >> do basic tests on the cable with a multimeter (ohm-meter or >> connectivity function), the pin diagrams, some patience, and maybe an >> extra pair of hands (if you can't find small-mouth alligator clips or >> pin clips). Just don't tell whoever handles requisitions/budget unless >> they understand that patience costs time and money when doing things >> like this. You have to be really careful to keep the leads from >> slipping, and not noticing a slipped lead can cost hours of >> unnecessary work.And there are tests you really don't want to try >> without a breakout box or the equivalent. >> > > Why couldn't he? They're cheap, i.e. > http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_14285_-1. > > Note if he's using DB9 connectors he would need a pair of DB9-DB25 > connectors. But they are also cheap. Uhm, maybe he has a multimeter now, and doesn't want to wait for overnight shipping or take the time to run down to a supply house downtown or even wait for said supply house to do a same-day delivery. Or maybe finances at the company are really, really tight right at the moment. Now, of course, if the supply house is next door, and his company is okay with people bringing in tools paid for out-of-pocket, going and getting it would be a good excuse to take a half-hour break anyway (assuming no lines at the supply house). My point was simply that connectivity checks don't need a breakout box. Breakout boxes do make them more convenient, and quicker, and give more reliable results. Not to mention enabling more in-depth testing, especially if you have an oscilloscope with data capture. I'm not arguing with you on this one, Jerry, I was just offering an alternative. Not a great alternative, but maybe a useful one. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iplxkijivltwizuhnrb+errmehz_6r56wmliwgz7oa...@mail.gmail.com
Re: Data from a serial port
On Sat, Oct 4, 2014 at 11:05 AM, Jerry Stuckle wrote: > On 10/3/2014 9:52 PM, Joel Rees wrote: >> On Sat, Oct 4, 2014 at 9:54 AM, Jerry Stuckle wrote: >>> On 10/3/2014 8:19 PM, Joel Rees wrote: >>>> On Sat, Oct 4, 2014 at 5:52 AM, Jerry Stuckle >>>> wrote: >>>>> On 10/2/2014 8:24 PM, Ethan Rosenberg wrote: >>>>>> [...] >>>>> >>>>> In addition to Dan's comments - is your cable OK? Do you need a >>>>> straight-through cable or a cross-over cable? Does the terminal >>>>> require/honor DSR/TSR and RTS/CTS? If so, are these lines active? >>>>> >>>>> You may need a breakout box on the cable to see what's happening on the >>>>> lines. >>>> >>>> If, for some reason, you can't get a breakout box, you may be able to >>>> do basic tests on the cable with a multimeter (ohm-meter or >>>> connectivity function), the pin diagrams, some patience, and maybe an >>>> extra pair of hands (if you can't find small-mouth alligator clips or >>>> pin clips). Just don't tell whoever handles requisitions/budget unless >>>> they understand that patience costs time and money when doing things >>>> like this. You have to be really careful to keep the leads from >>>> slipping, and not noticing a slipped lead can cost hours of >>>> unnecessary work.And there are tests you really don't want to try >>>> without a breakout box or the equivalent. >>>> >>> >>> Why couldn't he? They're cheap, i.e. >>> http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_14285_-1. >>> >>> Note if he's using DB9 connectors he would need a pair of DB9-DB25 >>> connectors. But they are also cheap. >> >> Uhm, maybe he has a multimeter now, and doesn't want to wait for >> overnight shipping or take the time to run down to a supply house >> downtown or even wait for said supply house to do a same-day delivery. >> >> Or maybe finances at the company are really, really tight right at the >> moment. >> >> Now, of course, if the supply house is next door, and his company is >> okay with people bringing in tools paid for out-of-pocket, going and >> getting it would be a good excuse to take a half-hour break anyway >> (assuming no lines at the supply house). >> >> My point was simply that connectivity checks don't need a breakout box. >> >> Breakout boxes do make them more convenient, and quicker, and give >> more reliable results. Not to mention enabling more in-depth testing, >> especially if you have an oscilloscope with data capture. >> >> I'm not arguing with you on this one, Jerry, I was just offering an >> alternative. Not a great alternative, but maybe a useful one. >> > > If his company cannot afford $9.95 + shipping for a breakout box, then > that company is in deep crap anyway. That's not the only possibility I mentioned, but I have worked for such companies in the past. (Twice.) Whether my reasons for not bailing immediately were valid or not is not something I care to dredge up. Come to think of it, I have also worked for companies where requisitions seemed to be on greased rails, and found out the hard way the problems you can buy yourself when you get lots of tools you don't know how to use. > And if he's a consultant and can't > afford the basic tools to do his job, he shouldn't be in the business. > And he's already worked on this much more than overnight (or even > second-day) delivery would have caused a delay. And maybe he would rather order a breakout box now, but still spend fifteen minutes doing things the hard way, so that when the breakout box comes he can be pretty confident about which end of the cable he wants to hang it on to start with, and what extra test data he wants to try to push down the pipe. > An oscilloscope (with or without data capture) is much more expensive, > and still can't monitor all of the lines concurrently - at least unless > you have an 8 channel scope (*very expensive*). And a multimeter will > work for one wire at a time - if you have access to the lines. And having a breakout box (or two, even) can help make the signals available if he decides he wants to look at waveforms. Even a single channel with trigger will allow you to get a llook at a byte of data going one direction, or watch a handshake line that you might suspect of being intermittent or having impedance problems. Or check that when you tell the system to use handshake, it really does. But, yeah, fo
Re: Debian policy on alternate init systems
2014/10/04 17:30 "Curt" : > > On 2014-10-03, berenger.mo...@neutralite.org < berenger.mo...@neutralite.org> wrote: > > > > > > I like this one, because it makes me smile. I like pieces of softwares > > with "play on words" (this translation sounds strange... is it the > > correct one?) > > It's the correct one (jeu de mots). also known as "pun". > > Oh, and apart from that, for people (if there are some here) which > > thinks that systemd's attempt to simplify daemon scripts is interesting, > > But as I pointed out long ago systemd itself is a play on words (le Système > D). > > http://en.wikipedia.org/wiki/System_D Ergo, calling themselves hackers. > Donc, démerde-toi. > > ;-) Hmm. Should that be translated to English as "So make do with yourself." or "Manage yourself." or "Hack yourself."? :-/
Re: Jessie netinstall CD on very limited internet connection.......
On Sun, Oct 5, 2014 at 12:46 PM, Charlie wrote: > > Just curious: > > I used a Jessie netinstall CD, downloaded some time ago, on a > computer belonging to a friend, who has a very limited internet > connection. It gave me an error message after reading the CD and I > think at the step of installing the base system or just before that. > > It was something about not finding any kernel modules probably due to > this version of the installer having the wrong kernel. That's what it > posted on the screen something akin to that anyway. > > I tried to go on, but there were just too many things not right, so > aborted. > > It didn't matter, as I used an early wheezy net installer for a minimal > system, changed the sources list accordingly. It booted, read the > updates for Jessie correctly and now I just have to get it to a better > internet connection and upgrade it, bring in the required packages and > we're done. > > But it was just a weird thing? Why would a net install CD come with the > wrong kernel? Maybe I downloaded it at a time when it was incomplete. Jessie being what it is until it becomes the new stable, I would be less than surprised if I got such errors. It might also be due to errors in the download. Slow connections can sometimes be less reliable -- old equipment, etc., and checksums are statistical objects. > Nothing drastic, but I just wondered. > Charlie -- Joel Rees Free is not Free! Choose your responsibility. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOKsh0XOXxWB+UFZap=N=ywacqyke8p8jn6mqoz7e0...@mail.gmail.com
Re: Jessie netinstall CD on very limited internet connection.......
On Sun, Oct 5, 2014 at 9:31 PM, Chris Bannister wrote: > On Sun, Oct 05, 2014 at 09:51:54PM +1100, Charlie wrote: >> >> As I thought. >> Downloaded on a very fast cable connection and burnt the CD on media >> which has never had any problems on a modern laptop etc., etc.. >> >> Probably, but not certain that I did the checksum confirmation. Sorry, I mis-read that. Thought you had downloaded the netinstall image on the slow connection. >> I thought it was just a glitch because I can't recall anyone ever >> having a problem just like that, but I may not have read that thread. Well, thinking a little harder, it had been some time since the netinstall image was downloaded, so the kernel in the netinstall image was, indeed, not likely to be matching the non-kernel stuff it was finding in the current repositories. If the mismatch were bad enough, it might make sense for the installer to complain. Otherwise, it would need to ask if you wanted to re-load the kernel and other elements of the netinstall image from the web instead of proceeding with the stuff from the CD, or whether you had a substitute repository that matched the kernel it was using for the install. >> Thanks for your time to reply. If it helps more than hinders, you're welcome. > If you think you have found a problem, then as a user of testing you > should report it. You may have found an obscure bug which should be > fixed *before* Jessie becomes the new stable. > > As users of testing, we should take a more active role with regards to > bugs, after all one of the reasons to run testing is to help make the > stable release as bug free as possible. Chris, I'm not understanding your reasoning here. Are you thinking he should be considering the possibility he's been hit by a MITM or something? Do you want him to try to roll back the testing repository or a mirror so he can do a full binary compare? -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPM5z0e5eM6W7wcV9kRx_L5Cd-CSbhytjHmueL=x2c...@mail.gmail.com
sock puppets (Re: (Song) ** SystemD)
On Sun, Oct 5, 2014 at 7:54 PM, Chuck Ebbert wrote: > On Sun, 5 Oct 2014 10:29:24 + > Gregory Smith wrote: > [...] Chuck, Al, anyone else paying attention to "Gregory" or "Tom Collins" or whatever he's calling himself -- I'll repeat what I posted to debian-user, but this is quite apparently a sockpuppet, either engaging in recreational trolling, or trying very hard to make it impossible to discuss systemd with any semblance of rationally. It seems to be hard enough for the more avid of both the proponents and opponents to be rational as it is, let's try not to get sucked into this kind of baiting. (Speaking as one who got a little bit sucked into it last week or so.) -- Joel Rees Computer storage is just fancy paper, the CPUs just fancy pens; all is text, streaming forever from the past into the future. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imnonrlamgergaxgazo-dvppmefusk5rhjnqxz1-6x...@mail.gmail.com
Re: Jessie netinstall CD on very limited internet connection.......
2014/10/06 10:44 "Chris Bannister" : > > On Sun, Oct 05, 2014 at 10:34:57PM +0900, Joel Rees wrote: > > > > > If you think you have found a problem, then as a user of testing you > > > should report it. You may have found an obscure bug which should be > > > fixed *before* Jessie becomes the new stable. > > > > > > As users of testing, we should take a more active role with regards to > > > bugs, after all one of the reasons to run testing is to help make the > > > stable release as bug free as possible. > > > > Chris, I'm not understanding your reasoning here. > > How do you think bugs get fixed if they're not reported? > What else can you read into the above paragraphs? > > > Are you thinking he should be considering the possibility he's been > > hit by a MITM or something? Do you want him to try to roll back the > > testing repository or a mirror so he can do a full binary compare? > > *WHAT*? I was thinking nothing of the sort. I'm not the person > responsible for producing the netinst image, but if I was that would be > the last thing I'd be thinking --- more likely just a silly mistake BUT > how would I get to hear about it if whomever found the mistake didn't > let me know, *Hrrrmmm*? Okay, looking at the OP's descriptions of the problems, should we ask the OP to go ask the release team whether an old netinstall image for testing should, in general, be able to recover from having the kernel on the CD out of sync with the current repository? And would they like him to image the old netinstall CD and upload it somewhere for analysis? Or would they like him to try to replay the install, maybe from a mirror where they can watch? I don't know how slow the friend's connection is, but unless there were some specific bug I were chasing, I'd hesitate to ask for a replay if it's going to take two of them a good part of a day, and erasing a working system. Especially considering that my record on installs leaves me with about one in five install CDs botched for various reasons. Joel Rees
Re: Jessie netinstall CD on very limited internet connection.......
2014/10/06 12:47 "Chris Bannister" : > > [...] > Jessie is a moving target, I personally would download the wheezy > netinst image and install that. Why does the OP need Jessie which is > uodated constantly when only a limited bandwidth is available? I have to admit, I was wondering that myself, but since he seemed to understand what he was doing in upgrading from wheezy, I assumed he'd understand that Jessie would likely have issues requiring a bit of patience and nursing on a slow connection. Charlie, care to enlighten us? Joel Rees
Re: [exim4] mixed up about terminology
2014/10/06 12:16 "Harry Putnam" : > > Jerry Stuckle writes: > > > The first question - why do you think you need to relay to other > > networks, even if they're your own? Do you have other SMTP servers > > running on those networks? > > Good question and apparently thee is no reason. It stemmed from a deep > seated confusion about what relaying means. All I really want is to > be able to do this: > > On my lan machines: > > HOST-1 > HOST-2 > [...] > HOST-mail-server now being configured > > HOST-[12...N] would have the server host above listed as smarthost in > there respective mail config. > > So they would all be sending mail by way of server host. > > I guess that is not what is meant by relaying? I think that's relaying, but not open relay (if you get it set up right). But you should consider why you want to send out through a central server, unless your firewall is for some reason set up to only allow outbound mail from that server, in which case you probably do want to authenticate on the lan, too. (Think, for example, about the possibility of malware on a local box.) Incoming mail may make sense to cache on a local server. Or maybe not. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Jessie netinstall CD on very limited internet connection.......
2014/10/06 15:13 "Charlie" : > > On Mon, 6 Oct 2014 13:30:32 +0900 Joel Rees sent: > > > > > Charlie, care to enlighten us? > > Thanks for your time with this. > > Joel I think you're right. I just didn't understand the way that the > netinstall CD's work. The disk or rather the installer was too old. Maybe. The question being whether it's worth replaying an install to be sure that was the only problem. If you'd had such a problem with the wheezy installer, the devs would probably like to at least know about it. And you might want to check with the guys who make the CD images about this one, if you don't mind looking for the right mailing list to post to. A casual check of lists.debian.org would suggest the debian-cd , as Chris (I think it was) suggested. >[description of what sounds like reasonably reasonable practice] Keep up the good work, but if you think you've hit a real bug, don't think you don't know enough to file a bug. Look for similar bugs first, ask on the list if you want, but you know enough by now and filing bugs is part of how users support the development effort. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Moderated posts?
As Don pointed out, it's the threads that have been clipped, as it were, not the topics: I think it's probably just as well, as those threads themselves were started by either a sockpuppet or someone who had lost control of himself, and the threads were counterproductive. So I can say, "systemd!" here, And this post will still not be blocked. Joel Rees On lkml, they block html.
Re: Moderated posts?
On Tue, Oct 7, 2014 at 10:28 PM, The Wanderer wrote: > On 10/07/2014 at 02:58 AM, Joel Rees wrote: > >> As Don pointed out, it's the threads that have been clipped, as it >> were, not the topics: I think it's probably just as well, as those >> threads themselves were started by either a sockpuppet or someone who >> had lost control of himself, and the threads were counterproductive. >> >> So I can say, "systemd!" here, >> >> And this post will still not be blocked. > > And that's fair enough in its way. (Though it does unfairly also hit > subthreads which were not on the same topic anymore, but I can see where > trying to be fine-grained enough to comb out one but not the other might > well be more trouble than it would be worth.) > > But it should still be accompanied by a public announcement that such > action is being taken, with at least a vague indication of which > thread(s) are being so filtered - and/or a system of automated replies > (possibly rate-limited to stymie DoS efforts) to any attempt to reply to > such a thread, explaining the situation. > > Doing such moderation silently, without comment or explanation, is just > not cricket. > >> Joel Rees >> On lkml, they block html. > > But do they do it silently, or is there an explanation of why an > attempted post containing such will not be posted? > > If the latter, I think I might actually approve of such a policy... Well, all you get is a generic RFC compliant message from your ISP saying it was rejected, but not really specifically why. IIRC, the FAQ is referenced in the rejection message, so you at least have a clue to go read the FAQ, where, if you read as far as the mailing list guidelines, you see that it says the list is pretty much open if you don't post in html, and html messages are automatically rejected. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOJvKUeO7hjowUSTtOcZ=ujoehzxet82rw3j5mi_tx...@mail.gmail.com
Re: Moderated posts?
2014/10/08 6:07 "Andrei POPESCU" : > > On Ma, 07 oct 14, 12:00:57, Steve Litt wrote: > > > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 > > > > Read ^H^H^H^H skim the thread. Notice how, in the first 10 posts, after > > insisting that alternate inits be part of the discussion, a guy named > > Thorsten Glaser was ordered not to bring up alternate inits in the > > That doesn't match my memory of the entire debate, care to refresh my > memory with a reference? Well, I'll tell you, Andrei. I was raised on the idea that KISS is never an optional principle in engineering, and more especially to be strictly observed when working with anything that has to respond to real-world events in some pre-determined amount of time. Perhaps that point of view colors my interpretation of the conversation in a way different from the way you read or watched it. > > thread again. Again and again, the conversation is steered into the > > most limiting set of alternatives, often trampling on those who say > > "wait a minute, let's consider other things." > > As far as I recall OpenRC was indeed deemed unsuitable quite early, but > this was done on technical grounds (not ready, lack of documentation, > lack of features, etc.). Lack of documentation is one kind of technical ground, I suppose, but it is a completely different topic from deterministic execution paths. Lack of features is not a defect in a pid 1 process. If the traditional sysv inherited inits have issues, pid 1 being too simple is not one of the problems. A good engineer can read code. No amount of engineering magic can read the execution of a pid 1 process that is chasing its tail trying to parse an error state. Pid 1 should never see anything more than three options to an event -- kill, pass it on, or ignore -- and the decision chain should have as few steps as possible, preferably less than three. Otherwise, and it doesn't matter how many processors you have going how fast, you are going to see the system freeze at odd times, punt at odd times, and fail to enforce at odd times, among other issues. And these will be the quiet kind of errors where data gets corrupted and is lost and no one is aware of the corruption until months later, when you really need the data but there is no way to go back and re-build it. Months and data corruption if you're lucky, backdoors never discovered if you aren't. All the fuss about race conditions, all the fuss about logging, the steady absorption of daemons, like cron, that should be separate, etc., all of these are not features. They are symptoms of the failure to keep it simple and avoid trying to make it too smart. If openrc was not ready because of documentation, how can systemd ever be considered ready until pid 1 is stripped down to the bare minimum? Greater than 1M is two orders of magnitude beyond too big. Does that help you see what Steve and others interpret as railroading? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Moderated posts?
On Wed, Oct 8, 2014 at 6:16 PM, Andrei POPESCU wrote: > On Mi, 08 oct 14, 11:41:05, Joel Rees wrote: >> 2014/10/08 6:07 "Andrei POPESCU" : >> > >> > On Ma, 07 oct 14, 12:00:57, Steve Litt wrote: >> > > >> > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 >> > > >> > > Read ^H^H^H^H skim the thread. Notice how, in the first 10 posts, (I'm wondering whether that's the first ten, or the first ten currently visible.) >> > > after >> > > insisting that alternate inits be part of the discussion, a guy named >> > > Thorsten Glaser was ordered not to bring up alternate inits in the >> > >> > That doesn't match my memory of the entire debate, care to refresh my >> > memory with a reference? >> >> Well, I'll tell you, Andrei. I was raised on the idea that KISS is never an >> optional principle in engineering, and more especially to be strictly >> observed when working with anything that has to respond to real-world >> events in some pre-determined amount of time. >> [...(background information that I thought might be helpful, with the >> following quetsion)...] >> Does that help you see what Steve and others interpret as railroading? ... which you also snipped, but then replied: > I was specifically asking about a reference for "Thorsten Glaser was > ordered not to bring up alternate inits...". So, I assume it did not help you see. I think what Steve is talking about may have occurred between https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#20 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#30 but right now I'm only seeing every fifth message, so it's hard to tell. #30 does quote something worded pretty strongly to the effect of "Go make your arguments somewhere else!" however. (Remembering that "please" does not always mean, "if you please".) -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inuvmx2guxxzxozntugszzmbu8fkbvmowgc9sqq+fz...@mail.gmail.com
Re: [exim4] mixed up about terminology
On Wed, Oct 8, 2014 at 9:32 PM, Jonathan Dowland wrote: > On Tue, Oct 07, 2014 at 10:40:28PM -0400, Jerry Stuckle wrote: >> And how can you be positive your network is secure? For instance, you >> don't have a configuration error, a bug in a router, an access point >> with weak encryption... the list of potential holes is almost endless. > > The likelyhood of both one of those scenarios AND a spammer with local access > discovering and exploiting them are rather lower, than the risk of getting > something wrong when setting up SMTP Auth and SSL properly for all current > and future clients on this small home LAN, especially since the OP is not an > experienced administrator of SMTP servers. Using (or abusing, if you insist) > dc_relay_nets for this scenario is entirely sensible advice, IMHO. I dunno. I rather think (not that I'd rather it be so) that you're more likely to have a spammer with local access in the mentioned scenarios than should there be a lack thereof. Configuration is configuration, some may be harder than others, but misunderstanding the configuration invites errors. (I don't see client configuration as being that hard, myself, BTW.) Also, he seems to be talking about VMs as much as (or more than) an actual network with physical boxes on it. 30 VMs, I think he said. So he is going to be getting practice. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iO2q9cCkdgrd+-+T-U2pQt0wGm22gM+_5cWpDSp3oR=m...@mail.gmail.com
Re: mounting local hd from live usb, was 'root account inaccessible'
Does jessie still provide /dev/disk/by-id , etc.? as in ls -la /dev/disk/by-id ls -la /dev/disk/by-label etc.? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
2014/10/09 10:58 "lee" : > > Joel Rees writes: > > >> 2014/09/25 9:15 "lee" : > >> > >>> Joel Rees writes: > >> > >> > >> Hmm. So linkage is a result of complexity, > > > > What is complexity? > > > > Complexity is not a simple topic. :-\ Indeed. And one of the problems with computers is that people want to believe that computers can make complexities go away. Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. > >> and implicity is a result of > >> undeclaredness (or unawareness of declaredness). > > > > Sort of, but not quite. > > > > I would rather say, > > > > Implicitness is the lack of explicit declaration at the point > > where the linkage is expressed (or occurs). > > > > but I'm not sure that would be universally well understood, either. > > So implicitness isn't a result of something but a lack of explicitness. Generally, the things which are implicit are the things which are not said, but assumed to be understood: unspoken assumptions. Logical implication is a different thing, the process of deriving something from assumptions which have to be explicit. The base word "imply" can cause yet another kind of confusion. > Too much explicitness isn't good, either, because it'll get into your > way. Yeah, if you take the time to explicitly specify every parameter, you're going to have a hard time getting started coding. And specifying too many parameters can really slow an implementation down. > You could as well argue that linkage is basically a bad thing and > therefore should only be accepted for instances where it has significant > advantages which outweigh the disadvantages. At least we have a > tautology here. Oh! The problem of evil rears its head in mathematics. ;-/ (sorry.) But the hidden assumption that linkages can be completely done away with is where the logic goes wrong. Remove all externally accessible parameters and you can't even write the algorithm, much less implement it. > > Generally, reducing complexity and reducing linkage are related, but > > not necessarily. The degree to which linkage is implicit, or to which > > entanglement is hidden, is not necessarily dependent on the degree of > > either complexity or linkage. These can be independent variables, > > depending on the case in question. In some cases, you can even make > > them indpendent variables, when they didn't start out that way in your > > analysis. > > Hm, true ... Less linkage is easier to hide than more linkage. It makes > me think of a simple perl script. Such a script probably has an > unbelievable amount of implicit linkage. For example: > > perl -e 'print scalar localtime, "\n";' Well, that indeed illustrates a lot about complexity, and about hiding it, along with the hidden parameters that can turn into implicit linkage. (I'd like to say more about perl, but I don't have time.) > >> Since you cannot make things less complex, > > > > I'm not sure what you're trying to say. > > > > If you know you can make things more complex, you know that there must > > be things that can be made less complex. > > The less complicated things tend to be deprecated and to become > obsolete. Well, the sales crew definitely wants you to believe it. > 25 years ago, computers didn't have sound cards. You could possibly add > one, making your computer more complicated both in terms of total > complexity of hardware and software. Nowadays, a replacement for a > sound card is built in. Making things less complicated would mean to > omit or to remove the sound cards and their replacements. Who wants to > do that? On the one hand, sometimes you do remove most of the sound software, leaving just enough of the drivers to keep the sound card in a safely powered-down state. On the other hand, with sound-on-the-motherboard, many old sound card modes are unsupported. The overall number of externally accessible parameters, and the complexity of interaction of what remains is decidedly less that what all but the cheapest sound cards used to supply. Also, with all the stuff that is on the motherboard, you can often get rid of much of the circuitry that would otherwise drive the external busses, and simplify much of the driver software. You really can't say that progress is linear in the direction of increasing complexity. > > There are several kinds of complexity. > > > > One is purely subjective -- perceived complexity: "It's different, so > > it's complicated." or &qu
Re: Effectively criticizing decisions you disagree with in Debian
2014/10/10 8:47 "Steve Litt" : > > On Thu, 25 Sep 2014 21:27:30 +0900 > Joel Rees wrote: > > > Complexity is not a simple topic. :-\ > > Can I quote you on that? Heh. I was quoting several teachers and co-workers, I don't know if anyone has figured out who said it first. It predates the Greek philosophers, however. 8-) But go ahead, if you think it's a good idea. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: question about systemd
2014/10/10 9:03 "Steve Litt" : > > [...] > LOL, the more people bust old features putting in new features, the > more I kludge. And that sums the entire argument up nicely, perhaps. :-( Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: In Poettering's own words: was question about systemd
Testing, here. Just want to check whether I get filtered out from here, as well. (Two responses to a thread that invites discussion of the /usr merge have not made it to the list yet.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inwe0hv5puqovuakwe0sxtks0qm-xb78k_hlqewwyp...@mail.gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hmm. Let's comment that for people newer to scripting than I am. On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt wrote: > [...] > Daemontools runscripts are incredibly simple shellscripts, that I'm > sure you could write no sweat except in very wierd edge cases. Here's > my run script for my home-grown cron substitute: > > == > #!/bin/sh > > ### DON'T START littcrond UNTIL THE NETWORK'S UP ### > pingaddr=8.8.8.8 > pingaddr=192.168.something Binding a value to pingaddr twice? > echo littcrond checking network 1>&2 echo is kind of like a basic print statement, except you sort of don't need quotes. littcrond , checking , and network are passed as three separate tokens to echo, which sees each one as a string literal (because it doesn't recognize any of them as something defined) and echoed separately literally. The clot 1>&2 , (man bash, / search for redirect) redirects stderr to stdout for the echo. > while ! ping -q -c1 $pingaddr > /dev/null; do between the while and the semicolon is the condition. Between the do and the done are the commands to execute in the loop. The loop condition is tested at the start of the loop. Exclamation mark inverts the test. ping returns a success value. In shell, success is zero, failure non-zero. That allows failure to be an error code, but it also surprises you if you forget that it's the reverse of C and many other languages. This doesn't really matter here, because ! expects the shell version of a boolean flag, so it does what it should. man ping tells us -q is "quiet" and -c1 says stop after 1 packet. $pingaddr refers through the name pingaddr, which was last bound to a LAN local address above, essentially as if pingaddr were a variable. > sleep 1 > echo littcrond REchecking network 1>&2 > done So the meat of the loop is in the test, and the body we just sleep and so we are waiting/checking. > ### RUN THE DAEMON ### > exec envuidgid slitt envdir ./env setuidgid slitt \ > /d/at/python/littcron/littcron.py \ > /d/at/python/littcron/crontab man exec for clues to that, understand that littcron.py is Steve's special cron (right, Steve?), and that he is setting up a special environment for things and there's other stuff there that I can only guess at, not having the code to littcron, I think. So I'll punt here. > == -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPyBSL+CHt-wcz2YN1HC5jKWWbbtcmVniwMCkFbp_8=x...@mail.gmail.com
Re: Bash usage: was implicit linkage
2014/10/12 23:07 "Andrei POPESCU" : > > On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: > > > > From my viewpoint, shellscripts were never intended to be big, huge > > programs. To me, they just glue together commands, and have a few > > rudimentary branching and looping constructs. > > Isn't that like buying IKEA furniture, but when you get home you realise > all those little plastic bags with screws and mounting pieces are > missing? I will say this: > > Any program that requires additional scripting just to get it > running is insufficiently advanced. s/advanced/customized/ Or you could talk about the difference between the jobs of distributor and integrator, if you're completely anti-DIY. > [...] Although, some of us don't really care all that much for IKEA furniture. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Bash usage: was implicit linkage
2014/10/13 2:14 "Andrei POPESCU" : > > On Du, 12 oct 14, 10:30:52, The Wanderer wrote: > > On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: > > > > > Any program that requires additional scripting just to get it running > > > is insufficiently advanced. > > > > > > (you can quote me on that) > > > > Part of the tradeoff for power is responsibility - both in the > > responsibility to use the power wisely, and in the responsibility to do > > things yourself rather than have others do them for you. > > But I'm also aware of the limits of my powers and don't try to do too > much, but instead use the right tool. Let's gloss over the idea that opinions on what constitutes "the right tool" differ, and ignore the question of what to do when "the right tool" doesn't exist. > > If you don't want the responsibility of writing shell scripts (or other > > scripting), you will have to accept not having the power to do some of > > the things you could do with such scripts. > > As well as avoid some of the mistakes I would (most probably) do. Which is another way of saying that you want others to have already made the mistakes for you. As long as you recognize that somebody has to make the mistakes, and don't mind watching and learning while they do, that's not necessarily a bad thing, given courtesy and quid-pro-quo, of course. > [...] Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Bash usage: was implicit linkage
2014/10/13 2:45 "Steve Litt" : > > On Sun, 12 Oct 2014 09:33:43 +0100 > Martin Read wrote: > > > On 12/10/14 04:12, Peter Zoeller wrote: > > > But the nice > > > thing is shell scripting is simplistic easy to learn and understand. > > > > I refer the audience to David A. Wheeler's essay[1] on how to handle > > filenames correctly in shell scripts, and to the bug report that he > > filed against POSIX.1-2008[2] on the subject. From those, I take away > > the lesson that no, shell scripting is not simplistic, easy to learn, > > and easy to understand. It just *looks* simplistic, easy to learn, > > and easy to understand, in ways that make it a horribly effective > > footgun. > > > > [1] http://www.dwheeler.com/essays/filenames-in-shell.html > > Martin, > > Thanks so much for the preceding resource. It's worth its weight in > gold, and I've bookmarked it for quick retrieval. mutter mutter ... cleaning input ... tool ... quick hack belt ... generalized tool box mutter mutter > This essay practically screams out for somebody to write a C program > that takes an argument of an arbitrary string, finds all files in a > directory, and returns a long string with those files separated by the > arbitrary string. A shellscript can then use mktemp or some other > facility to make that arbitrary string, pass it to the C program, and > then use the temporary string as a sure fire field separator. The C > program could also take an option as to whether or not should find > hidden files, and it could prepend "./" onto all relative paths not > already beginning with "./". I might do that tonight. mutter mutter ... RE ... glob ... sed - awk wars ... perl ... python - ruby ... mutter mutter erk cough cough man xargs mutter mutter
Re: Moderated posts?
On Sun, Oct 12, 2014 at 11:28 PM, lee wrote: > Steve Litt writes: > >> A) Tell everyone it's a moderated list >> B) Send the poster a short reason why his post has been moderated. > > It would be against RFC-821 to silently drop messages. That's why RFCs aren't/shouldn't be consider hard standards. But, anyway, see RFCs 2821 and 5321 as well, noting such entries in the headers as obsoleted-by and updated-by, and remember, "Request For Comments", even though many news sources insist that these things must be considered standards. (I know that's a lot to read and remember in one sitting. I don't remember/understand it all, myself, either.) (But in this case, absolutely requiring a response would be building a DOS and potential privacy vulnerability into the message infrastructure. The RFCs really should be stored with a summary of relevant comments.) -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iO6deoipA=oc_y28tr+arhmrv6osgega95__lctpq7...@mail.gmail.com
Re: piece of mind (Re: Moderated posts?)
On Mon, Oct 13, 2014 at 7:04 AM, lee wrote: > Bas Wijnen writes: > >> [Moving this to -project, where it belongs; please follow up only >> there, not on -user or -devel.] Uhm, might I ask, ${what}-project ? Oh. https://lists.debian.org/debian-project/2014/10/ Is that going to be appreciated? >> On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote: >>> Why doesn't Debian just do a GR on this issue? >> >> Because for a GR, a member of Debian has to request it and it needs to >> be seconded by at least 5 other members (constitution 4.2.1, 4.2.7). >> This has not happened. > > I know, and I'm suggesting to omit this requirement. > >>> Considering that the users are Debians' priority, couldn't this issue be >>> a case in which significant concerns from/of the users about an issue >>> might initiate a GR? >> >> No. Debian is a very elitist organization. The members decide what to >> do, and nobody else does. As a whole we rule over our users with >> enlightened absolutism. The main difference with rulers of countries is >> that our users can go away more easily. ;-) >> >> Debian is extremely democratic for its members, but it is utterly >> undemocratic for its users. And there's nothing wrong with that, IMO. > > Then they shouldn't say in their social contract that the users and > their needs are the priority. > >>> Wouldn't it speak loudly for Debian and its ways and for what it >>> stands for, or used to stand for, if it was established procedure that >>> issues arising significant concerns amongst the users can lead to a >>> GR? >> >> I'll speak for myself here: I don't really care about the init system. >> I am unhappy with the emotions that this debate is causing, but I'm not >> very interested in the technical parts. Are you a dev? If you are, it seems odd that you wouldn't be looking into the technical issues of something that is causing so much debate. >> From what I see on the mailing >> lists, it seems that a few users are very unhappy and they keep bringing >> this up. But if this would be a big issue for many people, then there >> should be no problem finding 6 members to start a GR (our members are >> users, too). That still hasn't happened, so I conclude that it isn't a >> big issue. > > There can be many reasons for why there hasn't been a GR. Some of these > may be that the devs/maintainers don't really care about the init > system, or that they aren't aware of how far-reaching this issue is. I'm inclined, seeing as I've watched political processes in committees before, to believe that most of the devs are under the impression that even having an opinion on the subject will taint them. Ergo, peer-pressure from a lot of conversations, probably in BOFs, "hackfests", and such, that are now lost to history. When you are familiar with this kind of politics (referred to by some in our community as social engineering), you recognize the after-effects in the way people who are normally reasonable and reasonably logical suddenly start saying things that are non-sequitur and stopping too early at politically correct conclusions when the tainted subject comes up. I'm not accusing anyone of overt threats. I kind of like the term "social engineering" (except that it's a bad reflection on engineering disciplines, in general) for this kind of stuff. It's simply a matter of respected, charismatic types, people who "should know about a subject" mentioning off-hand in private conversations things like Oh, gee, didn't you know that Doctor A. B. C. proved the non-existence of NP-complete problems? in a group of people who are sort-of familiar with the idea of NP-complete problems, but not really equipped with the tools to say to themselves Huh? that's kind of like saying somebody found a way to defeat entropy. and not really in a position to try to find anything written by Doctor A. B. C. or about his work because they are out of the social network. >>> I'm sure we could find quite a few supporters for having a GR amongst >>> the users (here). And after all, we're all kinda stuck in the same >>> boat. A GR might have the potential to make the gap between users and >>> devs/maintainers a lot smaller. Otherwise, this gap will only continue >>> to become wider and wider. >> >> There are many members. If you can't manage to convince 6 of them, we >> don't consider it a big issue. You may disagree, but that's Debian's >> rules. > > I think I don't need to convince 6 people on th
Re: implicit linkage
On Mon, Oct 13, 2014 at 1:39 AM, Martin Read wrote: > On 12/10/14 01:43, lee wrote: >> >> Reco writes: >> >>> >>> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638 >> >> >> Ah, this is a wonderful example :) My assumptions about the code were >> right. >> >> Does all/most of systemd look like that? > > > I'm not seeing a serious problem with that function. > > I mean, I can certainly think of better ways to write it, but I don't find > it bad enough that I'd want to *bother* doing so. I'm thinking of some really fun things to try with those XML-constants-in-macro definitions. Maybe. Have to look at where the code is used, see whether he's keeping the input clean with the right tools. But I'm going to challenge you to try to find a better way to write it. Re-factor it, and get your re-factored code to pass regressions. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMbH3XRZB1uGKs1vjt=UArYcT2+fc7srMFh=QkcwZz=z...@mail.gmail.com
Re: MTAs denying messages (was: Re: Moderated posts?)
On Mon, Oct 13, 2014 at 9:24 AM, lee wrote: > Joel Rees writes: > >> (But in this case, absolutely requiring a response would be building a >> DOS and potential privacy vulnerability into the message >> infrastructure. The RFCs really should be stored with a summary of >> relevant comments.) > > Could you explain how an MTA would create a privacy vulnerability or > expose itself to DOS attacks by not accepting messages? > > For example, my MTA does not accept messages that have an empty Subject: > header. How does that expose my privacy or allow for DOS attacks? Somebody mentioned both the problem and the usual solution later in the thread, but, laying it out in more detail: I have an e-mail address my ISP gave me. Back almost twenty years ago, when the internet was still a bit safe for naive use, I put my isp-provided e-mail address in my home page. For the last fifteen years, I've had to periodically clear that mailbox of junkmail, a thousand in a week at the worst times, down to about a hundred a week now. I'd change the address, but a junkmail magnet is actually an interesting resource. Every now and then, I still get a spate of junkmail there, where the to: field has a long list of semi-random na...@isp.tld . I know those names are bogus because I know there are not that many users at this isp who have registered themselves with English names. Rather amusing. What are the junkmailers doing? Shotgun mailing the isp with possible user names. If the isp responds with a code that says my user-id is valid, the junk mailer knows he has a live address. If the isp responds to the bad ones with an invalid user-id code, any user-id that doesn't get that response is assumed live. There's your privacy problem. If the isp accepts the message without acknowledging the existence of the user id, and then later sends an undelivered message, that's still revealing what user-ids in the random attack were valid, and it also amplifies the attack -- backscatter. Wikipedia's current article is fairly informative, check the references, too. http://en.wikipedia.org/wiki/Backscatter_%28email%29 If the sending box is a bot, it will disappear by the time a delayed rejection message is sent, which will cause a host-not-found message from somewhere. This also amplifies traffic. There have been several relatively well-known cases where this kind of opportunistic junkmail temporarily took an isp off the network. Searching the web for such things as "backscatter spam" should get you more information. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ipjskq9tyfod9vymjszwm3ye5bydwe2tugcnupfcsu...@mail.gmail.com
Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 1:38 PM, Chris Bannister wrote: > On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote: >> 2014/10/13 2:14 "Andrei POPESCU" : >> > >> > On Du, 12 oct 14, 10:30:52, The Wanderer wrote: >> > > On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: >> > > >> > > > Any program that requires additional scripting just to get it running >> > > > is insufficiently advanced. >> > > > >> > > > (you can quote me on that) >> > > >> > > Part of the tradeoff for power is responsibility - both in the >> > > responsibility to use the power wisely, and in the responsibility to do >> > > things yourself rather than have others do them for you. >> > >> > But I'm also aware of the limits of my powers and don't try to do too >> > much, but instead use the right tool. >> >> Let's gloss over the idea that opinions on what constitutes "the right >> tool" differ, and ignore the question of what to do when "the right tool" >> doesn't exist. >> >> > > If you don't want the responsibility of writing shell scripts (or other >> > > scripting), you will have to accept not having the power to do some of >> > > the things you could do with such scripts. >> > >> > As well as avoid some of the mistakes I would (most probably) do. >> >> Which is another way of saying that you want others to have already made >> the mistakes for you. > > No it isn't! Ponder why most people take their car to a mechanic for > servicing. And you snipped: >> As long as you recognize that somebody has to make the mistakes, >> and don't mind watching and learning while they do, that's not necessarily >> a bad thing, given courtesy and quid-pro-quo, of course. Paying a mechanic is one kind of quid-pro-quo, wouldn't you say? Paying money to buy the car is another form of quid-pro-quo, as well, I'd say. Do I need to unpack that a bit more, talk about how testing is a substitute for making mistakes? > -- > "If you're not careful, the newspapers will have you hating the people > who are being oppressed, and loving the people who are doing the > oppressing." --- Malcolm X -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43io+hd6vbnnjmvetz-nnt9ernukfb6fdrkdqqz3fvrq...@mail.gmail.com
Re: [exim4] mixed up about terminology
On Mon, Oct 13, 2014 at 11:24 AM, lee wrote: > Jerry Stuckle writes: > >> Among other things, legitimate MTAs have MX records. Anti-spam routines > > Who prevents a MUA from having an MX record and sending a HELO that > matches the RDNS entry? And what are these "other things" you're > referring to? MX record? Recorded in the domain name servers? When the sender is a bot with an ephemeral MTA/MUA? Hmm. Yeah, it can be done. Patient and careful use of free dynamic DNS services, or DNS poisoning. Temporary and slow. But the more you make the junkmailers work for their money, the more they switch to legitimate work. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inryoejfasuzzp_wjxlhqch_wgsa+mgavga4ovdnxv...@mail.gmail.com
Re: implicit linkage
de in that file, much improved as it is in current, looks like code that can get into exactly that kind of trouble. I'd have to dig way down deep to be positive, but I'm still extremely unimpressed. Get pid 1 down to 100 lines of C, no loops, no functions called, then I'll be impressed. Heh. No, that's talking about getting Linux ready to compete seriously in embedded, and the kernel needs a bit of work before we start talking about that. (Not that you can't use it now, sans systemd, in some of the less demanding embedded applications. There are some embedded applications it will work for, with reasonable pid 1 processes.) Setting aside initialization code, pid 1 should target less than 1000 lines of C in the main loop. (If we were to use dash or other streamlined shells, we might set a target of 100 lines of code.) Loops and subroutines should be carefully metered for maximum execution paths, and proven to be deterministic, with a maximum execution path of less than 500 lines of C. (I think this target would be significantly better than sysv-init, but you have to set a really good target to get things into a reasonable range.) It should not interface directly with dbus, cgroups, udev, or pamd. It should delegate interfacing to such things to non-pid 1 daemons, and restrict itself strictly to keeping the daemons themselves working together. There are other goals I should mention, but I don't imagine Lennart Poettering is even the slightest interested in what we have to say here, so I won't bother. No matter how much better it is now than last year, the code is still just plain wrong. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43io+cd_fc42ytmch7mtqjm+cocxfqh+n0wvthno8cvx...@mail.gmail.com
Re: implicit linkage
On Mon, Oct 13, 2014 at 7:34 PM, Ansgar Burchardt wrote: > Hi, > > On 10/13/2014 12:14, Joel Rees wrote: >> Get pid 1 down to 100 lines of C, no loops, no functions called, then >> I'll be impressed. > [...] >> Setting aside initialization code, pid 1 should target less than 1000 >> lines of C in the main loop. (If we were to use dash or other >> streamlined shells, we might set a target of 100 lines of code.) Loops >> and subroutines should be carefully metered for maximum execution >> paths, and proven to be deterministic, with a maximum execution path >> of less than 500 lines of C. > > What's the point of this exercise? What exercise? I'm repeating rules of thumb, not revealing the ways I derived them (estimates, based on the idea that you don't want anything close to a millisecond consumed by a pass through the main loop in pid 1), and admitting that the target I'm proposing is not necessarily achievable. systemd doesn't even consider such a target, near as I can tell. I didn't do a full analysis, but from my casual scan I'm guessing there are times a pass through the systemd main loop consumes more than a hundred microseconds, which is too close to a millisecond. > Linux's process scheduler alone has > significant more lines. And there runtime complexity actually matters... Does the scheduler run as pid 1? Have you traced execution paths? Did I say the kernel did not need some work? I don't remember saying such a thing,. In fact, I distinctly remember implying that it did need continued work. > I'm just counting lines in kernel/sched/*.[ch], I'm too lazy to filter > out comments. Or do the execution path analysis. Okay, I haven't shown the result of a path analysis for systemd, either. But systemd runs as process 1. The scheduler does not. > As an example: > > $ wc kernel/sched/fair.c > 7867 26757 207986 kernel/sched/fair.c You might want to ask on the kernel list for a pointer to the last execution path analysis Linus did for the scheduler. You might be surprised about what they tell you. You might also want to ask how often the code in fair.c runs. At any rate, whatever the kernel does is no excuse to introduce the kind of code in systemd into pid 1. pid 1 should always delegate any complex task to a child process. That way, a failure in the complex task does not have to be dealt with before pid 1 can do it's job the next time around. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMCytQ12M23yZFNF=SVq3jbKJa-6AvW1L2dDy-V-T+C=w...@mail.gmail.com
Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 10:53 PM, Chris Bannister wrote: > On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote: >> >> >> >> Which is another way of saying that you want others to have already made >> >> the mistakes for you. >> > >> > No it isn't! Ponder why most people take their car to a mechanic for >> > servicing. >> >> And you snipped: >> >> >> As long as you recognize that somebody has to make the mistakes, >> >> and don't mind watching and learning while they do, that's not necessarily >> >> a bad thing, given courtesy and quid-pro-quo, of course. > > Not on purpose. I didn't see it. It wasn't near that paragraph. > >> Paying a mechanic is one kind of quid-pro-quo, wouldn't you say? > > Don't know about you, but I don't know anyone who pays their mechanic to > make mistakes. Au contraire in fact. > >> Do I need to unpack that a bit more, talk about how testing is a >> substitute for making mistakes? > > No thanks. And yet it is apparent that you need it unpacked for you. Good mechanics made plenty of mistakes while learning the trade, and learned from their mistakes. That's what schools are for, and that's why those who learn on the job practice on junkers and their own hot-rods before they tackle customers' cars. Tests at school are one more opportunity to make sure that most of the learning by mistakes is behind you when you start working on customer equipment. (I don't want the straight-A student right out of school as my mechanic, or doctor. Straight-A students make their mistakes on the job.) -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOWKjMpdQCei65i-CuECnSXoDZyRWEnfs1Mhtz2ZZ0y=g...@mail.gmail.com
Re: implicit linkage
On Mon, Oct 13, 2014 at 10:44 PM, Chris Bannister wrote: > On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote: >> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland wrote: >> > On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote: >> >> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read wrote: >> >> > On 12/10/14 18:13, John Hasler wrote: >> >> > > You have no problem with an 1800 line function? >> > ... >> >> > I have a problem with 1800 line functions in general; >> > ... >> >> I have no problem with an 1800 line function. >> > ... >> > >> > *What* 1800 line function? The commit URI that was shared was an 1894-line >> > *file* with a large function definition starting at line 638 and ending at >> > 1890. That's a 1252-line function. >> >> mmm? 1800 vs. 1252 ? >> >> 30 years ago, when we still read printouts, 60 lines was considered >> the ideal max because that's what would fit on a page. >> >> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or >> so), so 40 lines is a good screen-full. But it turns out, with being >> about to scroll quickly, that 60 lines is still not hard to reach. >> Moreover, 60 lines seems to be a pretty good average for what an >> experienced coder can keep in his head. > > LOC is a silly way to measure anyway. You could put all the code on one > line --- PITA to read, but hey! it's only one line of code! :) You didn't read the rest of my post, did you? > "If you're not careful, the newspapers will have you hating the people > who are being oppressed, and loving the people who are doing the > oppressing." --- Malcolm X > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20141013134448.GB2362@tal > -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ipbkzh94rctqtmh1d-jhgpadmtsffzbdynfc6guwz5...@mail.gmail.com
Re: piece of mind (Re: Moderated posts?)
2014/10/14 4:35 "Jonathan Dowland" : > > On Mon, Oct 13, 2014 at 12:23:42PM -0700, Bob Holtzman wrote: > > If that's true, why the avalanche of dissent now? > > I see a lot of posts, but hardly any posters, and not a great deal of clarity > or consistency about what the complaints are. I also see a lot of FUD, both > about systemd and what Debian has agreed to do. In other words I don't see an > avalanche, nor the tip of an iceberg. Step 1: Somebody raises a valid problem, but doesn't have a whitepaper and list of bugs that will happen. Step 2: Somebody notices, very publicly, that there is no whitepaper, and that the person raising the issue is not clairvoyant. (We really want that list of bugs, of course.) Step 3: Somebody notices that the complaint can be conflated with a non-issue, and implicitly advises everyone to do so. Step 4: Somebody tries to point out that conflating problems with non-issues is not a good idea. Step 5: A chorus of boos rises aganst the whole thread, because there is no whitepaper, and no clairvoyance, and besides, it looks "just like this non-issue". Presto: All dissent is fud. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Way OT: Re. lines of code [was Re: implicit linkage]
On Mon, Oct 13, 2014 at 10:47 PM, Miles Fidelman wrote: > Chris Bannister wrote: >> >> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote: >>> >>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland >>> wrote: >>>> >>>> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote: >>>>> >>>>> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read >>>>> wrote: >>>>>> >>>>>> On 12/10/14 18:13, John Hasler wrote: >>>>>>> >>>>>>> You have no problem with an 1800 line function? >>>> >>>> ... >>>>>> >>>>>> I have a problem with 1800 line functions in general; >>>> >>>> ... >>>>> >>>>> I have no problem with an 1800 line function. >>>> >>>> ... >>>> >>>> *What* 1800 line function? The commit URI that was shared was an >>>> 1894-line >>>> *file* with a large function definition starting at line 638 and ending >>>> at >>>> 1890. That's a 1252-line function. >>> >>> mmm? 1800 vs. 1252 ? >>> >>> 30 years ago, when we still read printouts, 60 lines was considered >>> the ideal max because that's what would fit on a page. >>> >>> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or >>> so), so 40 lines is a good screen-full. But it turns out, with being >>> about to scroll quickly, that 60 lines is still not hard to reach. >>> Moreover, 60 lines seems to be a pretty good average for what an >>> experienced coder can keep in his head. >> >> LOC is a silly way to measure anyway. You could put all the code on one >> line --- PITA to read, but hey! it's only one line of code! :) >> > > Go Perl. > Go APL. > :-) I'm afraid the reasons we don't use perl or APL to write pid 1 code is not clear to most casual readers, so I'll be uncool and say it out loud: Non-deterministic execution. If pid 1 gets stalled, lots of things all over the system get to wait for something important that can't happen until pid 1 gets un-stalled, and that's true even with quad core. It may not freeze every process, but it can cause dropped packets and such things. Potentially, you could, every now and then, lose a buffer-full of data headed for a file on disk, as well. Again, to be painfully pedantic, one in ten thousand buffers is more of a problem than one in a hundred. You notice frequent dropped buffers, so you're likely to fix the problem. Infrequent dropped buffers tend to be not noticed until the data is lost. The only way to fix that in systemd is for systemd to delegate the complicated stuff like managing dbus to child processes, so the processes that will occasionally stall won't impact the whole system as much. When/if that happens, we should see the hard dependencies between systemd and other stuff that has been absorbed by systemd disappear. The real problem is that Poettering and others over there have rather indicated an unwillingness to do that. If we are willing to accept this kind of engineering, we have to assume that either the developers at systemd will eventually get around to a proper refactoring of the processes (and not just code within pid 1), or we have to hope that open processes will ultimately force their hand. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imlfvvy0+pm+eejr_xjwuzh8mtvedsgqt87_d6ujth...@mail.gmail.com
Re: debian-advocacy?
On Tue, Oct 14, 2014 at 7:35 AM, Brian wrote: > On Mon 13 Oct 2014 at 15:07:33 -0700, Buntunub wrote: > >> This list is the perfect place for such things. The decision to make Systemd >> default in Jessie was done by the Technical Committee, not by general vote, >> so I guess it was decided that the whole discussion about Systemd is a bug >> because it was relegated to such. This is the mailing list used to discuss >> bugs and technical issues, is it not? > > I wanted so much to understand and make sense of what was being said > here but gave up in the end and turned to the comfort of a book on > Quantum Chromodynamics. Can I recommend a thesis on analyzing execution paths of critical processes? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ipokgmhr+y-5eeyxi1nslxssmodsyk6xqhe35btx1b...@mail.gmail.com
Re: debian-advocacy?
On Tue, Oct 14, 2014 at 8:14 AM, Brian wrote: > On Tue 14 Oct 2014 at 08:02:28 +0900, Joel Rees wrote: > >> On Tue, Oct 14, 2014 at 7:35 AM, Brian wrote: >> > On Mon 13 Oct 2014 at 15:07:33 -0700, Buntunub wrote: >> > >> >> This list is the perfect place for such things. The decision to make >> >> Systemd >> >> default in Jessie was done by the Technical Committee, not by general >> >> vote, >> >> so I guess it was decided that the whole discussion about Systemd is a bug >> >> because it was relegated to such. This is the mailing list used to discuss >> >> bugs and technical issues, is it not? >> > >> > I wanted so much to understand and make sense of what was being said >> > here but gave up in the end and turned to the comfort of a book on >> > Quantum Chromodynamics. >> >> Can I recommend a thesis on analyzing execution paths of critical processes? > > I'd try anything if it brought enlightenment to the post I responded to. Well, that would be another topic. But understanding execution path analysis might help understand some of the underlying reasons for these kinds of posts. If you aren't familiar with the topic of execution paths, these wikipedia articles will get you started on the topic: http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 http://en.wikipedia.org/wiki/Performance_engineering http://en.wikipedia.org/wiki/Worst-case_execution_time I thought I had some theses handy on the topic, but they discuss tools for analysis and assume understanding the topic. One is ftp://ftp.cs.wisc.edu/pub/paradyn/technical_papers/CritPath-ICDCS1988.pdf -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iO5Jr8oLdsjxh=b-eoc5admj8mtqh1umcerxq75u1v...@mail.gmail.com
Re: Moderated posts?
On Tue, Oct 14, 2014 at 8:18 AM, lee wrote: > Jerry Stuckle writes: > >> And, in fact, more and more ISPs are just accepting and discarding >> emails to non-existent users because rejecting such email helps spammers >> (any non-rejected email must be a valid user). > > That's totally retarded. When I don't get an error message in return, > the message I sent has been delivered. If it hasn't because there's > some error, I will not be responsible for any damage that may hit the > recipient or myself. Quietly dropping messages is not an option. There is a header for requesting automatic confirmation of delivery, but it tends to be abused by malicious junkmailers (spammers). MUAs are supposed to be able to disable it, but I haven't seen that option in an MUA settings dialog for a long time. This is a grey area of the e-mail standard. People want it to be like snail-mail, only automatic, but don't realize that having people in the loop is what provides the desired feature. I mean, you really can't have certified delivery without someone to certify it. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43in3hz9mvqnvzfm2icctf22wu325rbfchvgl3bwad9o...@mail.gmail.com
Re: Network fails on headless system. I'm stuck!
message I got on the serial terminal was: > ng device sys-subsystem-net-devices-eth0.device... > [ ***] (5 of 7) A start job is running for dev-disk-by\x2dl...14s / 1 > which wasn't readable because of a lot of CR without LF. the syslog > above tells more about it. > After this the serial console stops working. > > > attached > crash.log - the kernel panic that occured while I had network problems > history.log - /var/log/apt/history.log - I cannot find anything network > related in there. > > > any idea what the problem is, and how to solve? > > thanks for any help, > > Jan > > > ps. I did not subscribe the list. Please CC me. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inmhazyqy2g3u-iqqedkt2vszkh6rzd71ed+qnhmdg...@mail.gmail.com
Re: Recipient validation - WAS: Re: Moderated posts?
Oh, dear. Somebody is WRONG on the Internet! You're talking past each other. Still, the current "standard" e-mail protocols were never meant to be either reliable or secure, and their is a very good reason for that. People may not be as reliable as machines in executing protocols, but they cannot be 100% reliable, and only people can certify things. 2014/10/15 1:04 "Tanstaafl" : > > On 10/14/2014 11:17 AM, Jerry Stuckle wrote: > > On 10/14/2014 8:05 AM, Tanstaafl wrote: > >> If you think I'm kidding, please by all means go make these silly > >> statements on the postfix list and I'll just sit and watch the fun. > > > You don't read very well. This has nothing to do with emails to a valid > > address. A large amount of that spam goes to invalid addresses. I see > > them go through the logs regularly. > > I read fine. The 'silly statements' reference was about your suggestion > that it is in any way shape or form 'ok' to *accept* mail to invalid > recipients then send it to dev/null. > > >>> To bounce all of those invalid addresses not only would further > >>> increase the amount of junk on the internet, > > >> That is pure and absolute nonsense. The vast majority of spam comes from > >> botnets, and *rejecting* garbage from these results in ZERO additional > >> smtp traffic. > > > Wrong. Rejecting garbage sends a message back to the originator, > > No, it doesn't. It closes the connection with a response code. > > The system that had opened the connection and was attempting to send the > email is the one responsible for 'sending a message back to the originator'. > > Well, *if* the system talking to your server is the originating server, > that is. > > If, on the other hand, there were relays involvbed, then it would simply > relay the response code back down the chain until it got to the > originating server. > > This is very simple to validate. I suggest you do so before compounding > your error in public. > > > increasing the traffic. Simply dropping them, as I do, does not. > > Given an identical mail transaction, with an email with a size of 1MB: > > If I reject the mail at the RCPT-TO stage, then I only accepted a few > bytes of traffic before terminating the connection with an SMTP response > (error) code. The connecting machine then decides whether to pass the > response back or not (again, a few bytes at most). > > If you *accept* the mail, then you accepted the entire 1MB of traffic. > > So, who is responsible for more traffic in such a case? > > >>> but by not replying, servers tell the spammers what are valid email > >>> addresses. > > >> More nonsense. Security through obscurity *never* works, and only, in > >> this case totally breaks SMTP. > > > Wrong on two counts. First of all, the false notion "Security through > > obscurity *never* works". This has nothing to do with security. > > You said you were concerned about telling spammers valid emails. Why are > you concerned about that if not from a security perspective? > > > And BTW, that statement is also wrong - why do you think people are > > encouraged to use obscure passwords if it doesn't work? But that's > > another subject. > > Lol! Not even in the same ballpark, Jerry. Passwords, by their very > nature, are intended to be difficult/impossible to 'guess'. > > To suggest that this is even in the same universe as 'security through > obscurity' is ludicrous. > > > On the second count - please point out exactly which RFC I am violating > > that "breaks SMTP". > > You don't necessarily need to explictly violate any give RFC to 'break > SMTP', Jerry. > > Breaking recipient validation defacto breaks SMTP. It tells the sending > server that everything is OK, when it isn't. It allows someone who > > >>> Finally, as for "...undermine confidence in the reliability of the > >>> Internet's mail systems..." - it hasn't been reliable since spammers > >>> virtually took over the email. And even when emails were rejected, it > >>> still was no indication the recipient got the message. > >> > >> Of course it wasn't, but it was certainly a positive indication that the > >> recipient did *not* receive it (as long as the sending server is > >> properly configured). > > > And why should I care if a bot finds out the message has not been received? > > No one should. What I do care about is if the President of NBC typos an > email address to our President when sending an important email, I want > him to know the email didn't make it. > > >>> BTW - by definition, any messages to any of the domains I manage without > >>> a valid email address are "seriously fraudulent or otherwise inappropriate". > >>> > >> Really? > > > > Yes > > > >> So when the President/CEO of XYZ Corporation, who does business with a > >> customer whose domain happens to be managed by you, accidentally typos > >> an email address, you consider that a 'seriously fraudulent or otherwise > >> inappropriate' email? > > > Yes. > > Please explain what is *Seriously Fraudulent* or *ot
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman wrote: > Tanstaafl wrote: >> >> On 10/14/2014 1:58 PM, Miles Fidelman wrote: >>> >>> Well, this really is OT for debian-users, but Turns out that SMTP >>> WAS/IS intended to be reliable. >> >> Reliable, absolutely. 100% reliable? That simply isn't possible when >> people are involved in the equation (people mis-configure servers - >> whether accidentally, through ignorance, or intentionally (just because >> that is the way they want it). >> >>> I'd always lumped SMTP in the category of unreliable protocols, w/o >>> guaranteed delivery >> >> The protocol itself is extremely reliable. It is what people *do* with >> it that can cause it to become less reliable/resilient. There are three ways in which machines can be unreliable. One, they can break. Two, they can do what they are told to do, but what they are told to do can be wrong. Three, they can operate in a context in which they were not designed to operate. Unfortunately, most machines operated outside the context in which they were designed to operate. It's a limitation of design. We are the designers, and we can't think of everything, therefore we cannot really design for a real context. Put another way, any context we can design for is necessarily more constrained than reality. Fortunately, most of the contexts we design for are "close enough" to be useful under many real contexts. But we have to quit being taken by surprise when our machines hit corner cases, or we end up wasting our energy being surprised. That's one of the reasons the Requests For Comments were RFCs and not standards dictated from on high (like many of the earlier network definitions that ended up too inflexible). > There is a technical distinction between "best efforts" (unreliable) > protocols, such as IP ('fire and forget' if you will), and "reliable" > protocols, such as TCP (with explicit acks and retransmits). > > At least in the technical circles I run in (BBN - you know, we built the > ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally > worked for me, for a short period - in a matrixy version of "worked for"), > SMTP is usually discussed as providing a "best efforts" (unreliable) service > -- which, in reality, it is (particularly in real world configurations where > mail often gets relayed through multiple servers). > > So.. I was just a bit surprised to go back and read the RFC and discover > that SMTP is explicitly intended to provide a reliable service. If it is, that has changed. Elsewhere from the part you quoted, there used to be an explanation of the self-contradictory nature of the requirements. Specifically, machines cannot actually (the illusions of PKI becoming widely accepted notwithstanding) certify delivery. That requires a human at both ends of the chain, in addition to the possibly human sender and recipient. RFC 821 messages were intended not to require any human in the chain. If that has changed, it would be the unreasoning demands of people who want e-mail to perfect in ways snail mail only almost could be in the best of times: people who want to be able to do things like sue other people for not complying with obscure rules when informed of those rules by e-mail. > As to "100% reliable" - nothing is 100% reliable. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iP9t8iJYmPNLkVw_Pg8UAJYHHZeacftZ=fm_rt2cr1...@mail.gmail.com
Re: Conflict of interest in Debian
they just basically aren't going to get any faster with any of the technology that we have any Moore. systemd tries to do too much, and fixing the corner cases will kill it eventually. Processors aren't going to get faster and save the day like they have with so many formerly impossible things. Hopefully, by that point, Poettering will cease to believe he's Supercoder and start having systemd delegate the hard stuff. Or someone will fork the code and fix what he is refusing to fix. He could have designed it that way from the start, but then it would look mostly like a re-write of sysv-init, and it wouldn't have been such a "cool new technology." Going further than that will, again, invite people to call "Foul!", so I'll refrain. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNH0E92tM29vpLYfPXEk+UMN=cYBxuS-=y0jud-c5b...@mail.gmail.com
Re: Conflict of interest in Debian
2014/10/16 5:46 "Ric Moore" : > > On 10/15/2014 12:39 PM, Steve Litt wrote: > >> We've actually been in this place before. Wonderful Linux company >> Caldera became SCO (oversimplification, but you know what I mean). >> Wonderful Linux company Corel changed their CEO, and promptly accepted >> money from Microsoft and dropped all their Windows software. > > [...] > If you knew Caldera, then you would know that it started with capitalization and focus by the retired CEO of Novell, Ray Noorda. > Now that is my kinda guy, as he knew that Linux would grow to be more than a desktop hobby toy. And, he put his own money where his mouth was. He was not responsible for what happened after. I still have a copy of the Caldera install CD and it worked like a charm on an aging ThinkPad. But it was too pitiful to watch Netscape try to update itself. :) Ric > Yes, Noorda was a good guy. I think Steve was talking about a later CEO.
Re: piece of mind (Re: Moderated posts?)
2014/10/16 5:59 "Andrei POPESCU" : > > On Mi, 15 oct 14, 09:46:47, The Wanderer wrote: > > > > I suspect that the answer is "they just didn't provide the functionality > > which ConsoleKit, and later systemd-logind, now enable them to provide", > > but I'm not aware - in a clear-understanding, defined-boundaries sense - > > of exactly what that functionality is, or of why it would be necessary > > or otherwise valuable, or of what the problem is which that > > functionality was intended to address. > > A problem that ConsoleKit and logind is trying to address is handling > permissions to access devices. > > Traditionally on *nix machines this was done with user groups, e.g. > members of 'audio' would have full (read/write) access to all audio > devices and members of 'video' would have full access to video cards or > web-cams. > > The problem with this approach is that it's not fine-grained enough, > i.e. it can't distinguish between users logged in locally or via ssh. > This means Mallory could easily spy on Alice remotely, just by being a > member of 'audio' and 'video'. > > Hope this explains, > Andrei Two thoughts that this problem brings to mind -- (1) Why should it matter? Local? Remote? A hole is a hole. (1.5) How does ssh deal with making connections private? Any clues there? (2) There are times when I don't want to have to be logged in as an admin user to be able to make an ephemeral group. I've understood that for ten years. When am I going to make the time to construct the package to manage it within the standard unix permissions model? :-( Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: piece of mind (Re: Moderated posts?)
2014/10/16 8:14 "Chris Bannister" : > > On Wed, Oct 15, 2014 at 12:30:26PM -0400, Steve Litt wrote: > > > > I completely understand not reinventing the wheel, but if all you need > > is a spoke, you don't construct an interface to a whole wheel just to > > get your spoke. > > A wise old owl lived in an oak > The more he saw the less he spoke > The less he spoke the more he heard. > Why can't we all be like that wise old bird? There are "generalisms" like "monolithic is a problem". And then there are generalisms like "Engage brain, then engage mouth." I might wonder which is more on-topic here. > -- > "If you're not careful, the newspapers will have you hating the people > who are being oppressed, and loving the people who are doing the > oppressing." --- Malcolm X -- Joel Rees
Would discussion of improving sysv-init be on topic?
systemd's problems would best be discussed at the systemd project. (Modulo the willingness of the devs over there to discuss them.) What I'm thinking is to talk about specific features to enable the sort of "managing services" that systemd seems to be aimed at, and how to implement them, where existing alternatives exist and how well they work, With enough discussion, we might be able to get enough mass to get a project started and get it (mostly) off-list. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: piece of mind (Re: Moderated posts?)
2014/10/16 15:34 "Jonathan Dowland" : > > On Thu, Oct 16, 2014 at 01:12:51AM -0400, Steve Litt wrote: > > OK, I'll be the first to admit that after Red Hat caused the demise of > > ConsoleKit (and probably lots more important software), I am free to > > take significant time out of my day job (that feeds my family) and > > rescue all sorts of software that Red Hat deliberately scuttled. > > You're being completely ludicrous, Steve. The extent of your sense of > entitlement is breathtaking. Here you are on a list dedicated to an OS > built almost entirely by volunteers and you're not prepared to roll > your sleeves up, but you're more than happy to tell everyone how they > should do it, and what they should do. > > I'm not going to engage with you any more on this list. I think it would help if we wouldn't assume the other guy is freeloading, just because he seems to have time to be looking places we not to, or because he shares his work in different ways. FWIW, I've been getting three or four hours of sleep at night for the last month, and I haven't touched any of my personal projects since before summer, including one that should have been making my day job significantly easier by now. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl wrote: > On 10/15/2014 8:37 PM, Jerry Stuckle wrote: >> Tanstaafl couldn't answer it, and you can't either, because it's not >> violating any. > > I did answer it, you just ignored it or don't understand it. > > Quote: > > "You do not have to violate an RFC to break SMTP." > > Here is a real world example: > > Improperly configured TCP filtering features on firewalls and routers > don't violate any specific RFC, but they certainly can break SMTP (and > other things too). Thus, we can understand that you are an idealist that would rather see your version of SMTP rules be followed by everyone than try to follow the RFC yourself. Where are your SMTP rules spelled out, by the way? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMhgnbTZiDfiG=yyV8cC5O+=-pttkhdaxemzqub6x3...@mail.gmail.com
Re: Would discussion of improving sysv-init be on topic?
On Thu, Oct 16, 2014 at 9:33 PM, Nate Bargmann wrote: > * On 2014 15 Oct 19:39 -0500, Joel Rees wrote: >> systemd's problems would best be discussed at the systemd project. (Modulo >> the willingness of the devs over there to discuss them.) >> >> What I'm thinking is to talk about specific features to enable the sort of >> "managing services" that systemd seems to be aimed at, and how to implement >> them, where existing alternatives exist and how well they work, >> >> With enough discussion, we might be able to get enough mass to get a >> project started and get it (mostly) off-list. > > Perhaps you are not aware of the development project for sysvinit that > already exists: > > http://savannah.nongnu.org/projects/sysvinit > > That would be a far better place to get involved. Would that be debian's sysv-init? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOPHp9172PXkvJENUqr=lph7+15wgmelz3cdosp-fh...@mail.gmail.com
Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, Oct 16, 2014 at 9:34 PM, Tanstaafl wrote: > On 10/16/2014 7:40 AM, Joel Rees wrote: >> On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl wrote: >>> > On 10/15/2014 8:37 PM, Jerry Stuckle wrote: >>>> >> Tanstaafl couldn't answer it, and you can't either, because it's not >>>> >> violating any. >>> > >>> > I did answer it, you just ignored it or don't understand it. >>> > >>> > Quote: >>> > >>> > "You do not have to violate an RFC to break SMTP." >>> > >>> > Here is a real world example: >>> > >>> > Improperly configured TCP filtering features on firewalls and routers >>> > don't violate any specific RFC, but they certainly can break SMTP (and >>> > other things too). >> Thus, we can understand that you are an idealist that would rather see >> your version of SMTP rules be followed by everyone than try to follow >> the RFC yourself. >> >> Where are your SMTP rules spelled out, by the way? > > Ok, I just went and looked it up, and lo and behold... > > RFC 2821 is the controlling RFC if I'm not mistaken... > > https://tools.ietf.org/html/rfc2821 > > In there you'll find this: > > " The second step in the procedure is the RCPT command. > > RCPT TO: [ SP ] > >The first or only argument to this command includes a forward-path >(normally a mailbox and domain, always surrounded by "<" and ">" >brackets) identifying one recipient. If accepted, the SMTP server >returns a 250 OK reply and stores the forward-path. If the recipient >is known not to be a deliverable address, the SMTP server returns a >550 reply, typically with a string such as "no such user - " and the >mailbox name (other circumstances and reply codes are possible). >This step of the procedure can be repeated any number of times." > > So, how do you 'interpret' the pertinent part: > > "If the recipient is known not to be a deliverable address, the SMTP > server returns a 550 reply, typically with a string such as "no such > user - " and the mailbox name (other circumstances and reply codes are > possible)." > > ? > > Sounds to me like a mandate to reject invalid recipients at the RCPT-TO > stage. Well, I'll tell you what. Before I try to engage with you on this, I'm going to do my part and re-read RFCs 5321, 5322, 4409, and BCP 14 and several others referred to therein, completely, and make sure I understand them. I strongly encourage you to do the same. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ip5ymnc3zvqsvyqwo3bgabwseaf1djcxif_lmsqsou...@mail.gmail.com
Re: Would discussion of improving sysv-init be on topic?
On Thu, Oct 16, 2014 at 9:57 PM, Nate Bargmann wrote: > * On 2014 16 Oct 07:54 -0500, Joel Rees wrote: >> Would that be debian's sysv-init? > > That link is from the sysvinit-core package's description in Sid's > Aptitude. Presumably it is the upstream project. Thank you. I was under the impression that there wasn't really an upstream for sysvinit. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iM84z+iV9+hx1xVvkyQaGzMbsXTyidefYM=xyd_+6q...@mail.gmail.com
Re: GR proposed re: choice of init systems
parallels in the industry, Microsoft kept making impossible promises about MSWindows being able to duplicate the Macintosh experience on "standard IBM-PC hardware", basically from the year 1985, when they first realized that the early Macintosh might not be a fluke. Their "forward-looking" promises, and their continual reliance on Moore's law to rescue them from the worst of their bad promises, gave them the edge to gain their effective monopoly. That is part of what is being referred to when people express concerns about systemd "taking over Linux". We hope that systemd will improve. Business-types seem to like the stuff it provides. But it's going to take major re-design to make it reliable. As engineers, we wanted systemd to go through that re-design in experimental distros, not in mainstream distros. The way I understand what happened with Fedora, management at RedHat decided that they weren't willing to be patient enough for systemd to happen in an experimental distribution. I have read where some of the open desktop community have expressed the opinion that the changes were going to be too hard to push through if we relied on proper engineering techniques. Or, in other words, they had come to the conclusion that they would have to force everybody to do things the right way, to get people to give up their old ways of doing things. That's the best way I can paint that. This is the background. Does this help explain why what appears to some as mere turf battles and childish name-calling, etc., is a bit more than playground antics? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNC0aL=y6dnjvhtncjgyjip4totctsb-aclqyaefgm...@mail.gmail.com
Re: Does Debian still have a systemd-must-die metapackage?
On Wed, Oct 22, 2014 at 7:41 AM, Steve Litt wrote: > Does Debian still have a systemd-must-die metapackage, and does it > still work in Jessie? >From Thorsten: https://lists.debian.org/debian-devel/2014/06/msg00521.html And Andrei noted: https://lists.debian.org/debian-devel/2014/06/msg00587.html And the discussion continued from there. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iow0d3qkcpmdbq8yg_qcclhjsfpj6xhmf65zle6pcb...@mail.gmail.com
Re: Error code 1...........
2014/10/23 12:57 "Charles Kroeger" : > > On Tue, 21 Oct 2014 11:30:02 +0200 > Charlie wrote: > > > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > When I encountered this error (which was mentioned on this list a few > > > days ago) I purged the linjpeg-turbo-progs package (on which > > > apparently nothing depended because it went without complaint) and > > > then resumed my upgrade; the error went away. But maybe that's not the > > > "right" way to do it. > > I get a code (1) on every dist-upgrade for some time now..maybe two weeks, can't > remember but if I run: > > apt-get -f install > > apt-get goes on to setup the packages it downloaded. > > If the dist-upgrade message says it it going to remove a lot of packages I run > instead: > > apt-get -u upgrade > > I continue this command until a dist-upgrade returns to sanity. Probably a meaningless suggestion, but have you tried apt-get clean ? -- Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Problem with systemd-sleep in Jessie
2014/10/24 9:57 "~Stack~" : > > Greetings, > > I have been running Jessie i386 on a spare laptop just so I can see how > all the big changes that are coming will impact me. For the last few > months, nothing too big has really hit me (at least none that don't have > a bug filed already). Well, that is until now. > > I think I last booted/updated this laptop last weekend. I booted it up > tonight to mess around on it and the first thing, as always, was to run > updates. A bunch of systemd stuff updated. Now the laptop is dang near > unusable. > > It boots and it will sit at the log in screen for quite some time like > everything is good and happy. If I log in either via GUI (LXDE) or via > command line, the laptop goes to sleep anywhere between 2 and 15 seconds > later. CLI? From a virtual (CTRL-ALT-fN) terminal? > I have to hit the power button (no other button on the laptop is > responsive) and it will wake up again but promptly go back to sleep 2-15 > seconds later. And repeat. > > It took me over a minute simply trying to log in via the CLI just run a > 'tail -f /var/log/syslog' because for whatever reason it really just > wants to go to sleep. The only thing that I really see is a line that reads: > systemd-sleep: suspending session > > Nothing before it of any consequence, and after is just logs about the > system going into sleep mode. > > So I have been digging around trying to figure out what is going on and > I can't seem to stop it. Here is what I know: > > * There is nothing in the /etc/systemd/sleep.conf file. > * It is technically going into a suspend. > * I have no idea what dictates how long it will last before going back > to sleep. > * I tried to reinstall systemd with no luck (that took forever...when it > takes 3-5 seconds for NetworkManger to bring up the wireless connection > and the window for activity is 2-15 seconds...well I am kinda surprised > I didn't jack up the install when it went to sleep in the middle of the > install...twice!). > * Unless I have something specific to search for, the system logs are > worthless because they are _flooded_ with the information about > going-to/waking-up-from sleep. > > I haven't really figured out systemd yet but I am not making much > progress with online searching at the moment. > > Can anyone help me figure out how to stop systemd from trying to go to > sleep all the time? This is quite annoying... > > Thank you! > ~Stack~ > I'd suspect something in power management, maybe, but who knows? Is sshd running so you could try logging in from the network? If it doesn't go to sleep when logged in from the network, that would be a data point. And, assuming the translating from binary to text didn't get in the way, it would allow you to do a looped tail on the log files to try to watch while you logged in from the keyboard. Of course, having another user logged in might trigger the "Can't log off while other users are logged." condition, but that would be yet another data point. Or have you tried booting a live image on an external device so you can read the logs at better leisure, grep, etc.? -- Joel Rees
Re: How To Prove Systemd Can|Cannot Be Jessie Default
2014/10/24 0:45 "David L. Craig" : > > On 14Oct23:0004-0400, Charles Kroeger wrote: > > > Is that your idea of letting the code speak for itself? > > The code speaks when its execution reveals a need to > run reportbug (or not). When we fail to run reportbug, > we muzzle the code and possibly allow that bug to be > part of the Jessie release. Hopefully that is nobody's > idea of a good approach. Also, hopefully everybody is > aware anybody can run reportbug, which simply emails the > bug report to the BTS--no registration is necessary and > formatting the report is quite painless. Please understand that I do not argue with this. If I could afford the hardware to replace my netbook that is no longer portable, or even if my tablet were not locked down and legally driver-hidden, I would be dual booting and probing for bugs in my spare time between classes and on the train. Not that I really have any spare time. > If systemd is the disaster many believe it to be, > its defects should be manifesting as we test systemd > behavior in as many configurations as possible and it > should not be trivial to remediate those arising from > poor software design. This is the attitude that allowed MS-Windows to become a defacto standard, you know. (Please don't tell me I have to unpack that comment. And don't complain that it's innuendo. We are among engineers are we not?) > If you want systemd to not be the default, you need > to prove to the Release Team it is unworthy, and the > only way to do that is to document the defects in the > BTS. > > Is that sufficiently clear? What kind of a question is that? > -- > > May the LORD God bless you exceedingly abundantly! > > Dave_Craig__ > "So the universe is not quite as you thought it was. > You'd better rearrange your beliefs, then. > Because you certainly can't rearrange the universe." Heh. > __--from_Nightfall_by_Asimov/Silverberg_ -- Joel Rees By the waters of Babylon ...
Re: Debian and upstream choices
2014/10/28 20:37 "Chris Bannister" : > > On Mon, Oct 27, 2014 at 08:07:50PM +0100, lee wrote: > > > > The point is that I was right and you were wrong. It wasn't right > > of you to so strongly urge people to "take issues upstream". It's not > > as easy to "faciliate change" as you seem to think. > > Now I know what the following joke means: > > "There is a man on his hands and knees searching around him. A man comes > along and asks what is the problem. He says I've lost 10 dollars, so the "I've lost my linux-based operating system distribution and community." > man bends down and starts helping him look. After a while of futile > searching the man says, hmmm, this isn't getting us anywhere; where did > you lose it. The man replies, Further on up the road, but the light's > better here." > > There's not much debian-user can do about facilitating change whether > upstream is receptive or not. I dunno. That sounds a little cynical to me. -- Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
bc menu files? (Re: Perfect Jessie is something like this...)
On Mon, Oct 27, 2014 at 9:53 PM, Christian Seiler wrote: > [...] > Quite a few packages ship Debian menu files and/or freedesktop.org > .desktop files for the inclusion in menus. For example, bc installs a > Debian menu file. No kidding? (Looking in my menus and not seeing anything bc-ish.) What menus should I be looking in? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iosunp+agwdvztqlzxaxit_g0extztgrl+rpqvmevu...@mail.gmail.com