Does Desktop have a future on BSD?

kpedersen said:
I don't really know what UI toolkit Firefox uses on Windows. I would be surprised if it was Gtk or Qt. They probably have a light abstraction layer ontop of Win32.

wxWidgets I suppose has a similar approach. Unfortunately on Linux/BSD, it sticks ontop of Gtk or Qt so you lose that "lightness".
Click to expand...
There's a lot of software that uses gtk and qt on top of windows (even some games do that, to be even worse, some games uses qtwebkit/webkit-gtk).
 
Didn't find anything about Firefox. Chromium indeed uses an own abstraction (well, isn't this adding yet another layer?)

Even this abstraction doesn't use win32 directly, but WTL. Never used it myself, but it's presumably a great choice when the target is only Windows, cause it's very thin and still abstracts away the madness of win32 ;)

OTOH, I don't see what should be so bad about Qt (or maybe GTK as well, although I never used it myself). Maybe how you use these toolkits plays a role as well…
 
Zirias said:
Didn't find anything about Firefox. Chromium indeed uses an own abstraction (well, isn't this adding yet another layer?)
Click to expand...

I am starting to suspect that it doesn't really have much to do with the number of layers but instead with what you layer it on top of. Win32 (and MFC) might be naff to develop with directly but even with a few abstraction layers, the resulting program is pretty crisp and snappy.

I ran Gimp on Windows a while back and it was fairly painful in terms of speed. However this has Gtk3 in the mix. I just don't believe that Gtk or Qt are serving us well (though in my tests, Qt *is* lighter than Gtk).

I was updating my fork of a level editor (you can see the kind of UI requirements here) from Gtk2 to Gtk3 and was simply not satisfied with the performance. The weird thing is that performance doesn't usually bother me. However Gtk3 is so sluggish that usability is starting to decline and it is starting to feel broken. The worst thing is that I feel this is by design (they want it slow so they can fit in their naff fade / translation effects and other tacky gimmicks).
 
Well, knowing only one of them (in my own projects, I use exclusively Qt for GUI), it's probably unfair to draw a comparison. All I can say is that Qt serves me well implementing the UI layer only once (yes, I am too lazy to do otherwise), and I never felt there was a problem with performance, and never got complaints from users…

About GTK3, I remember there was kind of an uproar among Windows users of emulators/vice when they dropped the different UIs (one for each platform) with major version 3 and instead used GTK3 everywhere. Most complaints from Windows users were something like "it's slow as hell". Still, this is no proof, there might have been other reasons, e.g. because OpenGL rendering is part of the picture. And they managed to reach a state by now that seems to satisfy most users on Windows as well, without getting rid of GTK3.
 
richardtoohey2 said:
Great, who is going to do all that work? And test all the hardware (that won't be cheap), and keep the list up-to-date? And across all supported versions of FreeBSD, and platforms (e.g. does the device work for 32-bit, 64-bit, Intel, ARM, etc. etc. etc.)
Click to expand...
And considering hardware churn, that work would never be done. There's always new hardware popping up, and old hardware becomes unavailable. The database would always be out of date.
 
richardtoohey2 said:
Great, who is going to do all that work? And test all the hardware (that won't be cheap), and keep the list up-to-date? And across all supported versions of FreeBSD, and platforms (e.g. does the device work for 32-bit, 64-bit, Intel, ARM, etc. etc. etc.)
Click to expand...
There is few command to have a good idea at first step. I list few possibilities here in this forum.
 
Jose said:
And considering hardware churn, that work would never be done. There's always new hardware popping up, and old hardware becomes unavailable. The database would always be out of date.
Click to expand...
Yeah its strange. Hardware databases always start with the best intentions but simply seem to rot. Especially if they are wiki based. People forget about them and newcomers don't even know they exist until they are ancient dust.

How about the forums enforce us to fill out a hardware profile before it lets us log in or register (nice and invasive! ;)). Or in massive red letters under the .iso download button "Official Hardware Database". Of course this does run the risk of scaring people away thinking they have unsupported hardware even if they don't, the database is just out of date.

Some thing like this is very useful: https://catalog.redhat.com/hardware/workstations/search
(Though I don't have one machine that is supported by anything newer than RHEL6! What the hell? I bought this machine less than 15 years ago!)
 
Forget about desktop on FreeBSD.

Is FreeBSD run by sane people in the first place?

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?
And I checked with a downloaded CMake source tar ball. It just builds fine outside of port system.

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.

FreeBSD is turning into a mess. Port system is brokenup. BlueTooth doesn't work. WiFi is iffy even with well known drivers.

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

Time to migrate to something more exotic.
 
shkhln said:
You'll have to read the Makefile to find out.
Click to expand...
You don't even have to work that hard. Look at its Freshports page. Note that its only dependency is textproc/py-sphinx. Scroll down a little further and note that DOCS=on: Build and/or install documentation. Mystery solved.

SR_Ind said:
I'm an old C programmer and I usually select most optimized operating systems for our embedded systems...
Click to expand...
Your behavior makes me question your optimization skills.
 
  • Like
Reactions: mtu
SR_Ind said:
WiFi is iffy
Click to expand...

Yes.

s1rzx5fjf2671.png
 
Jose said:
You don't even have to work that hard. Look at its Freshports page. Note that its only dependency is textproc/py-sphinx. Scroll down a little further and note that DOCS=on: Build and/or install documentation. Mystery solved.


Your behavior makes me question your optimization skills.
Click to expand...
First is of all does this forum has any rule against uncalled for insults.

Let me respond back in kind.

I always install ports with examples and docs turned off. Why should I have to look into Makefiles?

Brush up on your comprehension skills.

I may posses programming skills of whatever level. That's why I straightaway built CMake as is from the sources.

But you seem to lack basic social etiquettes, as amply demonstrated by your sly of the hand indirect ad hominem.
 
grahamperrin said:
Yes.

s1rzx5fjf2671.png
Click to expand...
So, another one out of the woodwork.

Send me your shipping address buddy.

I will send you a rtwn device and an ARM based SBC of your choice. You get it working. I will handle the shipping.

And. Since you felt compelled to jump. Did you care to check the BlueTooth support?

Missed the word "iffy"? My Atheros works fine. My old ural devices used to work fine. But despite the claims in the documentation the rtwn device doesn't work.
 
grahamperrin said:
Yes.
Click to expand...
Excellent.
Hope it is worthy of 21st century.
Could you care to send me a brief write up on how to set up a BLE 5 mesh on top of FreeBSD (take latest), with your recommendation of a BlueTooth 4.1+ adaptor?
I will pay you for your services, whatever you charge per hour.
 
Honestly, I wholeheartedly agree with OpenBSD's move to remove Bluetooth entirely. Even on Windows and macOS it barely works. At least with it removed, it saves the user spending time wrangling with a broken technology.

Ports like CMake pulling in more dependencies than they should is a bit of a known problem. I do understand that making the port pull in everything does help somewhat with making deterministic builds (i.e many build scripts do random crap depending on what they detect is installed). However it is something that the FOSS community will need to improve one day. It is making software a little large and broken.
 
You must log in or register to reply here.
Back
Top