4 ms·
> What's better about the FreeBSD userland? For one example, take networking tasks: Task / BSD / Linux set ip / ifconfig / ifconfig or now "ip" which is conf
by GalacticDomin8r 13y ago
> What's better about the FreeBSD userland?
For one example, take networking tasks:
Task / BSD / Linux
set ip / ifconfig / ifconfig or now "ip" which is confusing
wifi / ifconfig / iwconfig
speed / ifconfig / miitool or ethtool
duplex / ifconfig / miitool or ethtool
vlan / ifconfig / vlan
wol / ifconfig / miitool or ethtool
bridge / ifconfig / brctl
link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart all networking or reboot server
Want find out which nic is occupying ethX perhaps for tuning or scripting etc?
Linux = complicated, by distro/version
FreeBSD = nic by device eg em0
- ajross 13y agoMost of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue. Certainly dumping everything in the same tool is no less "confusing". I just googled the FreeBSD man page for ifconfig -- yikes! The last bit is unfair. Yes, Linux distros have recently diverged on network device naming. But that's for a good reason: the old scheme wasn't robust against probe order, the new systemd one is, and FreeBSD's isn't either. The systemd naming (while ugly) is better, period. That's a feature for Linux, not a confusing problem with its userland.
- mitchty 13y agogiant? Freebsd 9.1 RELEASE: 260k /sbin/ifconfig My Arch box: 76K /usr/bin/ifconfig I have to use linux for work, but he's right, keeping everything in ifconfig is much more close to the old school "unix" way than "lets play 20 commands" that seems to be present in most linux mindsets.
- ajross 13y agoThis may be the first time I've every heard the "old school unix way" defined as (heh) "packing all related functionality into one command". But use what you like. Just don't pretend that it's anything other than taste.
- mitchty 13y agoIts more keeping networking related things for interfaces in the InterFaceCONFIG command seems to be a more "one tool for the same thing" in my mind.
- GalacticDomin8r 13y ago> I admit I'm chuckling a little about the idea of udev not being "needed". If you're calling my tastes simple then guilty as charged.
- oscargrouch 13y agoold school? what about git? > git pull > git push > git clone or would you prefer a binary for each command: > git_pull > git_clone > git_push now, what really looks old school to you?
- mitchty 13y agoIts one command with subcommands for each sub function. What you're contorting is more akin to: ifconfig_wireless ifconfig_vlan ifconfig_foo Bit of a reach there.
- GalacticDomin8r 13y ago> the old scheme wasn't robust against probe order Very true. > and FreeBSD's isn't either Very untrue. FreeBSD does serial enumeration which results in static devices each time. There is no equivalent tool in FreeBSD to udev or systemd because it isn't needed(although devd does a certain subset of some of their functionality). About the only place out of order probing can occur is with external disk expander where FBSD isn't doing the actual probing. In this case, labeling disks or using the cam wire down method. man 4 cam
- ajross 13y agoI bet you it doesn't. The BSD name a driver name and a number, and that's not enough state. If you swap two identical cards between PCIe slots, does it still work? If you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2? If you have a fixed external network with its own routing rules on a USB ethernet adapter, does it work correctly if you happen to boot with another such device connected? I admit I'm chuckling a little about the idea of udev not being "needed". :)
- kps 13y agoIf you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2? Am I misreading, or do you mean to say that if you replace a failed part, the ‘correct’ thing is for the replacement to come up with a different name so that the box stays out of production until someone can manually reconfigure it?
- GalacticDomin8r 13y agoThat's how I read it too....uff da.
- GalacticDomin8r 13y ago> I bet you it doesn't. What exactly are you willing to bet? > and that's not enough state. It's enough. > If you swap two identical cards between PCIe slots It's probed by slot so in the case you present no config would generally be needed unless you have something dependant on layer 2 in the setup. > If you pull em1 and add a new card in its place does it come up as em1 (incorrect) Yes it does and actually that is correct. I don't want to have to muck with configs simply because I swapped a nic. If you like doing it that way have at it. > If you have a fixed external network with its own routing rules on a USB ethernet adapter, does it work correctly if you happen to boot with another such device connected? Depends on the setup, you can have it pretty much do anything but by default it would work if you swapped it out with something that used the same driver. > I admit I'm chuckling a little about the idea of udev not being "needed". As someone who has ripped udev out of a distribution and replaced it with something easier(auto provisioning) for a specific large SaaS stack, I can assure you udev is not needed.
- oscargrouch 13y ago> Most of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue. No, its not that. It clearly shows how fragmented Linux ecosystem is.. On Freebsd, on the other side, if a new kernel/OS feature is created, the enginner/designer of that feature can count on, create (or modify) existing tools in the userland, cause he knows the userland will ship together with the modified version of the kernel(or dinamic module) It gives the whole system, a consistency; not easilly found anywhere else, much less in Linux.. if you start to use Freebsd for some time, you will just note this.. It gives you a better, and consistent experience, and i think is this what Unix should look like..