Slop is content not written by a human. By definition, there can be no de-slop algorithms. There can only be algorithms that remove certain telltale signs, fraudulently attempting to present non-human-generated content as human-generated.
Here we are in place and time where if you put — character anywhere in your text you will be burned like OP on stake for witchcraft.
For those hunting witches doesn't matter if you put in effort and just did fixing grammar or did some research using LLM but in general thoughts and experience were yours. Maybe you are not that good at writing — yet still they will just take pitchforks and torches and drag you out, call you names.
I'll make a period tracker for you for 5 bucks a month. You won't buy it, because it costs 5 bucks a month. So I'll have to find alternative monetisation strategies.
Why would me giving you 5 bucks a month assure you didn't also sell all of the data from the period tracker app? That's money you'd just be leaving on the table.
Motorola needs to hurry up and release their GrapheneOS devices, I need a new phone soon(TM) (next year or two) and I refuse to give google money to buy hardware to avoid Google.
An error? It's useful to know if/when an app wants to access the Internet. So if an app says it's local only you can disable network permissions. Trust but verify.
geo-positioning, maps, way-finding, directions, time of day, calendar, lunar cycle, calculator, notes, language translation, calculator, games, contacts, etc.
I'd bet my money on no. To my understanding, those hallucinations are basically brain-level disturbances in perception, where the brain does its best to fill in ambiguous activity with known objects. So I guess if you've never seen hats (or men), your brain would just interpret the signal as something different.
Extreme tangent but interesting (to me): people in different cultures experience voice hallucinations differently. In the west, "hearing voices" is often frightening because the voices are hostile. In other cultures, the voices are friendly!
That's an interesting question, but the answer probably isn't worth the trauma you'd inflict on a child by intentionally raising them to be completely unaware of the existence of hats.
There are situations [1] where you could reliably BGP-hijack the IP prefix of the target domain authoritative nameserver, and obtain your own domain-validated cert for the target (by effectively controlling the zone file contents). And yeah, CAs do have their BGP protections, but still there's at least partial assumption BGP is secure enough to run DNS-based validation for new SSL certs, in our world where DNSSEC is still rare.
[1] https://www.ietf.org/proceedings/104/slides/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-00.pdf (see slide 15; yeah, it's already a bit old, yet still the case from my practice)
That's actually not the problem. The problem is that the conventional funding model for open source does not make sense and nobody has the resources to provide a financial product that actually works, since the projects with a single maintainer are too small of a market to be worth serving for classic financial institutions like banks.
The business model is as follows: Open source maintenance produces recurring costs (developer salary, infrastructure costs, etc) but these costs are fixed and do not scale with the number of users, only with the development effort. This means the ideal financing structure would be a cost plus system where the maintainer gets paid a salary and the customers (businesses) are spreading the cost among each other so that each business ends up paying less than if they had built or maintained the project in-house.
The problem here is that the costs are variable and depend on the number of participants and their individual willingness to spend money and how that effects the viability of the project as a whole. Participating businesses need some sort of guarantee that they won't be stuck with all of the costs and that there are other participants who will chip in. At the same time, once there is a sufficient number of participants, the participating businesses don't want to overpay. They may commit to a monthly worst case bill of $5000, but if the total bill is $10000 and there are 100 participating businesses so that each business could only pay $100, said big spender would want the option to lower their spending down to $100 if possible and let others carry more of the financial burden.
With this sort of arrangement, funding open source software would be rational, since the amount you save by freeloading is insignificant compared to the risk of the project being discontinued due to freeloading.
reply