Debian decides on systemd—for now
Debian decides on systemd—for now
Posted Feb 13, 2014 16:06 UTC (Thu) by pizza (subscriber, #46)In reply to: Debian decides on systemd—for now by rsidd
Parent article: Debian decides on systemd—for now
So this is why OpenSSH has what is effectively a permanent fork solely dedicated to porting OpenSSH to anything/everything other than openbsd?
You have chosen a pretty poor example of a champion of portability.
Posted Feb 13, 2014 16:38 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (6 responses)
Posted Feb 13, 2014 17:44 UTC (Thu)
by pizza (subscriber, #46)
[Link] (5 responses)
(and that information is also on the Portable OpenSSH webpage, FYI. Maybe you need to take your own advice?)
Meanwhile; A simple "you are incorrect, this is why" reply would have sufficed, without resulting to "hater" insults that accomplish nothing but make you look like an imbecile.
But I digress.
Theo De Raat has done (and continues to do) many great things for the Free Software community. He is many things, but a champion of interoperability is not one of them.
Posted Feb 13, 2014 17:59 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (4 responses)
Posted Feb 13, 2014 20:59 UTC (Thu)
by khim (subscriber, #9252)
[Link]
I think you've set some kind of record. You've talken a project with a very-well documented history publicly avalaible on it's web site and you try to construct some kind of alternate reality on another public web site. Don't you think that it's… well… too much? Please go and read about OpenSSH history! Then you'll find out that you should question not the existence of OpenSSH-portable, but the existence of OpenSSH proper! Before OpenBSD and Theo involvement OSSH supported at least the following environments: OpenBSD developers initially had zero interest in supporting these other environments, they removed all the the kludges (which were needed to support that zoo) in their efforts to cleanup the code and went with “OpenBSD-only” approch. Theo himself is listed as guy who removed these non-portabilities which made the code harder to read (but which were required to support wide range of non-completely-standard-OSes). Since these versions had many features which original version lacked various non-OpenBSD groups got very, very interested. After that Damien Miller, Philip Hands, and handful of others started porting OpenSSH to Linux and various other Unix operating systems. Note: Theo is surprisingly missing even if he was featured prominently in the first, “OpenBSD-only”, version. This is not something I've cooked up from some random sources, it's all written right there, on the web site of OpenSSH itself! I'm pretty sure if various non-OpenBSD will become very, very interested in systemd then people (not necessarily Lennart) will be able to create portable systemd fork. Indeed, nosh can be considered a kernel for such an effort—but I just don't see interest from various BSDs, MINIXes and QNXes in such a fork.
Posted Feb 13, 2014 21:30 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
But back to my original point.
If anything, Theo is more of a poster child for "my way or the highway" and "I don't care about implications for other systems, I'm making mine the best there is" attitudes than is attributed (often deservedly) to Pottering, and that attitude has helped make OpenBSD what it is today.
OpenBSD's kernel (and libc) is a world unto itself; anything that interacts with the kernel isn't even portable to the other BSDs, much less Linux. (And why should it? I don't say this as criticism; they are doing what they want, for their own goals, and appear to be successful)
Meanwhile, OpenBSD is only relevant to the vast majority of Linux users (and distributions) due to it being the upstream of Portable OpenSSH and the occasional security problem the OpenBSD folks find in 3rd-party software.
So, please, explain how Theo is an advocate of portability, and how his attitude (and practice) is different/better than Lennart's -- Because on the face of it, Lennart seems to come out on top in such a comparison.
Posted Feb 14, 2014 1:43 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Feb 14, 2014 13:39 UTC (Fri)
by pizza (subscriber, #46)
[Link]
In areas where they are not forced work with the outside world (eg kernel+libc, syscall interface, system configuration, and even the userspace ABI) they are completely non-portable (even when only compared to other BSDs) and non-standards compliant (unless you consider themselves to be compliant with themself).
(Nevermind you're trying to draw a comparison between a by-definition interoperable network service and something that *launches* network services. Apples and oranges...)
So, two of three of your items are irrelevant, you just now added a fourth ("interoparability") which is equivalent to the first two (and still irrelevant), and the third has been demonstrated to be completely false using the very documentation you accused me of not reading.
Even if one accepts your attempt to move the goalpoasts, you still haven't supported your original assertion that Theo de Raat (and the other core OpenBSD developers) are more dedicated to "standards, compatibility, and interoperability" than the systemd developers.
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
386BSD 0.1; i386
AIX 3.2.5, 4.1; RS6000, PowerPC
BSD 4.4; several platforms
BSD/OS 1.1, 2.0.1; i486
BSD/386 1.1; i386
ConvexOS 10.1; Convex
DGUX 5.4R2.10; DGUX
FreeBSD 1.x, 2.x; Pentium
HPUX 9.0x, 10.0; HPPA
IRIX 5.2, 5.3; SGI Indy
IRIX 6.0.1; Mips-R8000
Linux 1.2.8 Slackware 2.1.0; i486
Mach3; Mips
Mach3/Lites; i386
Machten 2.2
NetBSD 1.0A; Pentium, Sparc
OSF/1 3.0, 3.2, 3.2a; Alpha
Sequent Dynix/ptx 3.2.0 V2.1.0; i386
SCO Unix; i386 (client only)
SINIX 5.42; Mips R4000
Solaris 2.3, 2.4; Sparc
Sony NEWS-OS 3.3 (BSD 4.3); m68k
SunOS 4.1.2, 4.1.3, 4.1.4; Sparc
SysV 4.x; several platforms
Ultrix x.x; Mips
Unicos 8.0.3; Cray C90Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now