Re: Why does OpenBSD still include Perl in its base installation?
On Tue, May 19, 2020 at 10:19:23PM +0200, Dawid Czeluśniak wrote: > 3. Are there people among this community who think that > the base installation of OpenBSD should not include Perl > and Perl-dependent programs and utilities? I assume there are people in the community who think that OpenBSD should not include a lot of things, fortunately it is not the community who decides what OpenBSD becomes, but instead the developers. > Looking at FreeBSD for a moment it seems like Perl left the > base system in May 2002 (18 years ago)[0]. > In a nutshell the rationale was more or less the following[1]: > > > It appears that having Perl in the base distro has > > the following problems: > > > 1. It increases the distro image size. FreeBSD's minimal iso download is 370M while OpenBSD's is largest install media is 450M, however if you are looking for a more minimal install of OpenBSD, you can ~10M cd67.iso and avoid a little bit by only installing the absolutely necessary sets. https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/ http://ftp.openbsd.org/pub/OpenBSD/6.7/amd64/ In my opinion, the things that OpenBSD includes in the base system provide an excellent trade-off between size and utility. 18 years ago, an extra 60M of installed files may have made a difference. These days, it's insignificant. > > 2. It forces everyone to use the same version of Perl. It forces everyone to use the same default version of perl, and in exchange promises working packages for programs written in perl. There are several ways to manage having additional versions of perl installed if you need them. Both perlbrew and plenv come to mind. https://perlbrew.pl/ https://github.com/tokuhirom/plenv > > 3. If someone tries to install over that version or just even patch it, > > it can break stuff in BSD which needed the old version. I patch the in-base perl regularly, both breaking stuff and not. Not knowing what you're doing is a not only a great way to learn, but also a great way to break stuff. > > 4. Installing multiple copies imposes weird symlink tricks > > or else breaks other stuff. See above for some ways to do this that work really well, these days that's mostly a solved problem, but it does require both reading and understanding. > All comments and opinions are appreciated. Thanks! Oh good. Perl fits a really important niche between shell scripts and C, its combination of "whipupitude" and "manipulexity" make it great for a large range of tasks. While there are now several languages that also fit into that space, choices between them boil down to personal preference and momentum. The fact that there are so many lines of perl doing the amazingly complex work of managing the package system means that it is here to stay. Unix is full of text streams and having a tool available that excels at processing text is a significant benefit to the OpenBSD base system. Having perl in base was one of the things that brought me joy when I started using OpenBSD and it continues to bring me joy. > [0] https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html Being the OpenBSD "Perl5 guy", I consider keeping OpenBSD's "base perl" up to date well worth the effort and don't think it is a significant amount of work. There has been some headway by the perl5-porters in removing things from the perl core. Go see the last few upgrade guides where there are instructions on deleting the modules that have been removed. FreeBSD's incompatibility with the Perl 5 release cycle, where Perl gets security updates for the current and previous release, would have meant that the maintainer there would need to do significant work to backport fixes to several old versions of perl. That can be "hellish", but fortunately OpenBSD does not have that particular problem. Fortunately, I can count the number of backwards incompatible changes to Perl since I've been using it on one hand, so importing those new versions into OpenBSD is generally the work of only a few days, most of which turns out to be uneventful testing that things still work. > [1] https://bsd.slashdot.org/comments.pl?sid=32564&cid=3513689 See above. l8rZ, -- andrew - http://afresh1.com I wish life had an UNDO function.
Re: Thinkpad X1 5th Gen Microphone
On Thu, May 21, 2020 at 11:31:21PM +0200, zeurk...@volny.cz wrote: > IIRC, at least some Thinkpads have BIOS options for "sensitive" stuff > like a microphone. Tried looking there? Yeah I did. Mic is enabled. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Thinkpad X1 5th Gen Microphone
Hi, On Thu, May 21, 2020 at 08:22:46PM +0200, Eric Auge wrote: > forgot to ask in my previous mail but did you check your sndioctl settings? > $ sndioctl > input.level=0.494 > input.mute=0 > output.level=1.000 > output.mute=0 > app/aucat0.level=1.000 > app/aucat1.level=1.000 > app/mumble0.level=1.000 > app/mumble1.level=1.000 I had a fiddle with those, but I think mixerctl exposes all of those (albeit under different names) apart from the app-specific controls. By the way, in your previous mail you had master muted. I loaded your exact settings, unmuted master, and still nothing. I think the next step is to try some linux usb image and see if it works there. If not, I'm suspecting hardware. I know that a Lenovo engineer has had this machine open when they recalled the machine due to some dangerous battery-related something or other. I wonder if they forgot to plug something in... Anyway, thanks for your help -- much appreciated. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Select ssh key from ssh-agent?
Folks, I’m not sure this is the right place to ask, but I hope someone can point me in the right direction. When using ssh with keys that are in files on the local host, you can specify which key is used for the connection by using the -i option and giving the path to the key file. However, if you are loading multiple keys into ssh-agent and forwarding keys to other hosts, there doesn’t seem to be a way to select which key will be presented to the destination by the ssh client. The -i option does not find the original key file of course (since it’s on another machine) and there doesn’t seem to be an option to tell ssh-agent which key to present. The particular case I’m working with is using git with bitbucket.org, where user accounts are identified by the key. I have two accounts that have two different keys, and when I’m logged into another server via ssh I can only access one BitBucket account since that’s the one whose keys ssh-agent presents first. I can think of a couple of workarounds, but I also wanted to see if I’m missing something. —Paul smime.p7s Description: S/MIME cryptographic signature
Re: Thinkpad X1 5th Gen Microphone
forgot to ask in my previous mail but did you check your sndioctl settings? $ sndioctl input.level=0.494 input.mute=0 output.level=1.000 output.mute=0 app/aucat0.level=1.000 app/aucat1.level=1.000 app/mumble0.level=1.000 app/mumble1.level=1.000 Cheers, HTH, Eric. On Thu, May 21, 2020 at 5:03 PM Eric Auge wrote: > > re, > > just to be sure, I tried aucat | aucat .. and mumble both are fine and > I can record (low volume though as you can see, it was just to answer > your email for 5th gen...) > > # mixerctl -a : > inputs.dac-0:1_mute=on > inputs.dac-0:1=204,204 > inputs.dac-2:3_mute=on > inputs.dac-2:3=204,204 > inputs.beep=108 > record.adc-2:3_source=mic > record.adc-2:3_mute=off > record.adc-2:3=126,126 > record.adc-0:1_source=mic2 > record.adc-0:1_mute=off > record.adc-0:1=126,126 > outputs.hp_source=dac-0:1 > outputs.hp_boost=off > outputs.hp_eapd=on > outputs.spkr_source=dac-2:3 > outputs.spkr_eapd=on > inputs.mic=85,85 > outputs.mic_dir=input-vr80 > inputs.mic2=85,85 > outputs.hp_sense=unplugged > outputs.mic_sense=unplugged > outputs.spkr_muters=hp > outputs.master=206,206 > outputs.master.mute=on > outputs.master.slaves=dac-0:1,dac-2:3 > record.volume=126,126 > record.volume.mute=off > record.volume.slaves=adc-2:3,adc-0:1 > record.enable=sysctl > > > HTH, > Eric. > > On Thu, May 21, 2020 at 3:01 PM Edd Barrett wrote: > > > > Hi Eric, > > > > On Thu, May 21, 2020 at 12:50:36PM +0200, Eric Auge wrote: > > > Hello Edd, > > > > > > All good here, microphone works fine, once I enable recording: > > > sysctl kern.audio.record=1 > > > > Can you share your output of `mixerctl -a` please so that I can diff it > > with mine? > > > > -- > > Best Regards > > Edd Barrett > > > > http://www.theunixzoo.co.uk
Re: Mounting microSDHC
On 2020-05-21, Robert wrote: > On Thu, 21 May 2020 16:31:22 +0100 > Maurice McCarthy wrote: > >> Maybe depends whether it is on usb or pci. Have a look at >> >> $ pkg_info pcsc-tools >> > > I had a similar issue long ago (don't remember the exact hardware > setup). > The solution was to have a card in the slot when booting the machine; > otherwise it would not be detected. Afterwards it was possible to > insert different cards. > > /Robert > > Try that. And send a dmesg.
Re: Why does OpenBSD still include Perl in its base installation?
Hi David, Dawid Czelu?niak wrote on Tue, May 19, 2020 at 10:19:23PM +0200: > I am a huge fan of minimal and custom installations > as I mostly use OpenBSD to host simple HTTP servers. That's perfectly fine. These days, we consider the "minimal installation" the base file sets, including xbase. If you want, you can leave out the game file set and the other x* file sets, but it makes maintenance significantly harder for no benefit. Your choice, really. > I basically use vi to edit httpd.conf file, Sure. How else? I think almost everybody used vi(1) or mg(1) for that. > obtain a certificate from Let's Encrypt using built-in acme-client, > then start the server and things just work. Sure. That's exactly the same way as i'm maintaining machines like man.openbsd.org and mandoc.bsd.lv, too. > I was wondering if I need the package manager in the minimal > installation of the system as I only use built-in deamons (httpd, sshd) > and UNIX utilities (vi, sed)? By package manager I mean > pkg_* executables as well as its dependencies (most notably Perl). > (The size of /usr/libdata/perl5 is about 50MB on my machine). > I just want the minimal installation without any unnecessary > scripting language. One way to achieve that could be > to manually remove pkg_* executables and Perl from a machine, > but it can easily end up with the broken system especially when > done by unexperienced users. I can confirm that. Removing files that come with base in order to make base smaller is a bad idea. It tried that 20 years ago when i already had several years of experience with various flavours of Unix, and yet i consistently ended up with systems broken in one way or another. I did have a moderately good reason back then: i needed to run OpenBSD (around 2.6 to 2.8 times) on a i386 machine that only had 200 MB of disk space. Even then, that reason was only moderately good; buying an additional disk of 4 GB would not have been very expensive back then, so that would probably have been the most reasonable choice. But i did not want to spend money on that machine, so i chose to, instead of installing any file sets, to hand-pick the files i wanted, one by one. That way, i did actually get a working system, and i used it in production for a number of years, doing several upgrades in the same way. I learnt quite a bit about the purposes of various files in the process. I never asked anyone for help with it. Repeating such a stunt today would be quite pointless. A 20GB disk is more than sufficient for doing a base install, and you will have problems to find a 20GB disk even in the trash. The disks you will readily find in the trash are typically at least ten times larger nowadays. > But then I thought about > the second possible way: why not to extract pkg_* executables > and Perl to the separate file set (pkgXX.tgz)? As others said, absolutely not going to happen. I think having fewer sets might provide some benefits, but splitting sets would be a waste of time and asking for trouble. Yours, Ingo
Re: Mounting microSDHC
On Thu, 21 May 2020 16:31:22 +0100 Maurice McCarthy wrote: > Maybe depends whether it is on usb or pci. Have a look at > > $ pkg_info pcsc-tools > I had a similar issue long ago (don't remember the exact hardware setup). The solution was to have a card in the slot when booting the machine; otherwise it would not be detected. Afterwards it was possible to insert different cards. /Robert
Re: Mounting microSDHC
Maybe depends whether it is on usb or pci. Have a look at $ pkg_info pcsc-tools
Re: Thinkpad X1 5th Gen Microphone
re, just to be sure, I tried aucat | aucat .. and mumble both are fine and I can record (low volume though as you can see, it was just to answer your email for 5th gen...) # mixerctl -a : inputs.dac-0:1_mute=on inputs.dac-0:1=204,204 inputs.dac-2:3_mute=on inputs.dac-2:3=204,204 inputs.beep=108 record.adc-2:3_source=mic record.adc-2:3_mute=off record.adc-2:3=126,126 record.adc-0:1_source=mic2 record.adc-0:1_mute=off record.adc-0:1=126,126 outputs.hp_source=dac-0:1 outputs.hp_boost=off outputs.hp_eapd=on outputs.spkr_source=dac-2:3 outputs.spkr_eapd=on inputs.mic=85,85 outputs.mic_dir=input-vr80 inputs.mic2=85,85 outputs.hp_sense=unplugged outputs.mic_sense=unplugged outputs.spkr_muters=hp outputs.master=206,206 outputs.master.mute=on outputs.master.slaves=dac-0:1,dac-2:3 record.volume=126,126 record.volume.mute=off record.volume.slaves=adc-2:3,adc-0:1 record.enable=sysctl HTH, Eric. On Thu, May 21, 2020 at 3:01 PM Edd Barrett wrote: > > Hi Eric, > > On Thu, May 21, 2020 at 12:50:36PM +0200, Eric Auge wrote: > > Hello Edd, > > > > All good here, microphone works fine, once I enable recording: > > sysctl kern.audio.record=1 > > Can you share your output of `mixerctl -a` please so that I can diff it > with mine? > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk
Mounting microSDHC
I'm trying to mount a SanDisk Ultra microSDHC. My laptop -- HP Envy 13 -- has a slot for it. But upon pluggin in, there is no device recognized, and dmesg doesn't show anything. I understand sdhc(4) should take care of this, but that's all I know. Any pointers?
Re: Why does OpenBSD still include Perl in its base installation?
You are on your own. You knew that would be the answer. Be happy about it. Dawid Czeluśniak wrote: > Hi OpenBSD community, > > First of all, thank you for 6.7 release. > > I am a huge fan of minimal and custom installations > as I mostly use OpenBSD to host simple HTTP servers. > I basically use vi to edit httpd.conf file, > obtain a certificate from Let's Encrypt using built-in acme-client, > then start the server and things just work. > > I was wondering if I need the package manager in the minimal > installation of the system as I only use built-in deamons (httpd, sshd) > and UNIX utilities (vi, sed)? By package manager I mean > pkg_* executables as well as its dependencies (most notably Perl). > (The size of /usr/libdata/perl5 is about 50MB on my machine). > I just want the minimal installation without any unnecessary > scripting language. One way to achieve that could be > to manually remove pkg_* executables and Perl from a machine, > but it can easily end up with the broken system especially when > done by unexperienced users. But then I thought about > the second possible way: why not to extract pkg_* executables > and Perl to the separate file set (pkgXX.tgz)? > In this way, people who are not going to use the package manager > could just simply not install it. Moreover, it could break > the base installation free from the heavy dependence on Perl. > > I would like to get your opinion on that. > > So the questions to the OpenBSD community are the following: > > 1. Is it possible, from the technical point of view, to extract > pkg_* utilities, perlutil(1), any other Perl-dependent code > and Perl itself from baseXX.tgz to the separate file set > so that users that just want the *minimal* installation of OpenBSD > don't have to remove it manually? > > 2. Are there any other programs in the baseXX.tgz file set > that depend on Perl other than: > - pkg_* utilities > - perlutil(1) (rather obvious) > - fw_update(1) > - adduser(8) (adduser and rmuser utilities) > - vi.recover script > - cvs contrib scripts > > 3. Are there people among this community who think that > the base installation of OpenBSD should not include Perl > and Perl-dependent programs and utilities? > Looking at FreeBSD for a moment it seems like Perl left the > base system in May 2002 (18 years ago)[0]. > In a nutshell the rationale was more or less the following[1]: > > > It appears that having Perl in the base distro has > > the following problems: > > > 1. It increases the distro image size. > > 2. It forces everyone to use the same version of Perl. > > 3. If someone tries to install over that version or just even patch it, > > it can break stuff in BSD which needed the old version. > > 4. Installing multiple copies imposes weird symlink tricks > > or else breaks other stuff. > > All comments and opinions are appreciated. Thanks! > > [0] https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html > [1] https://bsd.slashdot.org/comments.pl?sid=32564&cid=3513689 >
Re: Thinkpad X1 5th Gen Microphone
Hi Eric, On Thu, May 21, 2020 at 12:50:36PM +0200, Eric Auge wrote: > Hello Edd, > > All good here, microphone works fine, once I enable recording: > sysctl kern.audio.record=1 Can you share your output of `mixerctl -a` please so that I can diff it with mine? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Why does OpenBSD still include Perl in its base installation?
On 2020-05-21 09:55, Anders Andersson wrote: >> I am a huge fan of minimal and custom installations >> as I mostly use OpenBSD to host simple HTTP servers. > ... >> I would like to get your opinion on that. > From what I've seen, those goals are not compatible with OpenBSD, as > in: You're just making it harder for you and anyone trying to help > debugging something if you change the default installation. I've seen > some wishes about even getting rid of the whole "sets" thing and just > install everything. I agree and disagree. I agree with the unsupported compatible side, with a big question of why do you want to? I like having a well considered useful base, rather than a million linux kernel/package options. I disagree with OpenBSD being incompatible. Take bsd.rd or single user and a binary and it could be a very small executer atleast. Anyone that has hosed the root fs and and had to fix the shared cache with ldconfig, probably realises that. No idea, why you would want to go that small and not use something like app engine and go though. I guess you could use pledge/unveil if you have all the networking side sorted. I can't see involatile storage as an issue there or anywhere OpenBSD runs though and it's focus on security means updates are fairly infrequent?? p.s. Even app engine uses a fairly big and useful install, before the deploy stage.
Re: Thinkpad X1 5th Gen Microphone
Hello Edd, All good here, microphone works fine, once I enable recording: sysctl kern.audio.record=1 HTH, Cheers, Eric. On Thu, May 21, 2020 at 11:53 AM Edd Barrett wrote: > > Hi, > > I was wondering if anyone has ever gotten a microphone working with the > built-in azalia chipset of a Thinkpad X1 5th gen (either the internal > mic, or a headset)? I've never managed to get it working. > > Default mixerctl settings: > > ``` > inputs.dac-0:1_mute=off > inputs.dac-0:1=198,198 > inputs.dac-2:3_mute=off > inputs.dac-2:3=198,198 > inputs.beep=108 > record.adc-2:3_source=mic > record.adc-2:3_mute=off > record.adc-2:3=126,126 > record.adc-0:1_source=mic2 > record.adc-0:1_mute=off > record.adc-0:1=126,126 > outputs.hp_source=dac-0:1 > outputs.hp_boost=off > outputs.hp_eapd=on > outputs.spkr_source=dac-2:3 > outputs.spkr_eapd=on > inputs.mic=85,85 > outputs.mic_dir=input-vr80 > inputs.mic2=85,85 > outputs.hp_sense=unplugged > outputs.mic_sense=unplugged > outputs.spkr_muters=hp > outputs.master=199,199 > outputs.master.mute=off > outputs.master.slaves=dac-0:1,dac-2:3 > record.volume=126,126 > record.volume.mute=off > record.volume.slaves=adc-2:3,adc-0:1 > record.enable=sysctl > ``` > > With default sndiod flags (i.e. the sole sound card is enabled: rsnd/0), > and of course `sysctl kern.audio.record=1`. Microphone enabled in BIOS. > > Using the "Ratchov method", `aucat -o - | aucat -i -` should echo > microphone input back at you. This works for me on my other machine > using a USB headset with a dedicated DAC. > > I've tried fiddling various knobs: boosting various mic and record > levels, all of the mic_dir enumerations, toggling various mutes in case > they are inverted. Tried it all again with a headset connected. No joy. > > So does it work for someone out there, or is there a bug? > > Cheers -- stay sane! > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk >
Re: Why does OpenBSD still include Perl in its base installation?
On 2020-05-19, Dawid Czeluśniak wrote: > But then I thought about > the second possible way: why not to extract pkg_* executables > and Perl to the separate file set (pkgXX.tgz)? I think it is safe to say this is not going to happen. > 2. Are there any other programs in the baseXX.tgz file set > that depend on Perl other than: > - pkg_* utilities > - perlutil(1) (rather obvious) > - fw_update(1) > - adduser(8) (adduser and rmuser utilities) > - vi.recover script > - cvs contrib scripts libtool /usr/libexec/security
Re: Why does OpenBSD still include Perl in its base installation?
On Thu, May 21, 2020 at 11:19 AM Dawid Czeluśniak wrote: > > Hi OpenBSD community, > > First of all, thank you for 6.7 release. > > I am a huge fan of minimal and custom installations > as I mostly use OpenBSD to host simple HTTP servers. ... > I would like to get your opinion on that. >From what I've seen, those goals are not compatible with OpenBSD, as in: You're just making it harder for you and anyone trying to help debugging something if you change the default installation. I've seen some wishes about even getting rid of the whole "sets" thing and just install everything. I tend to agree and would welcome such a move, because these days we're talking about such a tiny amount of space in comparison. Even if you're in a situation where you want to host thousands of virtual OpenBSD machines and then maybe get some sort of gain from removing those 50 MB, well, just use a CoW filesystem and clone the same base install. What I love with OpenBSD is that everything is just there to be used, there aren't 20 different filesystems, 20 different scripting languages, 20 different web servers. I don't have to fiddle with everything, it just works. There's the file system, perl, httpd, etc, and they are well designed. Why would I want multiple different perls when it is already so mature?
Thinkpad X1 5th Gen Microphone
Hi, I was wondering if anyone has ever gotten a microphone working with the built-in azalia chipset of a Thinkpad X1 5th gen (either the internal mic, or a headset)? I've never managed to get it working. Default mixerctl settings: ``` inputs.dac-0:1_mute=off inputs.dac-0:1=198,198 inputs.dac-2:3_mute=off inputs.dac-2:3=198,198 inputs.beep=108 record.adc-2:3_source=mic record.adc-2:3_mute=off record.adc-2:3=126,126 record.adc-0:1_source=mic2 record.adc-0:1_mute=off record.adc-0:1=126,126 outputs.hp_source=dac-0:1 outputs.hp_boost=off outputs.hp_eapd=on outputs.spkr_source=dac-2:3 outputs.spkr_eapd=on inputs.mic=85,85 outputs.mic_dir=input-vr80 inputs.mic2=85,85 outputs.hp_sense=unplugged outputs.mic_sense=unplugged outputs.spkr_muters=hp outputs.master=199,199 outputs.master.mute=off outputs.master.slaves=dac-0:1,dac-2:3 record.volume=126,126 record.volume.mute=off record.volume.slaves=adc-2:3,adc-0:1 record.enable=sysctl ``` With default sndiod flags (i.e. the sole sound card is enabled: rsnd/0), and of course `sysctl kern.audio.record=1`. Microphone enabled in BIOS. Using the "Ratchov method", `aucat -o - | aucat -i -` should echo microphone input back at you. This works for me on my other machine using a USB headset with a dedicated DAC. I've tried fiddling various knobs: boosting various mic and record levels, all of the mic_dir enumerations, toggling various mutes in case they are inverted. Tried it all again with a headset connected. No joy. So does it work for someone out there, or is there a bug? Cheers -- stay sane! -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Why does OpenBSD still include Perl in its base installation?
Hi OpenBSD community, First of all, thank you for 6.7 release. I am a huge fan of minimal and custom installations as I mostly use OpenBSD to host simple HTTP servers. I basically use vi to edit httpd.conf file, obtain a certificate from Let's Encrypt using built-in acme-client, then start the server and things just work. I was wondering if I need the package manager in the minimal installation of the system as I only use built-in deamons (httpd, sshd) and UNIX utilities (vi, sed)? By package manager I mean pkg_* executables as well as its dependencies (most notably Perl). (The size of /usr/libdata/perl5 is about 50MB on my machine). I just want the minimal installation without any unnecessary scripting language. One way to achieve that could be to manually remove pkg_* executables and Perl from a machine, but it can easily end up with the broken system especially when done by unexperienced users. But then I thought about the second possible way: why not to extract pkg_* executables and Perl to the separate file set (pkgXX.tgz)? In this way, people who are not going to use the package manager could just simply not install it. Moreover, it could break the base installation free from the heavy dependence on Perl. I would like to get your opinion on that. So the questions to the OpenBSD community are the following: 1. Is it possible, from the technical point of view, to extract pkg_* utilities, perlutil(1), any other Perl-dependent code and Perl itself from baseXX.tgz to the separate file set so that users that just want the *minimal* installation of OpenBSD don't have to remove it manually? 2. Are there any other programs in the baseXX.tgz file set that depend on Perl other than: - pkg_* utilities - perlutil(1) (rather obvious) - fw_update(1) - adduser(8) (adduser and rmuser utilities) - vi.recover script - cvs contrib scripts 3. Are there people among this community who think that the base installation of OpenBSD should not include Perl and Perl-dependent programs and utilities? Looking at FreeBSD for a moment it seems like Perl left the base system in May 2002 (18 years ago)[0]. In a nutshell the rationale was more or less the following[1]: > It appears that having Perl in the base distro has > the following problems: > 1. It increases the distro image size. > 2. It forces everyone to use the same version of Perl. > 3. If someone tries to install over that version or just even patch it, > it can break stuff in BSD which needed the old version. > 4. Installing multiple copies imposes weird symlink tricks > or else breaks other stuff. All comments and opinions are appreciated. Thanks! [0] https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html [1] https://bsd.slashdot.org/comments.pl?sid=32564&cid=3513689
