For the record, I personally am probably in favor of deleting this project, unless we are going to update it. (Updating it from FreeBSD might not be a terrible idea.) Conceptually the ideas behind this don’t seem to fit with more modern practice, and there are far better calendaring solutions available today. (Every major OS has something here, I think, and then there alternatives like Google calendar.)
I’m a little irked about what the double standard would be though, as in the past I’ve tried to propose removing things that were ancient and stale, and in some cases actually created real engineering overheads, but have been significantly thwarted by desires not to remove stuff that “someone” might find useful. For example, the baggage we carry to support the Cassini driver is somewhat large. (In fact we pay multiple penalties for every packet sent through illumos to support the multidata code path that is *only* used by the closed-source cassini driver, as well as the softmac support that is required to support the legacy DLPI provider interface of which cassini is the only remaining implementation, all others having since been converted to GLDv3.) At the end of the day, we don’t have any clear vision of illumos. We have a few companies like Joyent, that are attempting (whether intentionally or not) to direct the vision of illumos, but formally they cannot do that; instead the “vision” has been left up to the whims of the RTI advocates. This isn’t a situation I find wholly satisfying, but my attempts at rectifying it in the past have not been well received. Anyway if the goal here is going to be to start removing stuff based on “stale and unmaintained”, then that represents a change in direction, and I think that we should be explicit about that. Especially since in theory some of that stuff could change that state. (For example, absorbing the FreeBSD version would “fix” the problem instead of just “removing it”. (In case anyone wonders what *my* vision for illumos is, or at least was, it is this. I believe illumos should still strive to be a center of excellence for a POSIX compliant system; I believe we should put that compatibility ahead of other many other considerations, and I believe we should look for ways to minimize what is in -gate, such that the contents of illumos-gate are the core kernel, drivers, libraries, and utilities required to support the POSIX system, plus our unique illumos-specific components (for example, zones, etc.) Most of the other stuff that has no dependencies should IMO be punted from the gate and rolled into separate consolidations (git trees) so that distros can easily pick them up if desired. I believe illumos should also strive to be something that is easy for distributions to pick up and build upon, with as few constraining opinions (for example packaging) as possible. There are a bunch of other things that should happen as consequences of this vision, but which will almost certainly never occur.) Anyway, let’s not discuss “vision” further on this thread — if we want to do that we can do so elsewhere. In all honesty, I’m unlikely to participate if for no other reason than my past negative experiences trying to do so have been at best unproductive, and at times also injurious. — Garrett On Mon, Mar 13, 2017 at 6:08 AM, Peter Tribble <[email protected]> wrote: > > > On Mon, Mar 13, 2017 at 4:43 AM, Garrett D'Amore <[email protected]> > wrote: > >> What’s the motivation for removing it? >> > > It's old, of dubious functionality, and full of bugs. There are > alternatives > that do a much better job. So should we fix it, or remove it and get anyone > who needs something like this to use a better tool instead? > > >> The program isn’t NIS specific, although it is NIS aware (doing ypcat and >> merging that with the password file), and it should function “reasonably” >> well in most environments. (I don’t think it will work in a NIS+ >> environment, but who cares about that.) >> > > Or ldap or AD; although the very concept of trawling through your > entire nameservice looking for users to spame seems rather flawed > IMO. > > >> I don’t use this thing, but reading the man page it looks like it does >> still have some useful purpose. >> >> I can’t see that keeping this around carries any particular baggage, nor >> do I see where removing it is likely to facilitate other work or reduce >> some sustaining burden elsewhere. Am I mistaken? >> > > Ultimately, it boils down to what your vision for illumos is. Are we > trying to be an exemplar, a project characterized by superior standards > and engineering excellence? > > Or are we a museum full of mouldy old curiosities, where we take our > grandchildren to show them how bad life was when we were young? > > (And yes, the irony of this removal coming from me, possibly the most > retro distributor around, has been pointed out to me.) > > >> On Sun, Mar 12, 2017 at 4:46 AM, Peter Tribble <[email protected]> >> wrote: >> >>> Before I submit this for integration, is anyone actually using >>> the /usr/bin/calendar utility? >>> >>> (Note, this isn't the "cal" command; /usr/bin/calendar is a >>> completely different animal.) >>> >>> ---------- Forwarded message ---------- >>> From: Peter Tribble <[email protected]> >>> Date: Tue, Mar 7, 2017 at 8:33 PM >>> Subject: Review request: 7948 Remove old calendar utility >>> To: illumos-dev <[email protected]> >>> >>> >>> Please review: >>> >>> Issue: https://illumos.org/issues/7948 >>> Webrev: http://pkgs.tribblix.org/webrevs/7948/ >>> >>> A couple of alternatives for distros (and individuals) that might >>> want a replacement are mentioned in the bug report. >>> >>> Thanks, >>> >>> -- >>> -Peter Tribble >>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >>> >>> >>> >>> -- >>> -Peter Tribble >>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >>> >> >> > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > *illumos-discuss* | Archives > <https://www.listbox.com/member/archive/182180/=now> > <https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
