blacklight

As an engineer and self-hosting and self-coding enthusiast, I would agree with a lot of the points. I have spent most of my life in IT advocating for decentralization and democratization.

However, as someone who has had enough experience in the real world to notice how different time and skill constraints lead to different requirements for outsourcing, I think that it sounds elitist. Even an LLM is not sufficient for people who don't even know the difference between backend and frontend or what an API is, and therefore don't stand a chance to craft a proper prompt, let alone properly test the code that the LLM produces.

For context, I could also tell Mr. "Having a fucking website" that they're a hypocrite because they run a blog on Wordpress and have a social media account on mastodon.social. Those who really believe in decentralization run their own stuff, or code their own blogging platform like I did. They don't just brag of how morally superior they are just because they deleted their Facebook and Instagram accounts.

Of course I would sound elitist. And that's exactly how their stance sounds to the average bakery shop owner.

Madblog allows you to run a federated blog from an Obsidian vault, a git clone or your Nextcloud Notes.

Now that support for author replies and reactions has been added, you can also reply or like posts and articles through simple text files:

``` # This is a like

[//]: (like-of: https://mastodon.social/@user/1234 ```

You know that you are dealing with a fascist scumbag the moment you hear "terrorist", "antifa" and "law and order" in the same phrase. Flock is a disgrace for the industry, and this fascist sociopath is a disgrace for mankind.

I don't get it.

If you hate Windows just use Linux, BSD or whatever.

I'm sick of all the "Windows 11 sucks" folks that yet keep using Windows.

Just boot your laptop from a Linux ISO and you've got the best way to bypass Windows 11.

Boycott Microsoft and everything it touches.

Or just use the Surfingkeys extension - it has a bit of a steep learning curve to customize it, but it's worth every piece of effort.

My advice is to build such solutions around open products like Signal, XMPP or Matrix if possible. Or even Telegram.

On top of providing a better developer experience compared to Meta's ultra-locked and limited APIs, they aren't subject to the whims of a giant faceless company that can kill your product for no apparent reason with no chances of appeal.

Especially if you're doing these projects for folks in the developing world. Let's not lock them in proprietary American spyware like the whole West has already done :) from a user's perspective, if things are done properly, it'll just be a matter of installing another app.

And btw using a Matrix server with a WhatsApp bridge could also be a temporary solution to bypass the ban. But I haven't tested it with business accounts.

As the developer of a GPS tracking app that relies a lot on OpenStreetMap, I've faced many of these problems myself. A couple of learned lessons/insights:

- I avoid relying on any generic location name/description provided by these APIs. Always prefer structured data whenever possible, and build the locality name from those components (bonus points if you let the user specify a custom format).

- Identifying those components itself is tricky. As the author mentioned, there are countries that have states, others that have regions, other that have counties, or districts, or any combination of those. And there are cities that have suburbs, neighbourhoods, municipalities, or any combination. Oh, and let's not even get started with address names - house numbers? extensions? localization variants - e.g. even the same API may sometimes return "Marrakesh" and sometimes "Marrakech"? and how about places like India where nearby amenities are commonly used instead of house numbers? I'm not aware of any public APIs out there that provide these "expected" taxonomies, preferably from lat/long input, but I'd love to be proven wrong. In the absence of that, I would suggest that is better to avoid double-guessing - unless your software is only intended to run in a specific country, or in a limited number of countries and you can afford to hardcode those rules. It's probably a good option to provide a sensible default, and then let the user override it. Oh, and good catch about abbreviations - I'd say to avoid them unless the user explicitly enables them, if you want to avoid the "does everybody know that IL is Illinois?" problem. Just use "Illinois" instead, at least by default.

- Localization of addresses is a tricky problem only on the surface. My proposed approach is that, again, the user is king. Provide English by default (unless you want to launch your software in a specific country), and let the user override the localization. I feel like the Nominatim's API approach is probably the cleanest: honor the `Accept-Language` HTTP header if available, and if not available, fallback to English. And then just expose that a setting to the user.

- Bounding boxes/polygons can help a lot with solving the proximity/perimeter issue. But they aren't always present/sufficiently accurate in OSM data. And their proper usage usually requires the client's code to run some non-trivial lat/long geometry processing code, even to answer trivial questions such as "is this point inside of this enclosed amenity?" Oh, and let's not even get started with the "what's the exact lat/long of this address?" problem. Is it the entrance of the park? The middle of it? I remember that when I worked with the Bing in the API in the past they provided more granular information at the level of rooftop location, entrance location etc.

- Providing localization information for public benches isn't what I'd call an orthodox use-case for geo software, so I'm not entirely sure of how to solve the "why doesn't everything have an address?" problem :)

The irony of watching this 2017 TED video in 2025, and find out that my NoScript extension reports half a dozen of JS trackers and ads providers on this page - including Google, doubleclick.net, sail-personalize and sail-track.

Oh, and if you navigate to this page without NoScript, AdBlocker or a PiHole DNS you'll probably be presented with a cookie consent banner, a bunch of ads on the page and before watching the video, and your data being shared with at least half a dozen partners (a number that can increase dramatically if you visit the page of any news outlet instead of ted.com).

So yeah, I guess that the message of this video aged like fine wine.

Of course, I'm not saying that one size fits all.

There are cases like media apps, camera apps, videogames, terminal emulators, clipboard managers etc. that won't become Web apps any time soon.

Either because they need to operate closer to the OS, or for performance expectation reasons.

But I've just had a quick scroll through the apps on my phone, and I can confidently say that 90% of them are basically HTTP clients that interact with an HTTP server.

And even those that do more could probably be wrapped into a WebAssembly artifact with comparable performance in a near future.

The reason why they are not PWAs, and why engineers are often expected to do triple work (iOS, Android, Web), and why there aren't more products released as PWAs, keeps eluding me.

Sure, you have to tell folks how the "Install/Add to home screen" process works from a mobile browser, but is it that really that much more friction compared to an App Store paradigm to justify the abuse of native apps that either reinvent the wheel multiple times, or are just unglorified Web browsers running an Electron app just to show you the discounts at the supermarket near your house?

All the features you mentioned can also be achieved by a well developed PWA. Of course, minus the widgets or some deeper system integration (like controlling phone calls etc.)

It doesn't sound like anything that a PWA (paired with some a sync mechanism like Websockets) can't solve. And with WebAssembly the convergence is even more compelling.

I'd assume that self-hosting is not an option for this user?

Otherwise the alternatives would be pretty much a nobrainer for me:

Microsoft Office 365 -> Nextcloud Bitwarden -> self-hosted Bitwarden/Vaultwarden GitHub -> Sourcehut/Codeberg/Gitea/Forgejo Google search -> Searxng Reddit -> Lemmy Hackernews -> Lobsters Twitter/LinkedIn -> Mastodon / any Fediverse software

This got me genuinely interested - until I cloned the project and saw the docker-compose file.

Minio + Celery + 4-5 services just for the main app + Keycloak?

I'm sorry, but this isn't something that "anyone can run".

This is something that requires a beefy server and someone who can manage microservice architectures with 10+ services.

I'm not sure why all of those services are requirements for the app.

I don't know why you need an S3 provider and a federated identity manager to run something that looks like Notion.

I don't know why you need to split the app into 5 microservices.

And I honestly don't think that all of this overhead is needed.

I'll give Docs another look if it decides to trim some of this bloatware.

It depends on how much Firefox enshittifies. If it's just about removing some telemetry configuration from upstream, then a couple of downstream patches will still do the job. If, say, Firefox decides to fully embrace the spyware business model and drop support for Manifest V2 in order to kill adblockers, then LibreWolf will probably have to maintain their own fat piece of logic built on top of Firefox. Keeping it as a soft fork would then be a lot of work (you'd basically have a patchset of tens of thousands LoC to keep porting through different versions of Firefox). And making it a hard fork would be even more work (it basically means that the LibreWolf folks are on their own and they have to maintain their own independent browser).

The thing is that, in a platform based on link sharing, it should be known which domains point to URL shorteners.

Even if you automate their handling, the algorithm should know that, if it bumps into a say signal.me, bit.ly or goo.gl URL, it should first do a GET and then apply the algorithm to whatever is provided in the Location header.

Not doing this for a widely used URL shortener like signal.me is just a show of technical incompetence.

I did my Github -> self-hosted Gitlab -> Gitea -> Forgejo journey over the years, and I haven't looked back.

Forgejo is great and it's probably going to become even greater once federation is done (having distributed forks and PRs across multiple instances solves the fragmentation problem of self-hosted solutions).

And I lost my trust in Gitea once it spun off a for-profit branch backed by VC money (which was exactly the reason why it was forked into Forgejo).

The only thing I lost from Gitlab is the out-of-the-box CI/CD platform. But I could migrate my pipelines to Drone CI and trigger them via webhooks. Just keep in mind that, depending on the complexity of your Gitlab pipelines, this may not always be an option. Anyway, for me hosting a Gitlab server that hogged up 5GB of RAM to serve a couple of small projects was a big no-no. Forgejo takes 500MB of RAM at peak.

I wish this was the case, I doubt it'll be the case. Suppose for example that the foundation agrees that Manifest V3 is a bad idea (and, objectively, it is an awful idea). I can't imagine a world where the contributors from Google (which currently still make up the vast majority of the commits to the Chromium codebase) go back on their steps and re-implement support for V2, which would basically go against the profitability strategy of their own employer.

Same for intentionally crippling Google websites on non-Chromium browsers: given how deliberate such acts of crippling are, I have reasons to believe that it's part of Google's "works with Chrome" strategy, and I'd doubt that Google employees can do much against it.

The only way to fix the governance of Chromium is to effectively chop all the threads that connect it to Google. As long as Chromium developers who are employed at Google won't do anything that goes against the strategy of their employer, you can't have fair governance.

If you still use Outlook for ANYTHING then it's self-inflicted and well deserved.

Just install a PiHole in your home network.

I've got a Samsung smart TV I purchased a couple of years ago. I've never seen a single ad on it (the drawback is that the TV's app store doesn't work either as it belongs to a domain also used for ads).

When I tried to disable the PiHole for a couple of minutes, I couldn't recognize my TV anymore. Ads in the menu, ads popping up in the corners of the TV, ads everywhere.

It's no coincidence I guess that my smart TV is the main offender when it comes to requests to blocked domains on my PiHole.

Just get a PiHole, and, unless the TV manufacturer refuses to pick the DNS server used in your network, or they've found ways to inject ads without hosting them on blocked domains, you won't get a single second of harassment.

Platypush isn't a stand-alone app, but it provides a PWA for mobile - if that's what you mean. My main goal was to make block editing available through a Web-based interface.

Extensibility is a good point, and one that at some point I could implement. So far the block paradigm I've implemented only covers the primitive statements supported by Platypush' procedures (action, set, if, else, for, while, break, continue, return). But extensibility can definitely be a big win here - although extensibility means that the semantic of the new statement/block needs to be encoded both on the backend and the frontend (the frontend for example needs to know that I can't create a block after a return, or that break is only allowed within a loop).

Could you elaborate your statement a bit?

The release 1.3.0 of Platypush adds a visual editor for automation snippets that takes inspiration from Tasker and IFTTT.

I did some small jobs nearly two decades ago introducing school kids to programming through Scratch and the Lego Mindstorm IDE, and I've been toying since then with the idea of implementing a drag-and-drop, block-based and general-purpose UI to lower the barriers to coding. This has been a chance to finally follow-up on those intentions.

Platypush also still provides extensibility through Python scripts for more complex routines that can't be easily modelled through a block-based interface.

Keep in mind though that I'm no UX expert (I'm mostly a backend guy who can do some UI, not the other way around), and least of all I'm an expert of block-based interfaces and drag-and-drop, especially when it comes to a11y, so feel free to provide feedback.

Everyone agrees that Google has an unfair monopoly over search engines.

Everyone agrees that such a monopoly has been established by crafting commercial deals that potential competitors couldn't refuse.

But everyone seems to be confused on how to fix the issue without impacting consumers and their habits forged over 25 years of Google's search dominance.

In this new article I discuss how meta-search engines like Searxng that aggregate results from competing (and probably smaller/specialized) engines, open search protocols, a revive of the semantic web and a sprinkle of public funding to fix whatever the market alone can't fix can actually turn a regulatory puzzle into a technological opportunity - and make search better for everyone in the process.

Been there. There was this old fashioned developer in one of the companies I worked for a decade ago who never understood nor embraced version control (we were talking of SVN at the time, not even git). Luckily that wasn't the case for all the others developers in the company. But when it came to the projects he owned, I witnessed several scenes along the lines of "hey, customer X has an issue with your component Y, what version do they have?"

He had a spreadsheet where he kept track of the versions used by every customer. Once identified the version, he would open (no joke) a drawer in his desk and pick the right USB stick with that version on it.

I've always wondered whether this overhead was a worth price to pay for not wanting to learn a couple of SVN commands.

If my understanding of the article right, the counter needs to be updated by the business logic every time the underlying array is updated. This doesn't seem to solve any problems. Indeed, it's just synctatic sugar to wrap up what many developers have been doing for decades anyway. And it doesn't reduce the chances of mistakes in getting the counter and the array out of sync either.

Are there people who still watch videos from that cesspit domain called youtube.com?

Do yourself a favour and use Libretube/NewPipe/Tartube/mpv, or any other youtube-dl/yt-dlp based wrapper.

No trackers, no ads whose aggregate duration is longer than the video itself, no idiotic Google employees who regularly break the UI, no aggressive policies against adblockers or any other extensions that you want to use.

Avoiding youtube.com and making sure that not a single dime goes in Google's pockets for providing such a shitty service is a moral duty. Directly fund video creators through Patreon/PayPal if you want to feel less guilty.

I wrote a similar article a while ago: https://blog.platypush.tech/article/Deliver-articles-to-your...

In my case the purpose was to share saved links to my e-reader and used Markdown as an intermediate format through the mercury.js scraping API, but the possibilities are endless.

I raised many of the author's point about Sourcehut several times. I'm an, enthusiastic FOSS supporter who has always advocated for alternatives to Github. But Sourcehut seems to take the worst out of everything. It strips down all the features, provides a web interface that seems to come out of the 1990s, removes anything that is even vaguely interactive in favour of emails, and it turns reviews and PRs a mess of emails and patch files that is impossible to browse.

Seriously, when we say that Github is bad, it doesn't mean that the solution is to get back to the software development cycles of the early 2000s and throw out of the window all the innovations made in the past two decades.

Sourcehut's extremely elitist and proudly feature-poor approach is only pushing away potential users and contributors, and I don't think it's doing a good favour to the community.

I would advise the author to give Forgejo a try (Gitea has almost become fully enshittified with its business plans and vision, so I wouldn't recommend it to anyone anymore). Everything is very similar to Github, but FOSS and self-hosted, and it takes a tiny fraction to run than the resources required by that shapeless beast called Gitlab.

What infuriates me is that often these "services" could be easily served through a simple web app. Provide a link or a QR code, let folks open the URL wherever they like, and stop bitching. But no, everybody requires a freaking native app now because it's the best way of locking people in and scooping up data even when their browser is closed.

The EU needs to forge a law that forces providers of vital services to ALWAYS, no matter what, provide browser-based options, as well as low tech options for people who don't have access to any device.

Those who only provide a Google/Apple option and refuse the service to anyone who doesn't fit in those sets, while providing a service that could be easily served by a web app, ought to be fined.

Your point can be summarized as "We can't tax the rich, or they'll just go somewhere else". A.k.a. the Stockholm syndrome of extreme capitalist markets - we all know that it's not fair that Jeff Bezos pays zero on his wealth while a hardworking bricklayer has to pay nearly half of his salary, but that's the price to pay to avoid scaring off the ultra rich. Needless to say, this vision of the world is abhorrent, immoral, and disgustingly unfair, and we need to fix it.