What would you like to see over the next few FreeBSD versions?

And from an external projects perspective, I would love to see FreeBSD be a among the primary platforms for Rust, Go and Python, oh, and I would love to see pypy again in FreeBSD.
FreeBSD is one of the platforms primarily supported by GO, via the GOOS and GOARCH compiler directives.
 
I didn't want anything, until this pkg debacle. So I just want someone to have some oversight on pushing out packages, not push out something that breaks all desktop user's systems would be great.
Poudriere + ports + local repository could probably fix all packages problem, which are encountered recently.
I personally don't like pre-build packages, because they force options on you.
Probably options, you don't really want.
 
A GUI tool for bluetooth would be nice too. Also a small icon that can live on a panel would be nice. There was a post by someone who was developing a tool for that purpose but I don't believe the work was ever completed and added to the pkg server. So, that would be cool. That an UrbanTerror would be my two items I would like in future FreeBSD versions.
 
A GUI tool for bluetooth would be nice too. Also a small icon that can live on a panel would be nice. There was a post by someone who was developing a tool for that purpose but I don't believe the work was ever completed and added to the pkg server. So, that would be cool. That an UrbanTerror would be my two items I would like in future FreeBSD versions.
FreeBSD doesn't have any real GUIs in base. Perhaps you are thinking of a TUI like bsdinstall(8)?
 
Probably options, you don't really want.
Recently, many of the ports having NLS (Native Language Support) option enable it by default, but in ancient days it was not.

So anyone who want (at least) CJK characters needs building ports having NLS option disabled with it enabled locally.

And in ancient (pre-UTF-8) days, NLS usually doesn't mean it shows messages, menu items and so on are localized, but allow byte streams of non-English (meant non-ASCII) character encodings to be given and (hopefully) do not break them on output. Usually it meant "8bit through" (allow topmost bit on each bytes to be 1), means, some Shift-JIS encoded Japanese characters were broken. Sigh. If I myseld at the moment see the recent situations, I would have thought it's like a heaven.
 
My two wishlist items, that are incompatible with the freeBSD ecosystem, and are why I cannot dump linux...would be
1) a port of the linux md metadisk software raid layer and related filesystem types,
2) true nvidia cuda support

well, there is another impediment...I run a few vendor supplied IDEs that support linux but not freeBSD.

and no, I don't do emulation or container environments as a work-around
 
Do you want it because of some specific feature or because you want to read filesystems on md raids.

Not sure which filesystems relate to md?
I have too much existing data on linux raid-5 array to migrate.

In linux there are certain ext?? filesystem options that go hand-in-hand with the the options used to create the underlying raid array and will contribute to efficiency or bottleneck of IO operations, IIRC.
 
Oh young Padawan... Did you ever hear the story of Bumblebee? Now that was a debacle.

But maybe a bit more checking is always to be considered.
Not young, and I don't understand your cryptic message XD I didn't have any issues because I didn't update my pkg with broken stuff, but newbies did and it makes them run back to linux. It's not for me, I don't know why people think I'm only complaining for myself. I am complaining on behalf of all the new FreeBSD users who updated and lost their KDE or whatever and I believe that should have never happened. You think that pkg should push out missing packages like that?
 
It's 100% on nvidia, as it's provided only as pre-compiled binaries.
Nothing can be done (except via current Linuxlator way) from ports side, except for continuously requesting nvidia to provide the wanted libraries for FreeBSD versions they're kindly providing.
Actually, the FreeBSD driver is provided in source form on NVidia's website, but it's under a source-avalible, nonfree license. By my reading, however, you can modify it! I don't know how that woulf help with closed-source CUDA though.
 
I have too much existing data on linux raid-5 array to migrate.

In linux there are certain ext?? filesystem options that go hand-in-hand with the the options used to create the underlying raid array and will contribute to efficiency or bottleneck of IO operations, IIRC.
When I first moved over from Linux I was a bit confused about the file system and so I just installed freeBSD and moved everything over from the network. And then I nuked all the Linux off of all my machines. Lol but at the same time I have no idea what any of that technology is that you're using on Linux.
 
I'd like to see a small change in cp(1). It's still referencing rcp(1) in its SEE ALSO section however... /bin/rcp is currently obsolete according to /usr/src/ObsoleteFiles.inc.

I don't know all the details yet, but I do hope I can get a change request in somehow ;)

Your modest wish has been granted. I removed the references in cp(1) and hosts.equiv(5) today in CURRENT.
 
Actually, the FreeBSD driver is provided in source form on NVidia's website, but it's under a source-avalible, nonfree license. By my reading, however, you can modify it! I don't know how that woulf help with closed-source CUDA though.
Yes, upstream (nvidia) FreeBSD driver package contains source codes, but it's only glue codes for kernel interface that coulf differ between releases, and acutal driver part and libraries are pre-compiled.

And nvidia open source drivers support only Turing generation (and later) GPUs that have GSP (GPU System Processor) in it. Unfortunately, the GPU I have is Quadro P1000 (notebook) only, that is pre-Turing (Pascal) generation. So I cannot test it even if I can build it, thus, no intention to port it.
 
Your modest wish has been granted. I removed the references in cp(1) and hosts.equiv(5) today in CURRENT.
It took me a while to respond because I was still (re)building my system, but... I found commit 14783ce31437709f9c5778af32f7661a52407b6d in the source tree today after my update, and it had a rather familiar name and ditto description ;)

Thanks, appreciate it very much!
 
I have one for the list... I understand VAAI/ODX storage primitives have been "wired-up" and fully supported by ctl for a number of years.

OpenZFS 2.3 has BRT.

Wire the two together to support fast clone from block storage initiators such as iSCSI.
 
Back
Top