Does Desktop have a future on BSD?

SR_Ind said:
Why should I have to look into Makefiles?
Click to expand...
To make sure they don't rm -rf / your entire system? Seriously, you are the person acting surprised about dependencies and stuff, Makefile is the obvious place to check then.

Jose said:
Scroll down a little further and note that DOCS=on: Build and/or install documentation.
Click to expand...
Actually™, it's MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py-sphinx.
 
  • Thanks
Reactions: a6h
SR_Ind said:
Forget about desktop on FreeBSD.

Is FreeBSD run by sane people in the first place?
Click to expand...
You tell me.
And please, be as brutally honest and verbose as possible, embarrassing as I know this is going to be...

you_tell_me.jpg
 
SR_Ind said:
Forget about desktop on FreeBSD.

Is FreeBSD run by sane people in the first place?
Click to expand...

You may not like FreeBSD, that's your prerogative but you have no reason to call into question people's sanity. That's just a stupid thing to do. Are you stupid?


SR_Ind said:
I just reformatted a hard disk that was running the latest FreeBSD.

The trigger?

Why on earth should the port build for CMake pull in Python?
Click to expand...
Because some dependency of CMake requires something built with python. Your argument here is with, most likely, the makers of CMake.


SR_Ind said:
And I checked with a downloaded CMake source tar ball. It just builds fine outside of port system.
Click to expand...

It does? How miraculous. It had no dependencies? Phooey.


SR_Ind said:
I'm an old C programmer and I usually select most optimized operating systems for our embedded systems. One rule is that simple self contained BSD build tools.
Click to expand...

Then why are you using CMake rather than the old autotools? Yes, I use CMake extensively and it has its benefits, but the old automake etc tools work just fine.


SR_Ind said:
FreeBSD is turning into a mess. Port system is brokenup. BlueTooth doesn't work. WiFi is iffy even with well known drivers.
Click to expand...
It's not brokenup (sic), but yes it does have its problems, but it's a convenience. It's even more convenient to use packages.

As to bluetooth, that is just a plain mess and akin to the USB "standards".
Someone needs a lot of time, and probably working on it as their paid job, to unravel the mess that is. Are you volunteering time, expertise or money for that endeavour?

I have no doubt that should FreeBSD have someone like qualcomm write their driver for them they'd be as grateful as Linux was, but that hasn't happened.

SR_Ind said:
I don't like the bloated Linux distros with ever complex package dependencies.

Time to migrate to something more exotic.
Click to expand...

Good luck with that.
 
mark_j said:
You may not like FreeBSD, that's your prerogative but you have no reason to call into question people's sanity. That's just a stupid thing to do. Are you stupid?
Click to expand...
That largely depends on if he answers. ;)

Do you know how many times I've said that? I count 6 times and each ends the same way.
 
kpedersen said:
Even on Windows and macOS it barely works.
Click to expand...

Bluetooth works exceptionally well on my rMBP. You sure yours wasn't some Chinese knockoff? ;)

kpedersen said:
At least with it removed, it saves the user spending time wrangling with a broken technology.
Click to expand...

I'd rather the committers not be lazy and fix usable technology. Hell, I'd throw money myself at something like this, but the committers (and to some extent, the Foundation) have a hard time listening to their user base. WiFi is also broken on FreeBSD, would you suggest removing that as well? What about USB 3/4 support? it's also broken. Let's remove that too.

Let's not nurture more detractors of FreeBSD here..
 
My whinometer is pegged. Why bitch and moan about it - do something. Fix a problem, support someone fixing problems or go do something constructive with your time.
 
Geezer said:
decuser Are you really a dec user? I haven't used one of those for forty years.
Click to expand...
These days, the closest I come to using DEC is my whizbang PiDP 11 or my simulated SimH PDP-11, but I learned DOS on a DEC Rainbow 100, my dad was a Digital Equipment Service Engineer so I was exposed to DEC hardware early in life, and I heart research unix v6 which runs on pdp-11, so I guess you could call me a dec user :).
 
While not being able to run too much applications and some desktop envoirements crashing like one that I installed to FreeBSD 12.2 KDE5, I dont think so. It can become very nice if a big change happens like one that Apple did.
When I look at this Unix tree graph.
en.wikipedia.org

Unix-like - Wikipedia

en.wikipedia.org en.wikipedia.org
Some old MacOS's contains some parts of FreeBSD and they did very good job. I like design of Apple products. Lots applications supports too. As far as I know they currently using kernel named "XNU" so they just developed their own kernel and its running on new MacOS's and AppleWatch's. Anyway, its possible but very hard. Even hardware support is very less so it needs a lot of hardware supports first before desktop
 
Whoa. Seems like a lot of ruffled feathers. Sincerest apologies if it meant personally to some of you.

Maybe this was wrong thread to complain about (sharing my frustration) about the state of radio interfaces in FreeBSD.

FreeBSD is better suited for embedded space.
It will take a fraction of effort to get state of the art radio networking capabilities in FreeBSD.
Unfortunately, that effort doesn't come cheap. Radio networking stack development is less common skill.
No idea what are the funding priorities of the FreeBSD foundation.

Desktop will remain a shifting goalpost, unless the approach changes.
Desktop is simple, if and only if FreeBSD adopts a GUI/Widget/WM stack as the first class citizen. Just bundle Qt GUI and Widgets in the base system with a bare bone window manager with a set of configuration tools.
But the catch here is that no developer will spend their time to build these simple GUI tools, if the underlying OS has somewhat sub par hardware support.

Chicken and egg situation.
 
bsduck said:
Just a reminder: Apple's MacOS has much, much less hardware support than FreeBSD, and this doesn't prevent it to be the second most widely used desktop operating system around the world.
Click to expand...
Oh I see. On the second hand they building Macbooks and iMac kinda products by choosing thier supported hardwares. Are someone gonna create a FreeBSD distro that only supports certain hardwares then sell it with their self made devices. Yea maybe but It will be very hard to make FreeBSD supports most of softwares and bug fixes so I see developers doing a lot of contributions every day and thats what we getting. It would be more popular and useful if people be able to download it from internet without thinking hardwares. Like first time I install Linux, I were dont know anything about hardware supports, just thinking hardwares magicly connecting to system lol. It must be like that.
 
SR_Ind said:
Desktop is simple, if and only if FreeBSD adopts a GUI/Widget/WM stack as the first class citizen. Just bundle Qt GUI and Widgets in the base system with a bare bone window manager with a set of configuration tools.
Click to expand...
It is expected a FreeBSD user can use pkg install to trivially add this stuff. It will never be in the base install because it doesn't make sense for so many use-cases of FreeBSD.

As a C developer, you should also probably realize the issue with Qt and non-standard MOC for an OS primarily focussing on C. The very fact we have a C++ compiler in base is "luck".
 
Cmake has lots of dependencies, but really, those are ones that are the most useful, and should be common for almost everything. Python and Sphinx are really useful, and make good shared dependencies. If Sphinx could replace Doxygen for all cases. I would actually leave Sphinx in, and its common dependency of Python.

Cmake is like its own environment that has some common dependencies with a few other makes. It's the closet one to being multi-platform.
 
Jose said:
Project much?


View attachment 10246
And don't move the goalposts. You came here to whine about a Python dependency in a command-line build configuration tool.
Click to expand...

See there.

You don't seem to understand the issue.

I build my desktop from scratch. I use my desktop for development work.
I don't require Python and any of the interpreted runtimes.

If I start changing the Makefiles that came with the ports, then it will bring the whole question of using the ports.

Plus. When I create a FreeBSD image with all the development tools preloaded for one of my development boards, I just cannot afford to have any unnecessary tools included that I don't require.

The problem is not restricted to CMake, if you care to look around.

I manually changed around 4 or 5 Makefiles them work with LLVM10. That's the latest. If I leave an unattended install my system will end up with LLVM8, LLVM9 and LLVM10.

Some of the Mesa ports complaints being broken and grudgingly builds with Python2.x dependency. Who needs Mesa? Desktop.

Rather off topic, not related to FreeBSD per se, I don't understand the point of Meson being chosen for building Wayland.

A port system that is not streamlined is one fundamental problem, whether the system is intended to used as server, desktop or appliance.
Multiple tools means, multiple attack surfaces. Why should I keep something that don't need and just letting it to be an attack vector?

Please don't try that "you came here" stuff. I'm in this forum much longer than you.
 
SR_Ind said:
See there.
Click to expand...
(Snip a bunch of off-topic whining about amateurish system building.)

None of those things are in any way related to the topic of this thread, so the question remains, why are you here?
Are you really interested in Freebsd as a viable desktop operating system?
Or do you want to spread a bunch of FUD about how much it sucks?
 
  • Thanks
Reactions: a6h
sidetone said:
Cmake has lots of dependencies, but really, those are ones that are the most useful, and should be common for almost everything. Python and Sphinx are really useful, and make good shared dependencies. If Sphinx could replace Doxygen for all cases. I would actually leave Sphinx in, and its common dependency of Python.

Cmake is like its own environment that has some common dependencies with a few other makes. It's the closet one to being multi-platform.
Click to expand...

Agreed with the Doxygen vs Sphinx thing.
IMHO, even with all good things with Sphinx, that's strange choice for a build chain that is primary used by C/C++ community.
Hope it stays optional.
 
SR_Ind
I get some of what you're saying. I once pointed out that 14 hours of additional build time was excessive, to simply add a GCC compiler. I told them, it complies in no time by using the base LLVM/Clang compiler, and they fixed that. I still use the same kind of logic to point out inefficiencies. It has gotten much better. However, also there's some funny stuff when trying to upgrade a program, and seeing the amount of programs that need to be de-installed, and reinstalled. Trying to untangle this is difficult. Some problems come with that there are different suites of software from different camps that do the same thing, or that most people use the most complicated desktops, and make the defaults with those additional unneeded dependencies.

Only shell and C are more universal as a language than Python, so I am completely good with Python. Lua about matches Python in terms of how universal they are. I was thinking of Sphinx being optional, it can be, but it is so essential, I would rather leave it in. If it makes more people happy, make Sphinx optional.

However, the arguments you're making aren't helpful to your view.
 
You must log in or register to reply here.
Back
Top