> Data centers are built with redundant network connectivity, backup power, and fire suppression. [...] The question is their relative frequency, which is where the data center is far superior.
Well, I remember one incident were a 'professional' data center burned down including the backups.
I know no such incident for some basement hosting.
Doesn't mean much. I'm just a bit surprised so many people are worried because of the server location and no one had mentioned yet the quite outstanding OVH incident.
I'm not going to pretend datacenters are magical places immune to damage. I worked at a company where the 630 Third Street datacenter couldn't keep temperatures stable during a San Francisco heatwave and the Okex crypto exchange has experienced downtime because the Alibaba Zone C datacenter their matching engine is on experienced A/C failure. So it's not all magic, but if you didn't encounter home-lab failure it's because you did not sample the population appropriately.
I don't have a bone to pick here. If F-Droid wants to free-ball it I think that's fine. You can usually run things for max cheap by just sticking them on a residential Google Fiber line in one of the cheap power states and then just making sure your software can quickly be deployed elsewhere in times of outage. It's not a huge deal unless you need always-on.
But the arguments being made here are not correct.
I was curious if they optimized the download. Did it download the 'optimized' ~150 GB and wasting a lot of time there or did it download the ~20 GB unique data and duplicated as part of the installation.
I still don't know but found instead an interesting reddit post were users found and analyzed this "waste of space" three month ago.
Not for 13ish years but we built the chat feature in a social networking platform with BOSH. Looked just like FB Messenger, really. The thing never took off, so I don't remember any talks about outside federation, I think it was not on by default.
It is apparently also hard to maintain over time. I heavily customized my Firefox and Thunderbird and it is annoying how often GUI components which should be equal (e.g. toolbar buttons in different places) look the same* but have multiple different CSS rules.
Some widgets, or rather the repeated reinventions of widgets in HTML+CSS, use variables and the next equally looking widget has none, or other variables with the same values.
From an outsider perspective it looks like a mess.
* or almost the same with minimal, likely unintended, differences like one button has a slight border when hovered but another button right next to it has none
> I understand that search bar position is not changeable by theming,
It is changeable. With enough dedication you can go a long way just with CSS.
In this case it is even rather easy because the "unified toolbar" the thing containing the search box, the menu bar (if shown) and the tab bar are three elements in the same flex box. They can be reordered by setting the order property.
Only downside in this case is that (if client side decoration is not disabled in the settings) the window buttons (close, minimize) are also part of the unified toolbar and would end (without further fixes) below the tab bar.
As a quick (and dirty) experiment I moved the tab bar left to the search bar in the same row just with:
And a hacky way which often works good enough is to reposition and hardcode stuff with position:absolute/fixed/sticky.
Finally Thunderbird's own customization dialog can be used to fill the empty space around the search bar. By default it has a spacer left and right but that is easy to change even without custom CSS.
> Also, note that some areas of ThunderBird are rendered outside of the influence of userChrome.css in a "Shadow DOM" - as such, it is not possible to fully theme all elements of Thunderbird.
With some limitations it is possible to restyle Shadow DOM elements. It is just a lot harder to select the right element if it is inside a shadow dom.
I found a workaround (don't remember where I found it) which I use extensively in my personal userChrome.css.
The basic concept (afair) is that you can write selectors which match inside the shadow dom as long as they do not need to "cross" the shadow dom "boundary".
A good starting point for me is often to select by tag and part attribute, e.g. image[part="icon"] { ... }
Now the trick to style a particular instance of a web component (shadow dom instance) is to use variables and defaults.
With a selector which targets the "root element" of the shadow dom I set variables for any value I want to change and with a selector which is fully inside the shadow dom I add styles using the variable (which is then only defined for that particular instance) or a default which effectively cancels my custom style anywhere else.
As concrete example the dialog to create new calendar events has a drop down box to select the calendar where each entry is prefixed with a dot with calendar color.
The menulist has a shadow dom and the menupopup another. I styled those dots as squares (for fun and because I think the modern web is to round).
So to set the variables on the "outside" I have:
(the variable prefix "parthack" has no special meaning; it just evolved because I initially used it to hack styles onto shadow dom elements over the part attribute)
Now this will change only the icons only in the menulist with id 'item-calendar' and leave others unchanged. Whether I use revert-layer as default or something else depends on what style the element has by default and try and error.
> it is also not possible to theme the settings areas.
I don't see a reason why this should not work. If by settings area the author means the settings page which in modern Thunderbird is more or less a web page in the content area, it should be stylable with userContent.css instead of userChrome.css.
The hard part is to find the right @-moz-document selectors for each individual content page.
Don't know what exactly PostCSS is but with a JavaScript addon it would probably be wiser to inject the custom css directly into the shadow dom instance if possible and avoiding such hacks.
Also, by the way, when JavaScript addons get involved: userChrome.css is applied quite unfortunate in the css cascade. It gets low priority that is why they are usually full of !important rules. With JavaScript it is possible to add custom css instead as so called author stylesheet which makes it easier to override default styles. (never tried it myself)
Provided you have a working IP stack, your ping service requirement is met admirably 8)
I run a lot of pfSense boxes and they (and OPNSense) have a pinger daemon to test connectivity which is really useful for multi-link routing. Bad idea for single links because you add an extra thing to fail. On a router with multiple internet links they are handy. You mostly ping known "reasonably stable" anycast addresses - they are the best option and usually end up being DNS servers - 1.1.1.1, 8.8.8.8, 8.8.4.4 etc are all good candidates.
Bash is slower than other POSIX compatible shells but once you start running external commands for any substring or replace operation you loose much of this performance edge since forking is comparable slow.
One reason why I personally prefer to use Bashisms like ${x//str/replace} or [[ $value =~ $pattern ]] instead of doing the common x=$(echo $x | sed s/str/replace/) which has to launch two processes just for the sake of avoiding Bashism. (or grep -oP ... which is nice but a BASH_REMATCH is often simpler)
If the script does a lot of unstreamable replacements, you're right. But there are still ways out of bash.
I prefer no fork, no bashism, reusable functions:
set -euf
replace () {
local t=
REPLY=$1
t="${REPLY#*"$2"}"
test "$t" != "$REPLY" || return
REPLY="${REPLY%"$2$t"}$3$t"
}
replace_all () {
REPLY=$1
shift
while replace "$REPLY" "$@"; do :; done
}
input="foo bar foo baz"
replace_all "$input" "foo" "HELLO"
echo $REPLY
Not exactly easy to write, but now that they're functions, it doesn't matter since I can reuse them.
Regarding performance, it is slower than bash, but not significantly.
Times for 1000 calls:
9.908s -- sed (one fork per replacement)
0.015s -- bash x//str/replace
0.088s -- sh replace_all
Times for 50.000 calls:
0.351s -- bash x//str/replace
0.631s -- sh replace_all
Also, you can get further performance by inlining replace inside replace_all instead of making one call another.
Note that I could have done several replacements inside a single sed pipe, but I decided to count the performance for doing it like you suggested x=$(echo $x | sed s/str/replace/). The same goes for my functions, one invokation per replacement (in fact, they are tuned for that scenario).
sed can absoltely beat the shell in scenarios where you can make one fork do lots and lots of replacements. It depends on the scenario, and how proficient you are in writing sed (which can do branching, keep state, all sorts of things portably).
--
From an architectural point of view, it makes sense to have a simpler `sh` and keep a sort of standard library of functions, instead of feature creeping the interpreter with weird arcana. It makes shells like dash easier to maintain, easier to debug, easier to port and safer.
The reason Bash has so many features is that doing these things natively in the shell is faster and more convenient. After all, these features weren't just added randomly.
These features were added slowly, randomly, as time passed. The weird syntaxes for all of these are a clear sign of this.
Practically all shell interpreters suffer from decades of feature creep since the original bourne shell. They're full of weird arcana, hard to maintain and debug.
Many people tried to replace bash and died on the hill because of these weird features, or ended up creating a replacement that is even slower, or ended up rediscovering what perl is.
Well, I remember one incident were a 'professional' data center burned down including the backups.
https://en.wikipedia.org/wiki/OVHcloud#Incidents
I know no such incident for some basement hosting.
Doesn't mean much. I'm just a bit surprised so many people are worried because of the server location and no one had mentioned yet the quite outstanding OVH incident.