@claudius @narylis @gsuberland @whitequark
That's the point 😆🤦♂️
Unless someone can finally make a distribution of Linux that someone can use with their existing knowledge of computing then it won't get more than 10% desktop usage.
@ppxl @gsuberland @piko @narylis @whitequark
> Italian far left software kolchose
I'm laughing under my desk, LOL 🤣🤣🤣
@narylis @gsuberland @whitequark oh wow, that’s actually a surprise to me
But memes aside indeed, I was shocked to find recently that Python 3.12 is finally in FreeBSD ports and even works fine as a dependency (it was languishing in approval hell for more than a year)
@gsuberland @karlauerbach sure, you can complain about those bad naming choices, but they did come up with “ip”.
Oh, sorry, I meant
ip [ OPTIONS ] OBJECT { COMMAND | help }
OBJECT := { link | addr | addrlabel | route | rule | neigh | tunnel | maddr | mroute | monitor }
OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] | -f[amily] { inet | inet6 | ipx | dnet | link } | -o[neline] }
ip link set DEVICE { up | down | arp { on | off } |
promisc { on | off } |
allmulticast { on | off } |
dynamic { on | off } |
multicast { on | off } |
txqueuelen PACKETS |
name NEWNAME |
address LLADDR | broadcast LLADDR |
mtu MTU |
netns PID |
alias NAME |
vf NUM [ mac LLADDR ] [ vlan VLANID [ qos VLAN-QOS ] ] [ rate TXRATE ] }
ip link show [ DEVICE ]
ip addr { add | del } IFADDR dev STRING
ip addr { show | flush } [ dev STRING ] [ scope SCOPE-ID ] [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ]
IFADDR := PREFIX | ADDR peer PREFIX [ broadcast ADDR ] [ anycast ADDR ] [ label STRING ] [ scope SCOPE-ID ]
SCOPE-ID := [ host | link | global | NUMBER ]
FLAG-LIST := [ FLAG-LIST ] FLAG
FLAG := [ permanent | dynamic | secondary | primary | tentative | deprecated ]
ip addrlabel { add | del } prefix PREFIX [ dev DEV ] [ label NUMBER ]
ip addrlabel { list | flush }
ip route { list | flush } SELECTOR
ip route get ADDRESS [ from ADDRESS iif STRING ] [ oif STRING ] [ tos TOS ]
ip route { add | del | change | append | replace | monitor } ROUTE
SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ] [ table TABLE_ID ] [ proto RTPROTO ] [ type TYPE ] [ scope SCOPE ]
ROUTE := NODE_SPEC [ INFO_SPEC ]
NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ] [ table TABLE_ID ] [ proto RTPROTO ] [ scope SCOPE ] [ metric METRIC ]
INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ] ...
NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS
OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ] [ rtt TIME ] [ rttvar TIME ] [ window NUMBER ] [ cwnd NUMBER ] [ initcwnd NUMBER ] [ ssthresh REALM ] [ realms REALM ] [ rto_min TIME ] [ initrwnd NUMBER ]
TYPE := [ unicast | local | broadcast | multicast | throw | unreachable | prohibit | blackhole | nat ]
TABLE_ID := [ local| main | default | all | NUMBER ]
SCOPE := [ host | link | global | NUMBER ]
FLAGS := [ equalize ]
NHFLAGS := [ onlink | pervasive ]
RTPROTO := [ kernel | boot | static | NUMBER ]
ip rule [ list | add | del | flush ] SELECTOR ACTION
SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK[/MASK] ] [ dev STRING ] [ pref NUMBER ]
ACTION := [ table TABLE_ID ] [ nat ADDRESS ] [ prohibit | reject | unreachable ] [ realms [SRCREALM/]DSTREALM ]
TABLE_ID := [ local | main | default | NUMBER ]
ip neigh { add | del | change | replace } { ADDR [ lladdr LLADDR ] [ nud { permanent | noarp | stale | reachable } ] | proxy ADDR } [ dev DEV ]
ip neigh { show | flush } [ to PREFIX ] [ dev DEV ] [ nud STATE ]
ip tunnel { add | change | del | show | prl } [ NAME ]
[ mode MODE ] [ remote ADDR ] [ local ADDR ]
[ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
[ encaplimit ELIM ] [ ttl TTL ]
[ tos TOS ] [ flowlabel FLOWLABEL ]
[ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete ADDR ]
[ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]
MODE := { ipip | gre | sit | isatap | ip6ip6 | ipip6 | any }
ADDR := { IP_ADDRESS | any }
TOS := { NUMBER | inherit }
ELIM := { none | 0..255 }
TTL := { 1..255 | inherit }
KEY := { DOTTED_QUAD | NUMBER }
TIME := NUMBER[s|ms|us|ns|j]
ip maddr [ add | del ] MULTIADDR dev STRING
ip maddr show [ dev STRING ]
ip mroute show [ PREFIX ] [ from PREFIX ] [ iif DEVICE ]
ip monitor [ all | LISTofOBJECTS ]
ip xfrm XFRM_OBJECT { COMMAND }
XFRM_OBJECT := { state | policy | monitor }
ip xfrm state { add | update } ID [ XFRM_OPT ] [ mode MODE ]
[ reqid REQID ] [ seq SEQ ] [ replay-window SIZE ]
[ flag FLAG-LIST ] [ encap ENCAP ] [ sel SELECTOR ]
[ LIMIT-LIST ]
ip xfrm state allocspi ID [ mode MODE ] [ reqid REQID ] [ seq SEQ ] [ min SPI max SPI ]
ip xfrm state { delete | get } ID
ip xfrm state { deleteall | list } [ ID ] [ mode MODE ]
[ reqid REQID ] [ flag FLAG_LIST ]
ip xfrm state flush [ proto XFRM_PROTO ]
ip xfrm state count
ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]
XFRM_PROTO := [ esp | ah | comp | route2 | hao ]
MODE := [ transport | tunnel | ro | beet ] (default=transport)
FLAG-LIST := [ FLAG-LIST ] FLAG
FLAG := [ noecn | decap-dscp | wildrecv ]
ENCAP := ENCAP-TYPE SPORT DPORT OADDR
ENCAP-TYPE := espinudp | espinudp-nonike
ALGO-LIST := [ ALGO-LIST ] | [ ALGO ]
ALGO := ALGO_TYPE ALGO_NAME ALGO_KEY
ALGO_TYPE := [ enc | auth | comp ]
SELECTOR := src ADDR[/PLEN] dst ADDR[/PLEN] [ UPSPEC ] [ dev DEV ]
UPSPEC := proto PROTO [[ sport PORT ] [ dport PORT ] |
[ type NUMBER ] [ code NUMBER ]]
LIMIT-LIST := [ LIMIT-LIST ] | [ limit LIMIT ]
LIMIT := [ [time-soft|time-hard|time-use-soft|time-use-hard] SECONDS ] | [ [byte-soft|byte-hard] SIZE ] |
[ [packet-soft|packet-hard] COUNT ]
ip xfrm policy { add | update } dir DIR SELECTOR [ index INDEX ]
[ ptype PTYPE ] [ action ACTION ] [ priority PRIORITY ]
[ LIMIT-LIST ] [ TMPL-LIST ]
ip xfrm policy { delete | get } dir DIR [ SELECTOR | index INDEX ]
[ ptype PTYPE ]
ip xfrm policy { deleteall | list } [ dir DIR ] [ SELECTOR ]
[ index INDEX ] [ action ACTION ] [ priority PRIORITY ]
ip xfrm policy flush [ ptype PTYPE ]
ip xfrm count
PTYPE := [ main | sub ] (default=main)
DIR := [ in | out | fwd ]
SELECTOR := src ADDR[/PLEN] dst ADDR[/PLEN] [ UPSPEC ] [ dev DEV ]
UPSPEC := proto PROTO [ [ sport PORT ] [ dport PORT ] |
[ type NUMBER ] [ code NUMBER ] ]
ACTION := [ allow | block ] (default=allow)
LIMIT-LIST := [ LIMIT-LIST ] | [ limit LIMIT ]
LIMIT := [ [time-soft|time-hard|time-use-soft|time-use-hard] SECONDS ] | [ [byte-soft|byte-hard] SIZE ] |
[packet-soft|packet-hard] NUMBER ]
TMPL-LIST := [ TMPL-LIST ] | [ tmpl TMPL ]
TMPL := ID [ mode MODE ] [ reqid REQID ] [ level LEVEL ]
ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]
XFRM_PROTO := [ esp | ah | comp | route2 | hao ]
MODE := [ transport | tunnel | beet ] (default=transport)
LEVEL := [ required | use ] (default=required)
ip xfrm monitor [ all | LISTofOBJECTS ]
ifconfig and route have been maintained and continues to do its job, instead of fragmenting it across a zillion other tools with no documentation besides its bnf@starsider @atax1a @avuko I use route and ipconfig exclusively except in cases where I'm doing a complex setup they can't do.
The norm should not be that we deprecate simple familiar interfaces and replace them with overengineered bs whenever someone thinks of a new niche usage case the familiar interface doesn't handle.
It should be that the simple thing remains the default and well-maintained, and the specialized complex tool is something you only get out and learn if you need it.
@dalias @atax1a @avuko I find ip to be as simple (or as complex) as ifconfig, the only difficulty was it being a bit different so it messes up with muscle memory, but it's no big deal IMHO.
Note that ifconfig, route and several other utilities were part of the net-tools package, which unlike the BSDs it was not developed in sync to the kernel, it's a separate project. To support newer features, a rewrite was pretty much necessary, and if they rewrote the old commands with the old syntax it's very likely they would have broken things along the way, so they started a new tool to rule them all.
@starsider @atax1a @avuko I don't see any of this conflicting with what I said. I specifically said nobody needed to add significant new features to ifconfig. They just need to stop trying to break workflows using it.
The reason I deem ifconfig simpler and preferable is that its data model is just "modifying properties of a static thing" rather than "adding and removing things". Doing things with the ip command has complex state where you have to explicitly tear-down/remove old config you created before setting something different. You can't just "ifconfig ifname aaa.bbb.ccc.ddd" and be done. Even for experts, I deem the ifconfig workflow easier. For folks without suitable background knowledge, I can't even imagine trying to teach them to use ip by hand.
@dalias You can just do "ip addr replace" instead of "ip addr add", it always works even if the device didn't have an address already. Same with "ip route replace", functionality which the old route command didn't even have: you have to explicitly delete the old route. By this metric, route is stateful and complex where ip is not! You can just replace the route.
The only problem I see is that bringing the interface up still requires a separate "ip link set eth0 up", but it's a no-op if it's already up so you can just alias it to write less.
@starsider Ah that's very useful to know.
And *completely non-discoverable* !!
As usual, the worst part about these replacements is the atrociously bad "documentation" that's nothing but bnf expressions.
@dalias @starsider @atax1a @avuko
I think that specialized is the wrong way around, there. Usually it is the generalized tool, the one that can do every possible niche task (e.g. openssl even containing a WWW server) that is complex. Whereas the specialized tool (e.g. other SSL tools that do only SSL wrapping) is the simpler.
#ifconfig is the example that most people bring up, but the tale of #ps on Linux is also interesting as a different case study.
@gsuberland @karlauerbach if anything I read it as an argument *for* systemd — where we start to have some half consistent interfaces and broadly comprehensible names
Even if it does come with a slight churn cost
Personally I thought you were pointing fun at npm et al, where somehow a simple web project immediately involves glueing three almost identical yet randomly distinct ‘build tools’ together in chamber of horrors that'll be broken tomorrow because the beeptybopity zapity migration
@zbrown @gsuberland I find systemd to be close to gibberish, especially when something fails and it wants me to run things like journalctl.
I admit that Unix/BSD management commands could be obscure, but at least one learned the brain-muscle memory to use 'em. And their man pages fit on a single screen.
Personally I would have preferred that, if systemd were to exist at all, that it effectively have no real command line interface (it would have one for testing and emergency use) but would offer a network based interface that used JSON or the like to express commands and return results. That way people could write nice overlays that were less gibberish-ful.
(I actually hate NetworkMangler more than I hate systemd.)
As for npm - I've used it and felt like a tsunami of megabytes upon megabytes had washed upon me. I can see why people like the service and widgets that it provides, but the underlying implementation seems to have been struck by cancer.
@karlauerbach @gsuberland much of the tools, systemctl especially so, are already quite thin (albeit ‘pretty printed’) wrappers around bus calls
https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html
Things like cockpit already exist to provide alternative interfaces, in their case a web UI, for service management et al
And yes I don't really do overly much with networks but sometimes I have to diagnose something and NM/wpa_supplicant seem to mostly exist to fight with each other and systemd for at times little reward…
@karlauerbach @gsuberland ModemManager though, tried to make sense of that one once
Despite its name it doesn't behave particularly like NetworkManager, and it's cli was somehow bizarrely fragile, don't think I ever got much out of it
Bluetooth as ever is where one goes for the true horrors
@zbrown @gsuberland Ah yes, wpa_supplicant. I vaguely remember having a very nasty wrestling match with it.
I tend to need network interfaces that are mine, all mine; raw with no protocol looking at or emitting packets. NetworkMangler insists on sticking its greasy-sticky fingers on an interface with every change in link-state.
I used to have scripts to go into NetworkMangler's control files and tell it to keep its dirty mitts off various interfaces. But now they've gratuitously change the format and location of those control files.
@Qybat @gsuberland Oh, those sound like useful tools.
I use Imagemagick for many things so if I were write something like your Iconflex I'd probably try to make imagemagick the underlying manipulation engine. But recently someone decided to change the command scheme so that I now get piles of messages saying things like "convert is obsolete, use 'imagemagic convert'" (or the reverse). Change for the sake of change?
@karlauerbach @gsuberland I was thinking the other day how even when its a shortened word (like rm) its still damn user unfriendly for anyone outside the cliche
And then powershell goes and does the opposite and calls it “delete-filesystem-object” or whatever