FreeBSD 15.0 planning

Retrospective:


Looking ahead:

 
I kind of resent them removing FireWire.
Firewire does require hardware with specific plug dimensions. These days, I think you can actually find USB<->Firewire adapters. I actually have a Firewire connector somewhere in a box of old adapters that I never bothered to toss.


Sorry? Didn't know I needed to justify myself? Very nice SATA enclosures?
I seem to recall that Firewire hardware was actually fairly expensive stuff back in the day. If you owned that kind of stuff, that meant you were a pretty serious video capture/editing enthusiast. But these days, the process of video editing is much more accessible to the masses (Just look at the sheer amount of crappy face-morphing videos on YT). At the same time, Firewire hardware is harder to come by (unless you look on ebay for secondhand stuff). If you want something that's hard to come by, you kind of do need to explain why you need THAT, rather than something that's easier to come by. (Kind of like a kid asking for a $1500 dev-grade machine for a programming class, rather than a $500 laptop that barely has the metal for the same class).
 
Sorry? Didn't know I needed to justify myself? Very nice SATA enclosures?
Sometimes developers ask for use cases before they retire old code and drivers.

In case they’ve missed a good reason or several for keeping the old code in.

Not saying that’s the case here but the question might have been genuine curiosity as to why you wanted the code to remain.
 
It may also be a security thing. If I remember correctly then FireWire was a bus master DMA device which needed to be fenced in by the IOMMU, or a bad actor might read/write the memory from the outside, maybe even in S3 mode. Or a buggy device would randomly write to your kernel space. All that and the price tag for the connectors, thanks to the marketing abilities of the fruity company.
 
If you use obsolete hardware or technology (like firewire) you will need to plan how you are going to use that when it gets removed. Using firewire as an example, that could mean keeping old versions of FreeBSD running on hardware which has firewire.

When living in interesting times (such as now), things tend to change faster, meaning technologies get obsolete faster.

Remember analog modems? ISDN adapters? landlines? None of those is in use anymore in my part of the world.
 
At least analog modems are still usable. Serial connections and ppp(8) still work. Don't think support for the good old serial port will be removed any time soon. ;)
 
Well, I guess to be fair to the devs, they are merely putting it up on the chopping block as a suggestion.

Yes, I do have a whole box of FireWire stuff, but I also have a SATA box that is just as old. It wasn't that much more expensive when you consider that I don't have any ancient USB equipment due to it breaking or really being useless. FreeBSD dropped 3ware card support and all those connectors are still in production...

What annoys me about FireWire deprecation is that Thunderbolt doesn't have as good support for me to switch my hardware over. (Jam JHL8540 into the search box)
 
At least analog modems are still usable. Serial connections and ppp(8) still work. Don't think support for the good old serial port will be removed any time soon. ;)
Considering that serial port is still needed for headless installations like Pi or password recovery via the BIOS of a VPS...
 

smbfs replacement (v2 or better)​




It's amongst the top three.
Looking into the table in "prioritize feature list" section, smbfs is at the 7th mean rank, having point 5.0 where "Mean rank (lower is more important)" column. And practically, and unfortunately, the attribute would vary among documents. But I strongly want it and deprecation was stopped (at least pended) with discussions at freebsd-current ML started at Oct.2021 by EdMaste and continued until a post at Jun.2022.
 
Oops. I misread lower as meaning lower in that column. Sorry.

Now if I read the next column correctly, smbfs 2.0/3.0 is amongst the three most difficult things.
 
Remember analog modems? ISDN adapters? landlines? None of those is in use anymore in my part of the world.
And they are used in other parts. My FreeBSD server (which is located about 25 minutes from the core of Silicon Valley) has three serial ports, one of which is connected to an analog modem, which uses a landline.
 
Now if I read the next column correctly, smbfs 2.0/3.0 is amongst the three most difficult things.
Exactly.
Once I've tried to read Darwin's smbfs codes on their public repo years ago, but gave up. Macros, macros, macros, ...and different functions and files. Unfortunately, I've lost the URL. But it was clearly beyond me.
 
Or rewritten as a wrapper using pkg as underlying tool.
I thought pkgbase was already something that used freebsd-update as underlying tool!

Consider this in pkg-install(8) :
Code:
-I, --no-scripts
          If  any  installation     scripts (pre-install or post-install)
          exist    for a given package, do     not  execute  them.   When  a
          package is updated, deinstallation scripts (pre-deinstall or
          post-deinstall) are not run either.

If installing a package involves running scripts, is there anything to stop scripting freebsd-update(8) as an installation script?
 
Back
Top