FreeBSD development seems lost

I thought larry published perl under his "artistic license" but perhaps it's GPLed too. So I can understand they might want to remove code that is GPL.
 
CShell said:
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.
Click to expand...
They provide a display server but none provide a full fledged GUI system.

CShell said:
Literally the best "X Windows" experiences in the past were on workstations that were on *BSD hosts.
Click to expand...
Agreed. And the above is why. Your opionions about a good GUI is likely very different to mine which in turn is very different to some random Steam DRM platform gamer. Lots of people think they know about GUI because its a little intuitive to muddle through but it is all opinion and this is where disagreements happen. BSD has so far sidestepped all that mess by providing a minimum base.

But this discussion is also a good demonstration of the issue. There is more to computing than faffing with GUIs and yet this cycle is where the entire industry has stagnated for a decade. Tinkering with pixels on a screen rather than actually improving the OS in a substantial way (personally I don't believe the UNIX paradigm can be improved).

I'm not saying the GUI isn't important. I'm mainly saying that it is impossible to provide something out of the box suitable for a wide workstation use-case. The best people can do is make little mobs and try to bully the smaller mob into using something unsuitable.
 
My opinions only, again "what you paid for them" :)

Removing something from base: to me that implies "should it have been in base to begin with". Scripting languages: should a separate version be maintained in base or should a version be pulled in from "upstream/ports".
Perl. Having a version in base means base can use a single version instead of having to update base when the version changes. But that also means that the version in base can stagnate.

My opinion, base scripting should be in sh or lua (I think this may be a subset of "full lua" but not sure).
Packages, if they have a dependency on a scripting language that should clearly be a run time dependency of the package.
Where this can become problematic is "multiple versions of a thing" perl3, perl5 should they be able exist side by side? I think yes but others may say no, but the point is I think base should only depend on base, things like perl to me are outside of base .
 
Well, yes, sh(ell) would be the preferred tool for base scripting, I would have imagined, along with sed and awk, that's the real core. I was thinking more of always having perl available to the user from the point of installation, as a standard part of the unix cli environment. I guess it's a 'de-facto' standard though, not part of posix. Kind of a shame to see it go, its very useful.
 
there are 200k lines of perl in /usr/src vs 23mil of c/c++/.h but they are mostly tools/script/test units for contributed software
perl is not needed to build base
 
covacat said:
there are 200k lines of perl in /usr/src vs 23mil of c/c++/.h but they are mostly tools/script/test units for contributed software
perl is not needed to build base
Click to expand...
200k is still not an insignificant amount. And if this stuff is used for development, shouldn't FreeBSD have all the tools you need to develop it in base?
 
Ahh, items used for test/unit test. Should they be considered in base? Well, when I install a system fresh are they on the system?
Or are they in the source tree so that when a CI process builds base it has inline tests that can be executed?
 
Yes fair enough I guess, I just think I'd miss perl not being available at the command prompt from the outset straight after install. But boiling it all down to shell and removing script languages as dependencies, and no longer having to track those, sounds like a good rationale.
 
  • Like
Reactions: mer
if you install the source tree they are there but they are not used to build the base system
95% of them (perl) seem to come with openssl
 
cracauer@ said:
perl is also GPLed.
Click to expand...
Perl was in base but it didn't integrate into the build so it was removed from base about 25 years ago. Why? It uses GNU configure. Base doesn't. Perl scripts are sensitive to the version of the Perl interpreter. It made more sense to remove it.

I did the same when I managed a bunch of Solaris systems at the time. I made Perl non-executable on Solaris 2.1 and 2.3. My customers had to install their own specific Perl versions (plural). Perl is a system management horror show.
 
kpedersen said:
greed. And the above is why. Your opionions about a good GUI is likely very different to mine which in turn is very different to some random Steam DRM platform gamer. Lots of people think they know about GUI because its a little intuitive to muddle through but it is all opinion and this is where disagreements happen. BSD has so far sidestepped all that mess by providing a minimum base.
Click to expand...

I think what is missing here is that (we/developers on *BSD have always) spent our time working on GUI applications in *BSD (at the time BSD 4.2/4.3, BSD-Reno, BSD Tahoe, etc). I used to compile very early versions of Wine way back in the 1990s in order to "see" if they would work. At the time.. Windows 3.1 looking applications ran "sort of" and okay "it was what it was" back then. Did working on and supporting Wine (some how) change the development of the entire *BSD software tree to something different today in 2025? I argue - No

Am I glad than in the year 2025 Wine actually became something!? :cool: Well sure! I mean who would have predicted that Wine would knock gaming out of the park in the year 2025 in the 1990s?

Do I support Steam, DRM and other things now in 2025? Well I honestly do not know what technologies that we develop and make (today) will survive to live on for the next 30 or 40 years. *BSD has always been the testing ground for "tomorrow", and we'll see then what worked and what did not. And the answer is: Sure! I support Steam, DRM and Wine on FreeBSD - why not?

As for ftpd(8) ... I mean, Okay there's no encryption there :-). I am glad you see value in that, but it's not wrong to say maybe over the Internet (or whatever Net) there are some security decisions that are helpful. Heck I think telnet(1)/telnetd(8) are pretty cool too -- and I even ran a full uucp(1) host at one time. Do you see me complaining that uucico(8) is no longer in the FreeBSD source tree? Or a modem profile for my ancient Telebit Trailblazer 56 baud dial up modem (complete with MNP!) has been removed? Should I revolt like right now?

Don't you think I miss getting email addressed like:
From: source!mailb!mailrus!ucbvax!caltech1!thebayarea!nycityuniv@abouttime.net


WHO is this mysterious person that is stopping YOU from running FreeBSD as a server?

You are right ! I am switching to NetBSD !
 
Another think that attracts me is the lot of ports, but there are a lot of unmaintained, interesting ports.
It will come the time at which they will become unportable.
 
hruodr said:
Another think that attracts me is the lot of ports, but there are a lot of unmaintained, interesting ports.
It will come the time at which they will become unportable.
Click to expand...

Well, hold the horses.

I have seen ports removed because the original software is "unmaintained" (didn't have changes lately) when clearly that software was just a working, enclosed, finished system. There is some software that is just finished and working.
 
You must log in or register to reply here.
Back
Top