Who uses calendar(1)? (was: svn commit: r553259 - in head/deskutils/calendar: . files)

[Greg 'groggy' Lehey]

On Monday, 26 October 2020 at  6:59:15 -0700, Cy Schubert wrote:
> In message <20201026030214.GC19841 at eureka.lemis.com>, "Greg 'groggy' Lehey"
> wri
> tes:
>>
>>
>> --Md/poaVZ8hnGTzuv
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>>
>> On Sunday, 25 October 2020 at 18:37:34 -0700, Cy Schubert wrote:
>>> In message <20201026012126.GB19841 at eureka.lemis.com>, "Greg 'groggy' Lehey"
>>> wri
>>> tes:
>>>>> Anticipating the next step: removal of calendar from base, entirely.
>>>>
>>>> It's a bit late for that.  We discussed this at length (too much
>>>> length for some people) on arch@, and we came to the agreement that
>>>> the base calendar(1) is a Good Thing, and only the data files needed
>>>> to go somewhere where they can be shared amongst projects.
>>>>
>>>> FWIW, *all* OSs that I've seen, with the possible exception of
>>>> Microsoft, have calendar(1).  It serves a useful purpose.  What's your
>>>> problem with it?
>>>
>>> The Linux distros I know of don't provide it, even as an optional RPM.
>>
>> The machine I have access to, running Debian Testing, has it
>> apparently as a standard installation.  Nobody on the system had asked
>> for it.  But yes, I was surprised, too.
>
> At $JOB we maintain about 1500 Linux, Solaris and AIX servers, with a few
> Linux and FreeBSD appliances, the remaining 8000 being Windows and a
> growing number of OpenShift containers of which I lost count. The
> workstations are gone, though many of us propeller heads still maintain
> VirtualBox VMs for our own use. (I personally rather use git on a Linux or
> FreeBSD machine than on Windows -- management decision.)
>
> Why I mention all the details above is that my clients never ask for a
> calendar utility. Their contractors who develop containers haven't either.
> That world is gone.

For them, maybe.  You don't say who your clients are, just the
platforms they use.

>>> IMO it's usefulness is questionable, especially with the multitude
>>> of tools that already do the same thing.
>>
>> There is?  I haven't found anything similar.  That was one of the
>> things we discussed on arch@, but we came up empty-handed.  If you
>> could come up with links, that would be very useful.
>
> Today's tools use iCalendar files and protocols.

That sounds like Apple.  Do we have something non-graphic that works
on FreeBSD?  And note that even Apple supplies calendar(1) on Mac OS.

> For me personally I haven't used a calendar on a UNIX system for
> 10-15 years. Personally, I'm more mobile.

Sure, people have different requirements.  There are many (probably
most) people even here who don't use, say, yacc(1), printf(1) or
nm(1), but we still have them in the tree, and some people will
doubtless find them useful.  In the case of calendar(1), we get enough
bug reports to show that it's not at the top of the list of
seldom-used programs.

> The data in calendar(1) were a novelty at one point, not so much any
> more.

That's a different bikeshed.  We've already moved most of that to
ports.  I was specifically talking about calendar(1), not the data
files (not even calendar.freebsd in this context).  But it would be
*really* nice to find a better source of calendar data than the
warmed-over stuff of 30 years ago.

> My vision is a smaller more compact FreeBSD in which groups of
> packages are selected to build a system. I also see a blending of
> pkgbase and ports to provide the end user with something more like
> the Linux server and desktop variations based on groups of
> packages. Selectable profiles if you may.

Hmm, that's a different bikeshed again.  We used to have stuff like
that, a bare-bones FreeBSD system on a single floppy.  Maybe something
like that would be of use to more people than just you.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20201027/923e15ca/attachment-0001.sig>