>Organizations with a software budget should be happier to pay a fair price for ethical, user-first software from a friendly vendor than for a closed-source product from a megacorp.
Yet we don’t pay for Linux, grep, vim, etc, etc. Why is your open source project the only one worthy of requiring payment?
IMO you should drop the doublespeak of claiming these are open source values while simultaneously charging money. It’s offensive to people who contribute to actual open source projects like matrix, clang, Linux, kubernetes, and on and on.
Grep and vim are a much smaller magnitude than Linux, so don't mix the two. And you do pay for Linux indirectly, it ain't written by some developer in their basements out of their good heart for a long time. It's written by Intel, Nvidia, cloud vendors' etc - full salaried employees. You just pay for it via hardware or cloud fees.
But to be honest your stance is extremely detached from reality. It's a huge privilege to be able to work on a hobby project, people tend to need food and a place to live, you know?
Grep and vim are obviously stand ins for a myriad of tools that together are much larger than Linux. And even Linux still has unpaid volunteers and even the majority corporate contributors are not that relevant to the discussion because none of them have control over the project to the degree that they could enshittify it.
> people tend to need food and a place to live, you know
That has never been enough reason to require that others support your business model. I for one don't need or want any more "products" in my life, especially ones that are or depend on services I can only get from a single vendor.
Etymologically, a product is a thing which is produced. But it's unpleasant to think about how the sausage gets made, so nobody wants to consider the goods in their lives as products. They want their Nikes to simply pop into existence before them.
Tools like grep and vim dangle by a thread based on volunteer work, and open-source maintainers are famously prone to burnout. Some tools survive by being very small—nobody's out there updating `ls` every month—but the only sustainable way to maintain a large piece of software is with a salaried workforce.
You may not want to interact with the systems that produce Zulip for you, but you should be suspicious of goods that hide their status as products. There's no such thing as a free lunch.
Do you think clang, linux, and kubernetes could ever exist and survive in their current forms without the work of salaried developers? Volunteer maintenance is not sustainable; the long hours of unpaid labour are famously prone to causing burnout.
Free software is free as in speech, not free as in beer. If you want to save your cash, go use discord. If you're not paying, you're the product.
Had a thermometer read 170F 76C inside my black on black vehicle with windows cracked.
Decided to keep my battery devices in a cooler with cool and frozen water bottles to drink when I return. Phone, camera batteries, and a portable vehicle starter.
People are being shot that are interfering with said federal agents. Absolute excessive use of force but it’s stupid to present this as if there isn’t an easy way to avoid it.
My dude.. have you considered the possibility that some people on this very forum have voted for this actual very thing you are complaining about? I am not even passing judgment, but merely stating a fact. If anything, your comment shows severe disconnect from the societal mood.
How would you not consider that fact? Do you think I don't know there's plenty of people who think of HN as a nazi bar? Do you think the hacker ethos is to consider the "societal mood"?
Even fast LACP needs three seconds and that's on the same collision domain.
How does BGP actually detect a link is down? Keep alive default is 30s but that can be changed. If you set it to say one second, is that wise? Once a link is down, that fact will propagate at the speed of BGP and other routing protocols. Recovery will need a similar propagation.
Depending on where the link is, a second can be a "life time" these days or not. It really depends on the environment what an appropriate heart beat interval might be.
Also, given that BGP is TCP based, it might have to interact with other lower level link detection protocols.
It can get a bit hardware dependant but getting <50ms failovers from software based BFD in BIRD or FRR is fairly easy, and I've tested down to < 1ms before with hardware based BFD echo. ~50ms is the point at which a user making a traditional VOIP call won't notice the path switch.
You can get NIC's for computers (like most Nvidia/Meallanox or higher end Broadcom/Intel NIC's that do hardware BFD, and its obviously included in higher end networking kit.
You then link the BGP routes to the health of the BFD session for which that path is the next hop, and you get super quick withdrawls.
I.e. bird detects interface failure but this affects only your side of decision making.
For bidirectional failure detection you do BFD with BGB. BFD default timers are 3 times 30 ms, iirc.
I have both my own multihomed ASN and operate my own nameservers. The latter has usually been about as fast for failover overall in practice. BGP may look to converge near instantly from your 2-3 peer outbound perspective but the inbound convergence from the 100k networks on the rest of the internet is much slower and has a long tail very akin to trying to set your DNS TTL to 0 and having the rest of the internet decide to do it slower for cache/churn reasons anyways.
The bigger problem, and where BGP multihoming is most handy, is it's just so much easier to get a holistic in+out failover where nothing really changes vs in DNS where it's more about getting the future inbound stuff to change where it goes. E.g. it's a pain to break an active session because the address had to change, even if DNS can update where the new service is quickly.
The long tail of routers receiving your update doesn’t matter. Once the common transit networks get it, that’s where the rest would dump the traffic to reach you anyway. The only time slow propagation to the edges matters is the first time announcing a prefix after it has been fully withdrawn.
Using the wrong route to get the packet in your general direction still gets you the packet as long as it hits an ISP along the way that got the update.
We could fully drain traffic from a transit provider in <60s with a withdrawal with all of the major providers you get at the internet exchanges. If you weren’t seeing that your upstream ISPs may have penalized you for flapping too much and put in explicit delays.
<60s sounds about right as a general safe estimate. I just mean people should expect 1-2ish orders of magnitude more than <1s from a downed link with internet BGP upstreams in a multihomed situation.
If it were flap suppression/slow peer detection/"the dunce bucket" there wouldn't be a long tail of convergence - it'd just be nothing until all at once. This also isn't something I've only seen on my personal AS alone, it's what I've come to expect in many enterprise cutovers while previously working at a network VAR. The personal AS is however much more carefree to move around to different random providers on a whimthough of course :).
I found some data from an oldish post by benjojo https://blog.benjojo.co.uk/post/speed-of-bgp-network-propaga... which confirm various tirr 1s do propagate updates across their networks very fast (<2ish seconds) while others certainly do not. Notably, Level 3 (now Lumen) is the largest BGP presence by prefix count and was the worst tested in the list - starting to apply at ~20s after to finishing at ~50s after. This was for announce specifically, which should be the clearer case.
What has this “team” actually achieved? I keep reading these manager cosplay blogs/tweets/etc but they aren’t ever about how a real team was replaced or how anything of significant complexity was actually built.
reply