FreeBSD development seems lost

All went downhill when they removed rcs from base (AFAIR after 10?)
🐊😭
/s
You laugh, but it is a small, usable piece of software that in my opinion deserves to be in base.
I agree, and I loved and used rcs a lot back then, but version we had was GNU, so it had to go. Now, we have devel/rcs57 which is:
This port is gnu rcs 5.7. It is compatible with the rcs that was in FreeBSD prior to its removal in FreeBSD-10.0. Some ports will not work with changes made to rcs (e.g. changes to command line syntax) following the rcs 5.7 release.
and the latest release (5.10.1) in devel/rcs
 
Us old dogs may use the old stuff but the kids won't. [...] It's the world we live in. Get used to it.
The kids won't use nano either because "console is old". Should we really ditch the console and editors in general to appease this market? Perhaps an OS should be developed for people who know better than the kids. I feel that pushing back is the better choice than getting used to it.

The world is in a race to the bottom, it doesn't mean FreeBSD needs to join.
 
Perhaps an OS should be developed for people who know better than the kids.
The OSes you are thinking of, by now, are NetBSD, OpenBSD, DragonflyBSD, and illumos. Just a few years ago FreeBSD would be on that list, but given the recent developer attitudes, sadly it isn't anymore. I can imagine that 25 or so years ago, there was a similar discussion on a Linux forum, mass-appeal types probably won, and look where it is now.
 
The kids won't use nano either because "console is old". Should we really ditch the console and editors in general to appease this market? Perhaps an OS should be developed for people who know better than the kids. I feel that pushing back is the better choice than getting used to it.

The world is in a race to the bottom, it doesn't mean FreeBSD needs to join.
I use nano because I don't like ed or ee... and vi... well, if need be, I can always google for a cheat sheet of vi commands...
 
I use nano because I don't like ed or ee... and vi... well, if need be, I can always google for a cheat sheet of vi commands...
But there are people who will probably suggest removing (i.e. spinning out into ports, but now that pkgbase is coming everything will be a port) ed, ex, and vi simply because "they're difficult". My first text editor was vi, and I didn't beg for mercy. I just read the fucking manual, like everyone with even two braincells should.
 
That's just FTP in general, which will have the same issues no matter what implementation carries it. Also, that article looks AI generated, or at least heavily AI-assisted.
My point was, FTP does have vulnerabilities, and they are well known and easy to find, and are usually rectified in up-to-date implementations like sftp. No point reinventing the wheel or being political about things until you're blue in the face.
 
My point was, FTP does have vulnerabilities, and they are well known and easy to find, and are usually rectified in up-to-date implementations like sftp. No point reinventing the wheel or being political about things until you're blue in the face.
FreeBSD has ftpd and tftpd. They could just keep it as is, while adding an sftpd. There is no reason to remove things, and then not offer a replacement. ftps is rather undiverged from normal ftp, besides some simple encryption, so that capability might have actually been possible to graft on to the existing ftpd, instead of removing it so there is no ftp at all.
 
They are removing things "because" though. Look at the mailing lists. And some of the stuff they are removing actually has a use. ftpd as an example has no known vulnerabilities, and is used by anyone on FreeBSD that wants an ftp server. What the hell was wrong with fdisk? The foundation hates it, but it is useful for those of us who use MBR. And when they purge all of this useful software, they want to offset it with KDE in the installer. Linux is constantly deprecating and replacing things in this same way. The Foundation && Top Developers are following the Linux philosophy, not the FreeBSD one. And the new focus on Laptop use is alienating people who use it on their servers. FreeBSD was supposed to be a general-purpose OS, not a Laptop OS.
From one retro enthusiast to another, I think dropping i386 is a crime. And to that end, I'm certain that MBR will be on the chopping block soon.

Apparently moused needed evdev support added for "mices (sic) and touchpads":
src: aef807876c305587c60f73e2cd914115d2

And to your point about following the Linux philosophy, "Actually, the new moused config parser is taken from libinput."
 
:rolleyes:

sftp merely works with firewalls a bit better than ftps... just because the former only needs port 22, while the latter needs multiple ports open to function properly.
I can deal with a few ports at once, and it is still creates a smaller attack surface than just using normal FTP. I already handle many more ports than that in my home lab. If you don't know what a port is than you shouldn't be running a server.
 
So *BSD has always had a GUI component to it? Not sure why you think FreeBSD is solely a "server" O/S? I was running *BSD on GUI based workstations for many many years -- and even today on my PCs. Literally the best "X Windows" experiences in the past were on workstations that were on *BSD hosts.

So I think you might be ... wrong :-).

But good luck with NetBSD !

This misunderstanding is the basis for a lot of stupid arguments on the net, and poorly conceived implementations. don't think of GUI as a component, but as a layer. component infers equal standing, whereas layer infers delegation of a function within an abstraction heirarchy. When you start to think about OS/distro concepts in the onion shell model, things are much easier to deal with, and at least for me, stuff become much more apparent. So even "BSD on GUI based workstations" is slightly misleading and can cause confusion for the non-elite. OS and "apps" are better left segregated with the "core" being just enough to bootstrap a system in whatever direction you need by adding the necessary apps/layers. Of course this is a highly unpopular position since everyone wants to be lazy and just have everything immediately available.
 
FreeBSD has ftpd and tftpd. They could just keep it as is, while adding an sftpd. There is no reason to remove things, and then not offer a replacement. ftps is rather undiverged from normal ftp, besides some simple encryption, so that capability might have actually been possible to graft on to the existing ftpd, instead of removing it so there is no ftp at all.

Actually that strikes me as a case where to come into the 21st century, a unified ftp daemon should be created, with symlinks to the historical names to maintain reverse compatibility, and what you achieve is: you've gotten with the times, while honoring the responsibility of not deprecating the traditional functions.
 
Funny, I use scp(1) (which is definitely in base), and I don't need anything else, really. Frankly, I like having a variety of ways to transfer files. If I wanted to set up an NFS/SMB/WebDAV I can do that to make things convenient, but every once in a while? scp(1) is enough.

Sometimes, it's easier to ask, "What do I want done? What tools are actually available in base?". I was often surprised at what's actually possible with a base FreeBSD install. The tools are there, they've been curated by a pretty knowledgeable team of devs, it's just a matter of making yourself RTFM a little.
 
This thread grew too quickly to reply / react for each posts...
Sorry if I'm overlooking someone already answered the same thing.

For perl in base:
If I recall correctly, one of the reason was perl changes too quickly and in-base perl was too outdated on next release. This kind of things better fits in ports rather than in base, even if there are no issues with licensing.

For lua in base:
As far as I know, it was initially introduced only for loader, like forth.

For r* commands (and some more):
Removed as of security issue in design of the protocol itself.
I myself consider it as OK, as these are moved into ports and anyone who still need them can easily install them via ports or pkg.
If any of them are going to be deleted even from ports, I'll strongly object, though.

For dropping old items from ports:
In my humble opinion, the fact "it's old" alone is NOT enough reason to drop.
But if the upstream repo is gone (excluding move to elsewhere) and distfiles are NOT AT ALL available, it should be good enough reason to drop.
Even in this specific case, if any fork is actively maintained and the license when the fork was created allows forks, switching upstream SHALL be considered at least once before dropping (something like lang/python27 to lang/tauthon, not so active, though).
 
Back
Top