[PATCH 0/3] less: display ANSI colors with option -R
I am not really convinced about the size of the "Add -R" hunk as it costs ~300b which is a bit too much for my taste. Anyone up to rephrase/redo this? This sounds more like it should fit into <150b ;) The whole thing was provoked by some systemd ctrl script outputting color sequences, btw. Bernhard Reutner-Fischer (3): less: use esc positive instead of esc normal less: Add -R less: Clear search-highlight if no matches miscutils/less.c | 57 +++- 1 file changed, 44 insertions(+), 13 deletions(-) -- 1.8.5.2 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Tue, Jan 21, 2014 at 6:58 PM, Bernhard Reutner-Fischer wrote: > I am not really convinced about the size of the "Add -R" hunk as > it costs ~300b which is a bit too much for my taste. Anyone up to > rephrase/redo this? This sounds more like it should fit into <150b ;) > > The whole thing was provoked by some systemd ctrl script outputting > color sequences, btw. It is not okay in Unix to pipe escape sequences to a non-tty stdout. I don't think the rest of Unix world needs to accommodate it. Pottering's attempts to force his crap down our throats have to be called out and resisted. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On 23 January 2014 11:01:05 Denys Vlasenko wrote: On Tue, Jan 21, 2014 at 6:58 PM, Bernhard Reutner-Fischer wrote: > I am not really convinced about the size of the "Add -R" hunk as > it costs ~300b which is a bit too much for my taste. Anyone up to > rephrase/redo this? This sounds more like it should fit into <150b ;) > > The whole thing was provoked by some systemd ctrl script outputting > color sequences, btw. It is not okay in Unix to pipe escape sequences to a non-tty stdout. I don't think the rest of Unix world needs to accommodate it. Pottering's attempts to force his crap down our throats have to be called out and resisted. :) Fix systemd then. But apart from that I'd like to have a less that can display colors. Sent with AquaMail for Android http://www.aqua-mail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
>But apart from that I'd like to have a less that can display >colors. Me, too! -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On 2014-01-23 19:28, Bernhard Reutner-Fischer wrote: Fix systemd then. systemd is broken by design. The only way to fix it is to scrap it and design another, non-broken init system from the ground up. And it has already been done, several times. (By me, among others.) But apart from that I'd like to have a less that can display colors. Going down the slippery slope of rich text formatting usually ends up in implementing a full HTML parser. :P -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Thu, Jan 23, 2014 at 9:32 PM, Laurent Bercot wrote: > On 2014-01-23 19:28, Bernhard Reutner-Fischer wrote: >> >> Fix systemd then. > > > systemd is broken by design. I did not look too deeply into its design. Unless there are serious design flaws I am not aware of, the idea per se looks sensible. Admit it - "traditional" SysV init is neanderthal. Not merely "simple" (that's not a bad thing!) - but awkward too. My objection to Pottering's onslaught on Linux is not on the basis that he writes buggy code. My objection is that he tends to write *monolithic* code. systemd requires dbus. systemd includes logging daemon. I see a pattern here: if you want to use daemon A (or *have to use* it for whatever reason), you must also use B, C, and D. It goes farther than that. Some things don't merely live in tools which systemd requires (e.g. dbus). A lot of crap is _in systemd_! # ldd `which systemd` linux-vdso.so.1 => (0x7fff825fe000) libselinux.so.1 => /lib64/libselinux.so.1 (0x7fca4f97c000) libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x7fca4f778000) libudev.so.1 => /lib64/libudev.so.1 (0x7fca4f566000) ^ libwrap.so.0 => /lib64/libwrap.so.0 (0x7fca4f35b000) ^ libpam.so.0 => /lib64/libpam.so.0 (0x7fca4f14d000) libaudit.so.1 => /lib64/libaudit.so.1 (0x7fca4ef28000) libcap.so.2 => /lib64/libcap.so.2 (0x7fca4ed23000) libkmod.so.2 => /lib64/libkmod.so.2 (0x7fca4eb0e000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x7fca4e8c8000) librt.so.1 => /lib64/librt.so.1 (0x7fca4e6c) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fca4e4aa000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7fca4e28d000) libc.so.6 => /lib64/libc.so.6 (0x7fca4decd000) /lib64/ld-linux-x86-64.so.2 (0x7fca4fec3000) libpcre.so.1 => /lib64/libpcre.so.1 (0x7fca4dc6f000) libdl.so.2 => /lib64/libdl.so.2 (0x7fca4da6a000) libnsl.so.1 => /lib64/libnsl.so.1 (0x7fca4d851000) libattr.so.1 => /lib64/libattr.so.1 (0x7fca4d64c000) liblzma.so.5 => /lib64/liblzma.so.5 (0x7fca4d426000) libz.so.1 => /lib64/libz.so.1 (0x7fca4d21) What the hell *TCP wrappers* or *udev* have to do with *init binary*? He either does not understand why modularity is good, or *likes* that his approach makes distributions use more of the software developed by his team. Another troubling aspect is gratuitous changes. Like the one we see here: BAM! and he started feeding **ANSI color escapes to a pager via pipe!**. "Just because I can, if your pager doesn't understand it, your problem". I talked to him about it. He is not listening. I'm telling you: this is not an oversight. That's *his idea of how software should be developed*. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
Am 23.01.2014 21:32, schrieb Laurent Bercot: > On 2014-01-23 19:28, Bernhard Reutner-Fischer wrote: >> Fix systemd then. > > systemd is broken by design. The only way to fix it is to scrap it > and design another, non-broken init system from the ground up. And > it has already been done, several times. (By me, among others.) > > >> But apart from that I'd like to have a less that can display colors. > > Going down the slippery slope of rich text formatting usually ends up > in implementing a full HTML parser. :P > Tex seems a more sophisticated system ;) re, wh ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Thu, Jan 23, 2014, at 21:28, Bernhard Reutner-Fischer wrote: > On 23 January 2014 11:01:05 Denys Vlasenko > > Pottering's attempts to force his crap down our throats have to be > > called out and resisted. > > :) > Fix systemd then. > But apart from that I'd like to have a less that can display colors. Another "me too". Colors in less are useful with git etc, systemd doesn't have to have something to do with it. - Lauri -- http://www.fastmail.fm - Does exactly what it says on the tin ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
>> But apart from that I'd like to have a less that can display >> colors. > >Another "me too". Colors in less are useful with git etc, systemd >doesn't have to have something to do with it. ... to clarify my "me too". I do not use systemd. I like to create colored file lists and colored log lists to be viewed with a pager. A simple textual pager, not a full fledged HTML Browser or even text processor. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Fri, Jan 24, 2014 at 07:16:13AM +0100, Denys Vlasenko wrote: > On Thu, Jan 23, 2014 at 9:32 PM, Laurent Bercot > wrote: > > On 2014-01-23 19:28, Bernhard Reutner-Fischer wrote: > >> > >> Fix systemd then. > > > > > > systemd is broken by design. > > I did not look too deeply into its design. > Unless there are serious design flaws I am not aware of, > the idea per se looks sensible. The idea is not sensible. If I find time I'll write a short article on why for ewontfix, but it basically amounts to: 1. Crash in pid #1 brings down the whole system, so it's not acceptable to do anything complex in pid 1. 2. Inability to upgrade all the functionality that's been moved into systemd without rebooting, due to the inability to kill and restart pid #1. This cannot be fixed robustly even if systemd execs its own new version due to certain technical issues (there are cases when it might fail and thereby bring down the whole system, see point 1). 3. Massive attack surface for a privileged process due to the public (dbus-based) interface it exposes. This is an unacceptable security risk. A lot of the things systemd wants to achieve are correct (e.g. correct process lifetime management for daemons rather than racy pid files, clean race-free device insertion and removal handling, ...) but it's wrong to put them in the init process. They all can (and most already have) been handled in the past by other modular tools. The latter did not fail to catch on due to technical deficiencies but due to extremely conservative distro and admin policies and the lack of a Poettering-level propaganda machine attempting to force people to switch. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Sun, Feb 2, 2014, at 17:56, Rich Felker wrote: > > > systemd is broken by design. > > > > I did not look too deeply into its design. > > Unless there are serious design flaws I am not aware of, > > the idea per se looks sensible. > > The idea is not sensible. If I find time I'll write a short article on > why for ewontfix, but it basically amounts to: > > 1. Crash in pid #1 brings down the whole system, so it's not > acceptable to do anything complex in pid 1. I fully agree with your mail. FWIW, when I made point 1 in the past, their response was that since they catch all signals (including segv, ill), systemd will happily not crash, but go on its merry way. This of course completely ignores that it cannot fix whatever caused the error, and may go on to do wildly incorrect things due to it. - Lauri -- http://www.fastmail.fm - mmm... Fastmail... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] less: display ANSI colors with option -R
On Sun, Feb 02, 2014 at 08:46:44PM +0200, Lauri Kasanen wrote: > On Sun, Feb 2, 2014, at 17:56, Rich Felker wrote: > > > > systemd is broken by design. > > > > > > I did not look too deeply into its design. > > > Unless there are serious design flaws I am not aware of, > > > the idea per se looks sensible. > > > > The idea is not sensible. If I find time I'll write a short article on > > why for ewontfix, but it basically amounts to: > > > > 1. Crash in pid #1 brings down the whole system, so it's not > > acceptable to do anything complex in pid 1. > > I fully agree with your mail. FWIW, when I made point 1 in the past, > their response was that since they catch all signals (including segv, > ill), systemd will happily not crash, but go on its merry way. This of > course completely ignores that it cannot fix whatever caused the error, > and may go on to do wildly incorrect things due to it. Well in principle it could re-exec itself from the signal handler, but that brings us to my point 2: doing that is not robust. I don't even think execve is entirely atomic with respect to success/failure at the kernel level (e.g. it can fail to map the new VM after destroying the old one due to resource exhaustion) but even if the kernel were careful and allocated the new VM fully before destroying the old one and atomically replacing it, there are fatal errors that can occur before the program takes control after exec, at least in the dynamic-linked case (allocation, mmap, etc. failures in the dynamic linker). With musl we can guarantee no such prior-to-entry failures exist for the static-linked case (except when thread-local storage is used and allocation is needed to satisfy it), but glibc and uclibc do not make such a guarantee as far as I know (and systemd wants to be dynamic linked anyway). Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
systemd bashing (man it feels good) (was: [PATCH 0/3] less: display ANSI colors with option -R)
On 2014-01-24 06:16, Denys Vlasenko wrote: Admit it - "traditional" SysV init is neanderthal. Not merely "simple" (that's not a bad thing!) - but awkward too. Oh, I totally agree - I wrote s6, remember ? And I'm so much more interested in getting the design and the code right than in seeing it widely adopted that I didn't even take the time to promote it - just the opposite of Lennart - which is obviously a huge oversight. systemd was so obviously inane and insane to me that I didn't even consider it could make it that big. My objection to Pottering's onslaught on Linux is not on the basis that he writes buggy code. My objection is that he tends to write *monolithic* code. systemd requires dbus. systemd includes logging daemon. That's exactly what I meant by "broken by design". See http://skarnet.org/software/s6/why.html and http://skarnet.org/software/s6/s6-svscan-not-1.html#systemd :) Lennart's quest for change disregards not only the current conventions (which is not a bad thing to do per se), but also the most basic software design principles as well as the core of the Unix philosophy. This guy should apply at Microsoft, they'd love him there. It goes farther than that. Some things don't merely live in tools which systemd requires (e.g. dbus). A lot of crap is _in systemd_! (...) What the hell *TCP wrappers* or *udev* have to do with *init binary*? (...) Amen, brother, amen. But I'm afraid you and I will be preaching to the choir here. It's not the busybox mailing-list that we need to convince, it's the major Linux distributions. I have no idea how a piece of software that I wouldn't give a D to as an undergraduate student project made it into Fedora and Arch Linux, is threatening the whole GNU ecosystem, and is making countless people waste countless hours trying to integrate it while keeping a pretense of modularity. I'm not good at advocacy - waging political wars is bothersome and tiresome to me, and writing good code is a much better use of my time. But someone who is, and who has a tiny bit of sense of what good engineering is, should definitely step up and expose the systemd fraud, and I'm all willing, as I'm sure you are, to provide the detailed technical arguments. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
