If you could change one thing in FreeBSD...

PCBSD-Netmanager

Lorem-Ipsum said:
I would like a Ncurses/GUI wireless network manager. I find it a bit tedious every time I open my laptop to type in the commands manually.

If not then I'm sure I'll get around to scripting it.
Click to expand...
I just found that the PCBSD-Netmanager is now in the FreeBSD ports collection. I think this may be what you want. It will work in the system tray with xfce4 (not sure about others).
But beware that it is KDE dependent and the ports will want to compile and install all of KDE, Qt, etc. Nevertheless, I'm installing it now.
 
As a hobbyist musician, MIDI software sequencer support. No softsynth, just driver for USB class-compliant hardware, and maybe for legacy ports on i386.
 
I wish FreeBSD was on my phone. While taking on Android is almost impossible with its vast number of native apps there could be a chance with Firefox OS which uses Gonk as an underlying system. With most apps for Firefox OS are to be written in HTML5 and Gecko already running just fine on FreeBSD (see www/firefox) the porting effort should be considerably lessened. It's mostly integration with B2g/Gaia and keeping up with upstream.
 
It would be nice if user home directories were automatically set with permissions that prevented other non-wheel shell users from accessing them.
 
To be honest, as odd as it may sound to some, I wouldn't change anything. I started using FreeBSD mainly out of curiosity. It's extremely well documented, soundly secure, has a great community, and is headed by a group of competent developers that care about it. Sure it doesn't always have the latest and greatest updated technology, but when that technology is added, it is integrated right and ends up very stable in the end. I personally care about security, stability, and control first. I have yet to encounter a problem that couldn't be remedied spending some time searching Google, the forums, or mailing lists, and I'm new to UNIX or UNIX-like operating systems in general. The community support is excellent provided your willing to do your homework learning regardless of technical background, and the base operating system and userland is consistent throughout updated versions. I personally feel a sudden large influx of users and/or developers could change that. I also personally hope FreeBSD continues the same path it has been taking in the future and will continue to learn and use the operating system for what it is; a stable, secure, and general purpose operating system for whatever your needs.

-Regards
 
I really like FreeBSD . Its the best at letting you own your configuration, without undoing what maintainers have decided was best .

I lack the skill to code anything useful to the FreeBSD whole . If I had one wish, it would be that the FreeBSD toothfariy would pop out my USB and smach we with an ASM on up magic wand .

Can someone make a package or ports of that for me ?

I just need to study .

It would be great if there was a place for non-coding morons to climb the knowledge ladder, while being useful to FreeBSD at the same time .
 
Maybe a bit more obscure, but I´d really like to see this for PAM:
Code: 
auth        sufficient    pam_unix.so nullok try_first_pass
[B]auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success[/B]
auth        sufficient    pam_winbind.so cached_login use_first_pass
auth        required      pam_deny.so
This example is from Fedora 17 /etc/pam.d/system-auth

It would make a really big difference for all local accounts that now have to wait a minute or so for winbindd to go through our domain before getting logged in.

/Sebulon
 
My top choice is (today, anyway) the item of the following list may glean enough attention from this post to eventually be a feature:

A utility which would wrap Xorg to actually write a working Xorg.conf (cycling through hundreds of user-submitted ones? ) upon the first or second attempt
...
A set of flowcharts (each huge) which contain almost all edge-cases for installs (cups,
GPT, MBR, geli, zfs, ...) and a repository for them...
...
Alternately, a utility similar to the first above, which does the work of the second
above (of course, both could be better...)
...
pkgng as an optional default or as optional, for those wishing to retain
methodologies which may work better now than in the V11 V12 instances...
 
I would like an ifconfig implementation which allowed for using MAC addresses instead of interface names. Example:
Code: 
# ifconfig em0 inet 1.2.3.4/24 #old
# ifconfig -M "00:11:22:33:44:55" inet 1.2.3.4/24 #alternative

# ifconfig em0.9001 create inet 1.2.3.5/24 #old
# ifconfig -M "00:11:22:33:44:55.9001" create inet 1.2.3.5/24  # new
I'm sure there's a ton of corner cases here, but something like this might allow for more consistent configurations, independent of how physical cards are re-arranged.
 
Carpetsmoker said:
I would replace rc.d with systemd and add more entries to /proc/ such as cpustat.
Click to expand...

My troll detector is currently in repair, could this be a case of posting drunk, smoking the wrong carpet or do we have to report an account as stolen?
 
Making part of /etc/rc.conf depend on the network

There are a few things I'm currently working on (and which I'll share here in due course), but the one thing on my TODO list that I just can't seem to find the time for is making part(s) of /etc/rc.conf dependent on which network you're on (if any). For example, I'd like to be able to easily specify something like this:
  • When at home: set the hostname, start sshd(8), start sendmail(8) (or another MTA, I don't care) for relaying to the local mailserver, run ntpdate(8) using the local NTP server and start client-side NFS.
  • When at work, university or even just on the road, pretty much anywhere where you'll get a dynamic IP: only set the hostname if DHCP didn't already do so and start sshd(8) but don't do the other stuff or establish a VPN connection to home first.
  • When there's no network at all, set the hostname to something amusing but don't even bother with any of the other stuff.
I think this could be quite useful to (travelling) laptop users and I know it's possible to rig something yourself, but it requires quite a bit of hacking and knowledge of how the rc(8) system works. I have some ideas for extending rc(8) such that it becomes easier to do this, but I just can't seem to find the time to work on it :(:r
 
Nukama said:
Integration of a FreeBSD Xen-DomU template for Qubes OS.
Click to expand...

Come on, you've got to think bigger: we might not want a FreeBSD DomU (running under systemd nonsense) as much as FreeBSD Dom0 running like Qubes, i.e. with 'AppVms' but (like older Qubes) not forcing removing host OS networking. I don't mean for security paranoia (others here might) as much as for usability/productivity: it'd be great to let FreeBSD run other OSes you can open their programs in the same X (or whatever GUI) session (maybe even sometimes logging in on pure non-GUI terminal session?) as if they were part of it (rather than inset in an emulator/virtual-machine window you have to key in & out of.) It'd be a huge task (and probably actually a fork) but potentially increasing popularity if people could run FreeBSD like that, run other OSes inside almost as if they were part of it, then don't have to run those outside of it anymore, rather than run them in a more stable system... then you get the advantage of having maybe all possible package repositories/managers and maybe even professional software from some quite different OSes, without having to run those OSes directly on hardware instead of killing or reinstalling them when they crash, without even rebooting... or trying adding in another that has the same software (if FreeBSD doesn't yet or can't)

Another thing I'd like to see is Radeon Open Compute (ROCm.)
 
You must log in or register to reply here.
Back
Top