Closed What Would You Like to See FreeBSD Do Differently?

[sidetone]

PcBSD is too bloated. Jwm or i3 do plenty for a simple window manager; and PcBSD should drop it's desktops for these two. Benefits of PcBSD, however, are ease of mounting without a command line, and an easy to use desktop jail.

 

[sidetone]

I realize this may sound like a far fetched question, but what's the feasibility of using lang/rust (which produces pure binaries) to make or improve graphics drivers? Calling C or other programming languages would be no problem. I also realize that this is not in base system, and would bloat it. But in any way, through ports, or compiling source code. I also realize someone is going to think, why do something difficult or to just use a rust built OS, but I just want to know.

 

[bcomputerguy]

I realize this may sound like a far fetched question, but what's the feasibility of using lang/rust (which produces pure binaries) to make or improve graphics drivers? Calling C or other programming languages would be no problem. I also realize that this is not in base system, and would bloat it. But in any way, through ports, or compiling source code. I also realize someone is going to think, why do something difficult or to just use a rust built OS, but I just want to know.

I don't think rust will work here as most of this stuff needs to be implemented in the kernel. I've been looking at the latest linux drm stack and it's mostly simple data structures, the part that gets complicated is me understanding the linux kernel_params object and how to translate that to FreeBSD kernel objects.

This will take a bit of time, but it doesn't seem unreasonable or excessively difficult. It just takes proper understanding of two operating systems kernel calls, virtual and memory management as well as the way both systems handle acpi.

 

[sidetone]

Adopt another important project like fixing LPD. That code begs for cleaning. Common. Apple has enough resources to maintain CUPS. We need FreeBSD guys to step up and remove legacy code from LPD and add minimal set of new features supported by current printers. Adding IPP would be one example.

To standardize and simplify it. Just so, legacy printers aren't removed, and if a driver is missing, keep having a simple way to add that driver, which it already can do. Then have it so scanning functionality (through ports) can work on top of LPD. After learning about what that can do, CUPS and other printing systems can just reduce their significance on FreeBSD, and in ports. I thought CUPS was the most essential for printing, until looking at how LPD was functional and simpler.

 

[BSD-Kitsune]

I'd like to see the graphics stack reworked and implement DRM, KMS, GEM and all those modern features WITHOUT relying on linuxkpi. I think that kpi is a virus honestly, this might make a few people upset but I think it makes BSD weak.

I will work to bring all those graphics features to BSD w/o relying on Linux headers!

Once that's done we can update the input drivers to something like evdev and also get the latest xorg and then linux will not have much over BSD.

I agree. We should not be relying on playing catch-up with Linux and doing things the Linux way - doing so compromises the integrity of our goals

The way those *BSD systems implement graphics is very brittle and will most likely break in the future at which point it will be REALLY hard work to rewrite their graphics stack from scratch.

Currently Linux has improved their graphics stack sufficiently where they even have atomic updates, I doubt they'll be doing any major code breaking changes.

I think this is a good time to port the graphics stack to FreeBSD without depending on linuxkpi.

Ditto what I said above.

I don't think rust will work here as most of this stuff needs to be implemented in the kernel. I've been looking at the latest linux drm stack and it's mostly simple data structures, the part that gets complicated is me understanding the linux kernel_params object and how to translate that to FreeBSD kernel objects.

This will take a bit of time, but it doesn't seem unreasonable or excessively difficult. It just takes proper understanding of two operating systems kernel calls, virtual and memory management as well as the way both systems handle acpi.

Well not only that but a rewrite of the graphic stack using FreeBSD native kernel apis will make for quicker and more optimized graphics. And if we lack the equivalents to the Linux kernel - it's an opportunity to improve there.

 

[bcomputerguy]

I agree. We should not be relying on playing catch-up with Linux and doing things the Linux way - doing so compromises the integrity of our goals



Ditto what I said above.



Well not only that but a rewrite of the graphic stack using FreeBSD native kernel apis will make for quicker and more optimized graphics. And if we lack the equivalents to the Linux kernel - it's an opportunity to improve there.

This is exactly what I am thinking and I am in the early stages of working on this. Check out this question and the answer the guy gave

To me that just shows that the linuxkpi route is a dead end.

Currently the graphics stack has been improved dramatically up to the point where there's atomic updates and every GPU vendor is starting to implement atomic api's to their graphic drivers.

This is a good time to implement the graphic stack and make it work the BSD way.

 

[mfm]

Suspend doesn't work correctly on a lot of laptops. I always have to fiddle with sysctls to make laptops properly suspend/resume with FreeBSD (if it works at all).

( sysctl -a | grep hw.acpi is equivalent to sysctl hw.acpi btw)

Since Multics days [not even mention Unix] we can run the same thing using combination of different tools.

OpenBSD only recently enabled suspend on lid close by default (in OpenBSD 5.7 I believe; not so long ago... and only after a several releases long testing and fine tuning period of their ACPI stack).

Good to know. Thank You for that info. I was using OpenBSD as the reference point. Also NetBSD witch is BTW great development platform.

No. The cooltrainer.org howto is becoming outdated fast (last update 2014-12-26). For example the way it describes setting up x11/nvidia-driver will lead to problems. The way it recommends kernel knobs without explaining why they are needed. Why set kern.maxproc=10000 (it's autotuned)? Why load sdhci(4) from /boot/loader.conf when it is in GENERIC? Why, why, why set the mode of all disks to 666!? Why yet another /etc/pf.conf without using interface groups? Also sysrc(8) is awesome. Why run X -configure? I could go on and on here ;-).

I think my point here is that it adds lots of noise to something that is very simple to setup already.

Correct. I was using only some parts from that site. What my point was the official guide should contain notes for example about how to check If your laptop have that feature that could be enabled, like suspend/resume after lid close.

I'm the ordinary user, not preying to any OS. I'm using FreeBSD as a tool to do the job including programming with capsicum(4) capabilities.

But after all I'm impressed how FreeBSD works well. I was using it years ago like version FreeBSD 4.x.x

what you personally prefer or go through the extra work to change it, are all pretty selfish and lame.

Good conclusion.

 

[Maxnix]

Since Multics days [not even mention Unix] we can run the same thing using combination of different tools.

Apart the overhead caused by sysctl -a | grep hw.acpi compared to sysctl hw.acpi, in this case.

 

[daemontrainer]

I thought about this for sometime.
Honestly, main thing I want to see FreeBSD do is not to change too much. I am still learning a ton of things I can do with it, and one of the best parts is that the ground under my feet doesn't constantly shift heh. So far everything has been nice and very familiar since 9.2 (i think that was the first release I ever installed? time flies x.x)

As for actual new things to be part of base?

-IPFW to be the our only fire wall. I love pf, but we are pretty far behind upstream. If we could phase it out by release 13.0 or 14.0, I would think ~5 years is enough time to transfer? I can't imagine maintaining pf is an easy task at ALL either. I personally love it and use it, but since we have an alternative for which we can be the upstream of, I would say its worth it = |

-LibreSSL in base. (definitely not trying to start holy wars, and certainly know it would be very very difficult, but again, seems like a very worthy endeavor)

-iocage-like tool in base. Some zero conf tool that is in base and has no fear of suddenly being not maintained. I am aware that there are alternatives, but none live in base. Putting something like this in base would, in my humble opinion, would allow FreeBSD to be deployed easier as service platforms. Currently the tools we have are ok. they are very usable and even aforementioned iocage will still work despite not understanding how I have 11.0 and not 10.2 which is the last it supported. But, to me it seems that jails are certainly one of the best features of FreeBSD and having a tool to manage them in base would be great.

*Oh and of course, GPU pass-through in bhyve... so I can finally not run linux for that feature haha. This one belongs in "nice to have, but don't really care as I know how much work it is" pile = ]

 

[BSD-Kitsune]

-IPFW to be the our only fire wall. I love pf, but we are pretty far behind upstream. If we could phase it out by release 13.0 or 14.0, I would think ~5 years is enough time to transfer? I can't imagine maintaining pf is an easy task at ALL either. I personally love it and use it, but since we have an alternative for which we can be the upstream of, I would say its worth it

Have you ever configured ipfw? it's not a pleasant experience. I'd rather go back to my high school days and pop 24 Benadryl so I can get chased by shadow people again...

Okay I'm exaggerating. But really I've done some research and it isn't even that much work to get PF up to date, just nobody's doing what needs to be done - if we can be porting the AMD drivers, which I don't even use and I don't know anyone here who uses AMD graphics anyways - then we can be keeping PF up to date, if without SMP support. Either way, ipfilter is bitrotted and needs to GTFO

 

[daemontrainer]

shadow people don't return my calls no more X.X

Back on topic, I guess its been awhile since I did legwork on the dif between mainline and our pf, but last time I checked our pf doesn't quite deal well with IPv6 and the syntax difference is pretty staggering (that one I had to check recently). I've configured standalone IPWF walls for servers that needed to restrict access of jail's networking (if server is serving me voice coms and email, it doesn't need every port open is my personal philosophy = | ). It wasn't that bad. Maybe a serious edge router is way worth of an experience. I might have to give it a shot for fun sometime soon than. Honestly its not as smooth as pf, and lacks a neet utility like pfctl. But I am not qualified yet to comment on things under its hood and can only parrot the official lines of "porting in kernel systems from system to system is very difficult, maintaining them is even harder". = \ I think the biggest transition to people would be the whole "last match vs first match". pf is unique in that regard as IPtables uses first match as well (what other firewalls are even out there that are used?Oo)

also ... I use AMD graphics ... just not on FreeBSD heh.

 

[BSD-Kitsune]

Well, you'll see what I have in store for a little project I'm brewing up. But ipfw isn't part of it. Unless someone comes on and wants to rewrite it's config syntax and give it external utilities to match pf.

Oh when it comes to our pf it's certainly not as prepared for ipv6, and the syntax is different. I'd probably say it would be easier to get a base working port of the new pf without the enhancements and patches to the current one applied, then deal with optimizing it - rather than trying to patch upward.

 

[Hunter Jozwiak]

As a blind user, I would like to see a kernel level text to speech system similar to Speakup for Linux. I don't know of a port that I could build in to a system and do an eyes free installation of a system on bare metal as of yet, and I would like to be able to take advantage of FreeBSD sans virtualization.

 

[eric oyen]

I am also a blind user and would appreciate seeing this kind of feature being implemented in the OS. In fact, BrlTTY would make a good interface. Also, I would like to see an install version that has speech/braille support built in. I had tried this with OpenBSD back in 2012, but the lack of support from the Devs (in specific, Theo) put paid to that project. Since I am not a coder, I ran into a lot of problems trying to get it working. So, any help anyone around here can give would certainly be appreciated.

thanks.

Eric
From the Central Office of the Technomage Guild.

As a blind user, I would like to see a kernel level text to speech system similar to Speakup for Linux. I don't know of a port that I could build in to a system and do an eyes free installation of a system on bare metal as of yet, and I would like to be able to take advantage of FreeBSD sans virtualization.[/

QUOTE]

 

[BSD-Kitsune]

It's very important to accommodate visually impaired people when it comes to an OS. The only pitfall I see here is having sufficient funding/maintenance overhead of such a system covered for a small percentage of our userbase.

 

[wblock@]

I'm probably the only one who still has an interest in text so this is a personal request. I'd like to see the backspace and delete problem fixed once and for all. Linux did it, we can too.

I don't have any idea what you mean by this. Some people have trouble with backspace and delete, but it's easy enough to configure in the shell startup. Set once, never touch again.

 

[Deleted member 9563]

I don't have any idea what you mean by this. Some people have trouble with backspace and delete, but it's easy enough to configure in the shell startup. Set once, never touch again.

So how does one make it the same everywhere? I've never gotten it to work properly and it is clear by the number of posts, both here and on the wider net, that I'm not alone in that predicament. At the moment it works in my editor, but not on the command line. Perhaps you can point me to some instructions. Google isn't helping me with this and I'm guessing it's just beyond my skill level.

This is not really the thread for me to go on about this, but I'll give it one last try.

Edit: I've just spent about 4 hours on this (yet again) but don't want to derail this thread, so I posted here: https://forums.freebsd.org/threads/59323/

 

[eric oyen]

well, therein lies the problem and the solution is within the problem itself.

To begin with, the only reason we are such a minority in the user base is that no one has even considered thinking about how to make the OS and install fully accessible. Because of this, no one is willing to support and thus we end up not being supported, thus remaining a very small percentage of the user base. The solution is to just create it and then advertise that fact to a lot of blind users (we are far more common as computer users than you know) You say that it's a maintenance headache and there would be some other factors. The fact is, there are 4 different versions of linux that do support this right from boot and so far as I know, no official line of any BSD does (OS X which operates on top of a version of FreeBSD does right out of the box).

to sum up:
there is a very small user base of blind users, only because there is no support. THere is no support because the devs can't justify the extra time. As a result, there are not a lot of blind users. and around we go again….

See what i am getting at?

-eric


So, how many blind computer users are there on the planet? Millions and a lot of them are either forced to use windows, some of them use OS X or Linux and very very few use any BSD whatsoever. A lot of them would rather have a nice secure free OS that is easy to work with without all the pain of dealing with a GUI that was never intended to be used by the blind. Linux offers this and its about time that BSD (any flacor) did too. btw, not many of us have the funds to afford an apple, so OS X is generally in the realm of not affordable by most.

My last point is this: why should I, as a blind person, be forced to depend on someone with working eyes to install and do the initial setup on a machine? GIven the technology available, I shouldn't have to (except for want of someone to implement it ONCE).

-eric

It's very important to accommodate visually impaired people when it comes to an OS. The only pitfall I see here is having sufficient funding/maintenance overhead of such a system covered for a small percentage of our userbase.

 

[sidetone]

What I was thinking of earlier, was that, until a BSD has support for blind or poor eyesight users, then it will gain widespread support from them.

It would make most sense to me, for FreeBSD or another BSD to have a spinoff (canned) distribution (as DesktopBSD or PCBSD are), that's supported by the blind support community, uses FreeBSD's packaging and is led to from here. They deserve to have their own OS, but having it in the FreeBSD base, doesn't benefit most of us. It makes sense for the blind community to support their own implementation of FreeBSD, or a fork, which is easy, because FreeBSD's license allows all kinds of uses.

I am curious if a blind person could install a FreeBSD operating system with blind user support, on their own, with as complex as setting it up can get.

 

[silicium]

After recently switching firewall from Cisco IOS to FreeBSD pf, I found many helpful good tutorials and examples for classic syntax and ALTQ, and will never accept or need OpenBSD's new pf.

 

[horseflesh]

I just learned the pf basics this weekend -- had my hand forced when I tripped over the nasty NAT issues currently in ipfilter. I was really surprised to find ipfilter in such a poor state.

 

[scottro]

I'd like the semi automated ZFS on root install to easily enable customized gpt disk labels. It can be done manually, but it's a lot of typing. (See Michael Lucas' book as an example)

 

[chrcol]

Drop the politics, this seems the problem of various other things.
Implement hardenedbsd code, even if its disabled by default. It is silly shaun has had to split off a fork.
Stop frequently changing syntax of various things, in last 5 years as an example there has been syntax changes in rc.conf and make.conf.
Ship with hardened binaries, PIE protection, DEP, SEHOP, etc. likewise use those flags by default in ports tree and on pkg binaries.
Out of the box MAC configuration.
Merge over modern PF from openbsd.

 

[BSD-Kitsune]

To begin with, the only reason we are such a minority in the user base is that no one has even considered thinking about how to make the OS and install fully accessible. Because of this, no one is willing to support and thus we end up not being supported, thus remaining a very small percentage of the user base. The solution is to just create it and then advertise that fact to a lot of blind users (we are far more common as computer users than you know) You say that it's a maintenance headache and there would be some other factors. The fact is, there are 4 different versions of linux that do support this right from boot and so far as I know, no official line of any BSD does (OS X which operates on top of a version of FreeBSD does right out of the box).

Two things:

OS X does not run any major FreeBSD code. The kernel is called XNU, and it runs on the MACH kernel architecture. Therefore that is a non-sequitur and irrelevant to your argument. Same goes for Linux - it's not a case of "Everyone else is doing it, why not you?" - that's a bandwagon fallacy.

Secondly I'll admit I have no idea how the visually impaired use a command-line based OS - my only experience with visually impaired accessibility systems is on Windows and OS X when I spent time as a desktop support tech. However, an auditory readout system of some kind would require a kernel module to be built - and this cannot be based off Linux or other implementations due to licensing issues, a set of userland tools to configure it and so-on. Because FreeBSD has a fraction of the total computer market, it's likely to not be a high priority item for quite some time. Now if you want it, the best thing to do would be to create a bounty by pooling your money with others who want the feature and pledge a bounty for a developer who implements an accessibility system for the visually impaired. Until then, I'm sorry to say, I don't see it happening. Now, personally I am sympathetic to your cause, and I like the idea, but I am not going to code it as there's far more work on the chopping block of higher priority. But I do agree that it is a needed feature - just not one that's going to happen anytime soon.

I do understand the need to be independent - my eyesight may be crap but I still have the luxury of being able to drive and be independent. You and millions of others do not have this luxury and sad to say but my friends who are visually impaired face a lot of issues in the workplace and just plain getting around, from people not being courteous of them to entrances/exits not being particularly friendly to them.

 

[sidetone]

Just suggest to the entire the blind computer using community to fork a BSD distribution or have a special build of BSD. That in itself is it's own following of users.

I don't understand how a visually impaired user can use the command line and edit text files for configuration. Because it is complex enough for me with the ability to see it.

I guess you could feel braille code, but that seems to be a whole new type of text file based on braille instead of pure alpha numeric. Configuration text files can't have major errors in them, or they won't work. The braille translation may not either be easy to use, to correct errors, like a simple leaving out of a comma or minor character can make the configuration file not work. I can also try to scan for errors in configuration or text files, as fast as I can figure it out. I don't think physically feeling for code can do that for a large amount of text in a reasonable time frame. It seems there needs to be a much simpler OS for your purposes.

@ eric oyen, Hunter Jozwiak, and others who it concerns