Sure, but on the other hand the Babylon bee is a bit of a right-wing shitrag. So it's also important to play to your audience and consistently reinforce the fundamental nature of arbitrary gender stereotypes.
While I do think the underlying pushes to per-wafer density will no doubt lead to cheaper memory prices per capacity, unfortunately I believe the vast majority of the over production in the near term won’t be useful for the consumer market since it’s all going into HBM right now and not modular sticks like the typical DDR SDRAMs.
Besides the obvious problem of racialised body proportion comparisons (and more so: genitalia focused ones introduced as ‘Chinese pee-pee’ and ‘African tribal DICK’) - the term itself also remains one reliant on reductive exoticism that’s highly othering. Finding humour in stereotypes doesn’t negate harm.
Want to highlight a specific geography? Use the region. Want to highlight a specific population or ethnic group? Use that. Want to talk about your scientific racism and at least sound believable? - at least just use ‘sub-Saharan Africa’ so not everyone spots that you’re a nut instantly.
And just to be very explicit why this is an issue: each time the package is upgraded through an automated update, the PKGBUILD may change (e.g. to adapt to different dependencies, file structure, etc introduced with new app version).
That also means an AUR maintainer can smuggle in malware with any of those updates, even if you checked the original PKGBUiLD when you installed. And, anyone can request taking over maintenance for unmaintained packages, so it can even happen if the original maintainer was benevolent.
Always check PKGBUILD files on upgrade, even if just a glance. If I remember correctly yay had a function to always show you PKGBUILD diffs before updates, not sure if that was automatically enabled.
Cause that particular tears of joy emoji only became standardized in Unicode 6.0, 2010. It was presumably around a bit before that but nobody except the Japanese really did a lot of emoji stuff much before that (iirc Google and Apple only started adding the first emoji to their keyboards 2007-08).
Either way would find it very interesting if somebody was already using the emoji way before that, or the text area of the picture went through multiple iterations.
isn't the better solution not to accept PRs from unknown / untrusted sources
I think that's partly the point of this exercise - if they find a meow they now know this is an untrusted source.
Because it's pretty easy to say 'ignore untrusted sources' but when you're maintaining an open source repo (especially if it's still pretty small/new) this detection is part of the cognitive burden. Almost every contribution will technically be from an unknown source for a long time, until, if you're lucky, some drive-by contributors turn regular.
I think that’s the perfect choice of distinguishing phrases.
KDE is very customizable (perhaps too much for more casual users) while Gnome is hackable with the extension system - but it will always feel a little more tacked on, be a little less stable, prone to upgrade breakage, etc.
As a corollary to OPs argument, there’s also a reason Niri and Cosmos didn’t stay Gnome extensions.
(But at the end of the day, if the Gnome experience niche works for you, more power to you.)
You'll have to point me even closer because none of the comments I have seen on that post state what happened is different than what I described above?
I can see a comment stating the switch is justified in their eyes, but it doesn't negate that it is a bait-and-switch model.
As far as I can see OP took the original article headline verbatim; the article itself does describe the exact kind of bait-and-switch model as I've heard it used: company offers open standard edition, after a while switches it to basic / 'core' offering which locks e.g. Linux access behind a (steep) paywall.
SearX really works best if you run your own node, not using one of the public ones. I run one on a tiny vps and it’s never blocked by any of the engines.
Caveat: you do give up some of the privacy advantages by being the only user. Thus, I invited my friends and family to also use it and it still works perfectly well. (ofc maybe just none of them actually use it and they’re just being polite about it)
While the above is a little more focused on front-end/web projects I think one thing to keep in mind generally is also to meet the user where they are, or rather where they expect.
E.g. if you create a tool/plugin for vim, users will be thankful for having a vimdoc for reference. If you create a command line tool, a man page will be helpful for quick lookups.
I know that many projects today (especially when first getting set up) focus on a presentable readme but in many cases there are tools to automatically adapt this markdown text to the generally preferred documentation style and location.
Don't have to focus on perfection first but just having a pipeline set up which can then be iterated on over time.
For a more advanced approach I think you can get a lot out of understanding the principles of the Diataxis framework - but this is also larger up-front effort.
But then just don’t use google authenticator and instead one of the FOSS alternatives? Aegis comes to mind.
Like the original reply to your situation said, you do you - but this seems a weird threat model to me, extra-step point notwithstanding.
Sure, but on the other hand the Babylon bee is a bit of a right-wing shitrag. So it's also important to play to your audience and consistently reinforce the fundamental nature of arbitrary gender stereotypes.
While I do think the underlying pushes to per-wafer density will no doubt lead to cheaper memory prices per capacity, unfortunately I believe the vast majority of the over production in the near term won’t be useful for the consumer market since it’s all going into HBM right now and not modular sticks like the typical DDR SDRAMs.
Those ones are specifically designed to be able to fit onto bike lanes, no?
Not sure I understand - if you only have 3-4 packages you can just search for them specifically in the long list?
Even if you have 50 or 100s of packages, bash makes it pretty doable
Should spit out only the packages appearing in both lists (done by memory so may not be 100%)
Besides the obvious problem of racialised body proportion comparisons (and more so: genitalia focused ones introduced as ‘Chinese pee-pee’ and ‘African tribal DICK’) - the term itself also remains one reliant on reductive exoticism that’s highly othering. Finding humour in stereotypes doesn’t negate harm.
Want to highlight a specific geography? Use the region. Want to highlight a specific population or ethnic group? Use that. Want to talk about your scientific racism and at least sound believable? - at least just use ‘sub-Saharan Africa’ so not everyone spots that you’re a nut instantly.
Love this insightful answer to what I originally thought was a pretty ‘duh’ question - very nice analysis!
…why?
And just to be very explicit why this is an issue: each time the package is upgraded through an automated update, the PKGBUILD may change (e.g. to adapt to different dependencies, file structure, etc introduced with new app version).
That also means an AUR maintainer can smuggle in malware with any of those updates, even if you checked the original PKGBUiLD when you installed. And, anyone can request taking over maintenance for unmaintained packages, so it can even happen if the original maintainer was benevolent.
Always check PKGBUILD files on upgrade, even if just a glance. If I remember correctly yay had a function to always show you PKGBUILD diffs before updates, not sure if that was automatically enabled.
Was it already with the same text/emoji combo?
Cause that particular tears of joy emoji only became standardized in Unicode 6.0, 2010. It was presumably around a bit before that but nobody except the Japanese really did a lot of emoji stuff much before that (iirc Google and Apple only started adding the first emoji to their keyboards 2007-08).
Either way would find it very interesting if somebody was already using the emoji way before that, or the text area of the picture went through multiple iterations.
I think that's partly the point of this exercise - if they find a meow they now know this is an untrusted source.
Because it's pretty easy to say 'ignore untrusted sources' but when you're maintaining an open source repo (especially if it's still pretty small/new) this detection is part of the cognitive burden. Almost every contribution will technically be from an unknown source for a long time, until, if you're lucky, some drive-by contributors turn regular.
I think that’s the perfect choice of distinguishing phrases.
KDE is very customizable (perhaps too much for more casual users) while Gnome is hackable with the extension system - but it will always feel a little more tacked on, be a little less stable, prone to upgrade breakage, etc.
As a corollary to OPs argument, there’s also a reason Niri and Cosmos didn’t stay Gnome extensions.
(But at the end of the day, if the Gnome experience niche works for you, more power to you.)
You'll have to point me even closer because none of the comments I have seen on that post state what happened is different than what I described above?
I can see a comment stating the switch is justified in their eyes, but it doesn't negate that it is a bait-and-switch model.
Can you explain?
As far as I can see OP took the original article headline verbatim; the article itself does describe the exact kind of bait-and-switch model as I've heard it used: company offers open standard edition, after a while switches it to basic / 'core' offering which locks e.g. Linux access behind a (steep) paywall.
SearX really works best if you run your own node, not using one of the public ones. I run one on a tiny vps and it’s never blocked by any of the engines.
Caveat: you do give up some of the privacy advantages by being the only user. Thus, I invited my friends and family to also use it and it still works perfectly well. (ofc maybe just none of them actually use it and they’re just being polite about it)
One method of escape: Sponsorblock
While the above is a little more focused on front-end/web projects I think one thing to keep in mind generally is also to meet the user where they are, or rather where they expect. E.g. if you create a tool/plugin for vim, users will be thankful for having a vimdoc for reference. If you create a command line tool, a man page will be helpful for quick lookups.
I know that many projects today (especially when first getting set up) focus on a presentable readme but in many cases there are tools to automatically adapt this markdown text to the generally preferred documentation style and location.
Don't have to focus on perfection first but just having a pipeline set up which can then be iterated on over time.
For a more advanced approach I think you can get a lot out of understanding the principles of the Diataxis framework - but this is also larger up-front effort.
Thanks, that’s good info and makes a lot of sense.