What does not work very good on FreeBSD

T-Aoki said:
What's not listed yet would be smbfs, out of the box.
At least, I need the patch proposed at PR 90815.
And more, if Windows completely drops smb1.x support, anyone who want to mount shares on Windows would lose it on FreeBSD clients. Latest (at least smb/cifs2) support is needed. There seems to be a plan, but its priority looks low.
Click to expand...
That's why when using bhyve VMs I switched from Windows 10 to Windows Server 2022 (where I run NFS server). But I'm not sure that Windows Server will install on a non-server platform.:-/

Edit.
My platform is a server (but I use it as a workstation) - https://forums.freebsd.org/threads/how-is-14-doing-for-folks.91636/post-635896
(post 31).
 
T-Aoki said:
Descriptions in the Handbook often takes behind.;)
Click to expand...
The versions mentioned by the Handbook may be behind - a little. The description on how to install and set up stuff should not be drastically different because of that. If the correct setup procedure for the current default version is in fact drastically different, that's a red flag that the FreeBSD documentation team should be made aware of via a PR...
 
Long long ago, when I was a student, I've worked for creating documents from source codes by other programmers. Some had comments in it but many did not, so I must read thoroughly the codes, understanding how it works and then document it as its internal specifications.
It was PAID JOBS, as the company is mandated to provide documents to their customer and most of programmers didn't want it.
Programmers loved designing/coding, but usually didn't like documenting. Maybe this kind of habits would not easily change.
And nowadays, softwares became much, much larger and complexed that I cannot analyze and document in limited spare times.
 
T-Aoki said:
Long long ago, when I was a student, I've worked for creating documents from source codes by other programmers. Some had comments in it but many did not, so I must read thoroughly the codes, understanding how it works and then document it as its internal specifications.
It was PAID JOBS, as the company is mandated to provide documents to their customer and most of programmers didn't want it.
Programmers loved designing/coding, but usually didn't like documenting. Maybe this kind of habits would not easily change.
And nowadays, softwares became much, much larger and complexed that I cannot analyze and document in limited spare times.
Click to expand...
Yeah, the conundrum - no, it's not fun to put in the effort to not only write the code, but also explain to others what the code is even doing. Documentation is what keeps the code maintainable. Otherwise, how do you even tell others that the code does the correct thing? If I don't know the code does the correct thing, I'm not gonna buy a copy or even bother using it for free. Which means the programmer who didn't bother to properly document their source code has wasted their own time and effort coding.

Well, there's limits to everything. So people came up with documenting techniques to save on labor - inline comments inside parsable tags, XML, reworked syntax, and more... devel/doxygen is an example of a reaction to that chilidish laziness. Sometimes you kind of have to keep beefing about a problem until it has an adequate solution.
 
getopt said:
Just to be on topic see the huge list of PRs:

Bug List

bugs.freebsd.org bugs.freebsd.org

and note how many are new, open or in progress. Also see how many are not worked on for months, just laying there without progress.
Click to expand...

Perhaps if $omeone organises a whingeathon and enough people complain about the poor service, greater levels of compliance might ensue?

If not, at least we'll know who to fire ...
 
smithi said:
Perhaps if $omeone organises a whingeathon and enough people complain about the poor service, greater levels of compliance might ensue?

If not, at least we'll know who to fire ...
Click to expand...
If (like the vast majority of people) you can't code, you hire someone who can. But if the coder can't meet demand, coder no longer in demand. In the hubbub of complexity, we all have a propensity to lose sight of pretty simple and useful ideas. ?
 
astyle said:
If (like the vast majority of people) you can't code, you hire someone who can. But if the coder can't meet demand, coder no longer in demand.
Click to expand...

My underlying point is that the vast majority of FreeBSD was coded and is maintained by volunteers, not 'staff". I should have added a specific smiley ...

astyle said:
In the hubbub of complexity, we all have a propensity to lose sight of pretty simple and useful ideas. ?
Click to expand...

Aye.
 
grahamperrin said:
Bugathons
Click to expand...
Bugathons are great! Therefore some questions:

1.) When was the last Bugathon and where?
2.) Are FreeBSD Bugathons regularly events?
3.) How many Bugathons would be needed to solve 10% of the current PRs on bugs.freebsd.org?
4.) Do you think that a few Bugathons here and there and now and then can solve a structural problem of the magnitude the FreeBSD ports suffer?
5.) How good are FreeBSD Bugathons in terms of maintainer education?
6.) What would be needed to make FreeBSD Bugathons more than an event that helps generating a nice FreeBSD news headline?
 
You must log in or register to reply here.
Back
Top