Mozilla itself didn't think the Gecko engine itself has a long term future either. After all, Mozilla funded the development of the new Servo engine for eight whole years, and it slowly replaced pieces of Gecko with Servo.
After Mozilla laid off all Servo developers in 2020, the future doesn't look bright for Gecko or Firefox.
Hey, I live near you. Agree on multiple points. I doubt most people from the coasts would believe how good the food and drink scene in Winona and La Crosse is.
Everyone I know in the API / CDN / Proxy space switched from using ab to wrk years ago for good reason. PSA: Please stop using ab and use wrk/wrk2. ab doesn't even support HTTP 1.1...
Most of your above list would be taken care just by sticking to Ubuntu on Thinkpads using gnome-session-flashback. Its basically a polished version of the same DE I have been using since 2004 and love... rock solid (not of the boot or HW issues you mentioned, etc). I spend like no time ever messing with it and its been that way since 2014, 2016?
I'd use this over cgit. For exposing a read-only view of my repo on a barebones server. This does not include issues, pull-requests etc. and that is useful in some scenarios.
We had a kitchen and hundreds of people. Dorms are not designed for students to regularly cook, and even if they were, a shared kitchen seems even less sanitary than a meal hall
It's not uncommon, but it's also calibrated to the negligible number of residents who want to use the kitchen. If everyone in the dorms suddenly had to eat out of that kitchen, there'd be a several-day waiting list to use it.
US colleges earn money off the meal plan and tend to be liability shy so having a full kitchen is a non-starter. Heck, it was against the rules to have a microwave in dorms (even room not in actual dorms) where I went to college. It was a pain in the butt.
Pretty sure the ban on microwaves was an electrical fire risk, not them being predatory about students eating at the dining hall. Can you imagine if even every other room had an appliance pulling 1000W whenever the hell a student felt like warming up some soup?
>Can you imagine if even every other room had an appliance pulling 1000W whenever the hell a student felt like warming up some soup?
Can you imagine if even every other room had an appliance pulling 1000W whenever the hell a student felt like blowdrying their hair after their shower?
The main problem with the provided dorm microwaves when I was in school was burned popcorn sending the entire dorm outside at 4am until the campus security could come and turn off the alarm.
I find Go's approach to be in the Goldilocks zone. Its not intrusive enough to slow me down (or guarantee correctness for that matter...) but its enough that I no longer need to save the multi-threading something I know needs to be multi-threaded for a second pass and very rarely have multi-threading issues or trouble debugging.
That being said, developers often have a bit of learning to get there, but that can greatly be accelerated by good team/mentor code review and discussion.
Goroutines are definitely an improvement, no argument from me.
It's just that there exist ways to shoot yourself in the foot quite easily.
Example: I'd find it much more intuitive if writing to a closed channel returned an error value and didn't issue a panic.
But I'm guessing that the Go programmers get used to the assumptions that must be made when working with the language so such things are likely quite fine with them and cause them no grief.
Such things bites everyone. But writing to closed channel is regarded as programming error. You potentially lose values. So logic should be watertight, which is hard with concurrency. Doing simplest approach to locking helps.
Better with panic than silent errors and flawed logic.
