DEV Community: Niko Sagiadinos

Nine Years of Almost: My Raspberry Pi Love and Hate Journey

Niko Sagiadinos — Mon, 14 Sep 2026 13:11:53 +0000

Intro

My relationship with the Raspberry Pi has been ambiguous for the last nine years. On the one hand, I think it could be the perfect low-cost digital signage player. But the devil is in the details. And he enjoys fooling people's expectations. In 2019, I even wrote a big article for my company advising against a Raspberry Pi for serious digital signage. Seven years later I published a tutorial on how to do exactly that. This is the story of what happened in between.

Since 2017 I have been trying to bring my garlic-player to the Raspberry Pi, and I failed constantly until now.

The Pi3 Story

On the Pi 3, FFmpeg accelerated the codec in hardware via the MMAL API, but there was no acceleration for video output. In particular: The Qt lib made the player platform independent. It also had no zero-copy path for display output. The result was crackling video even at 30% CPU load.

A solution in 2017 was to tinker with Omxplayer. This software decoded completely on the GPU and it worked well for the H.264 codec. A guy named Luca Carlon managed to create a backend which uses parts of FFmpeg and Omxplayer to render videos directly in QML scenes. He named the project POT - PiOmxTextures.

The first problem: in 2017 garlic-player was based on a QWidget interface, while PoT was QML. It was necessary to split my app in a lib and a player component. Then I coded a QML player as a second option next to the QWidget player part. Days of refactoring just for one video codec. Fortunately, QML was required for Android multimedia anyway.

In 2018, I managed to stick everything together and got perfectly smooth HD video playback even on a Raspberry Pi Zero. But then another rock hit. For a reason I never found out, it was no longer possible to open a webview component while using PiOmxTextures in QMultimedia. No error. No log. Just nothing.

Videos now worked great in fullscreen, but HTML5 Widgets and websites failed. Multi-zone layouts also became a problem. That meant two garlic-player features which made it different from other free solutions were killed.

After a few weeks I closed the branch and did not touch it again. The mistake was aiming for perfection. Many companies instead released their Raspberry Pi software and communicated known problems and restrictions. Just to have the marketing line: It runs on a Pi.

I do not like this style, but that does not mean it did not work.

The Pi4 story

In 2019 the new Pi 4 came out, and I wanted one immediately. Since I lived in Greece at that time, I even asked an expat friend from Munich, who was already in the middle of his travel preparations, to buy a device asap and bring it to Corfu.

The Pi 4 again came without eMMC flash, but with a new GPU, a much faster CPU and something almost unique for IoT: two HDMI ports.

The first attempts were promising, as 1080p videos now played without crackling via FFmpeg, but acceleration was available only on the 32-bit OS. The 64-bit Raspbian, which was more interesting for garlic-player, seemed to become an eternal beta, and on top of that without any acceleration. Pick one: modern OS or hardware decoding. Even Luca's solution did not work anymore, as MMAL became deprecated.

One more disappointment on top: 4K videos worked only in fullscreen in VLC player and only for one specific H.265 profile. No support for 4K with the H.264 codec. 4K in a window and in garlic-player resulted in ugly stuttering, because the hardware overlays were efficient but could not be embedded in complex surfaces like Qt widgets. Garlic-player used FFmpeg via QtAv and additional Qt Multimedia as its multimedia backends at that time. I even added a libvlc implementation as a third backend. It crashed in ways I could not reproduce.

I soon became frustrated again. On the one hand I was impressed by playing four videos in parallel in the 64-bit beta, but this was software decoding only. Nothing for a serious digital signage project that has to be rolled out on hundreds of remotely maintained screens. A demo is not a product.

The machine I technically considered a perfect low-cost 4K digital signage player turned out to be a minefield of pitfalls, "almosts" and "buts".

In the following years I focused on Android and built the garlic-launcher, because my partner had more and more project requests based on Android hardware.

The Comeback Years Later

In 2022, I realized for the first time that something had changed significantly. There were some optimization, Wayland, labwc, many small performance enhancements and a V4L2-M2M decoder at least for VLC. I bought a Pi 400, and in 2023 it finally played a surprisingly smooth 4K H.265 video, even in a window. It was not perfect, but it gave me some hope for the next incarnations.

The Pi5 Story

In 2023 Raspberry Pi 5 was released. Although again without eMMC Flash it got at least a battery-buffered real time clock and a PCIe interface. An RTC is crucial for digital signage. After a crash or reboot the player starts with the correct date and time. Playlists now play time-scheduled content correctly even when the player is offline. With the wrong time, TLS certs can fail and the CMS will refuse connections. A two dollar battery fixes all of that.

But again there were some weird technical decisions: higher energy consumption, which required a fan, and a big slap in the face for digital signage applications, namely hardware acceleration for H.265 only. Everything else was deprecated and decoded on the CPU. The Pi 4 still accelerated h264, the Pi 3 even more. Three generations, and the codec support went down. I realized that the Raspberry Pi would never be the perfect solution for huge digital signage networks, so I lowered my expectations.

Then Qt5 QWebView started crashing on Raspberry Pi OS based on Debian 12 (Bookworm). The moment you wanted to display a website or an HTML5 widget: crash. No information and no real bug reports, just a recommendation to use Qt6. As far as I know, nobody knows why to this day. So again I was stuck with problems I could not solve for a serious release.

Qt6 was not an option for me. The migration alone would have been a huge amount of work, and QXmlPatterns was removed in Qt6. The problem is that garlic-player needs XPath 2.0 functions. The only open source C++ library that supports it is XQilla, unmaintained since 2016, badly documented, and dragging in Xerces-C as a second dependency on every platform. Replacing a working XML engine with a dead one plus extra build complexity made no sense. There are other ways to solve this, but not as a side project while chasing a WebView bug.

I tried to offer experimental images based on pi-gen for the Pi 4, but pi-gen is suboptimal and complex, and after a while it started to produce 32-bit binaries instead of the configured 64-bit ones. At that point I was too annoyed to invest a significant amount of time in finding out why.

Finally the surprise

In 2026, 3 years after the last stable of garlic-player, which is another story of silly perfectionism claims, I tried again on Bookworm and Trixie. This time with a self compiled version of the last Qt5 lib (5.1.5.19) and surprisingly everything worked. Everything. On the first try. So I decided to release a 1.0 version of garlic-player and offer an official AppImage for the Raspberry Pi. It seems there were some fixes in Qt WebEngine and in Raspberry Pi OS which makes everything working.

So what changed after all these years?

Garlic-player on Linux ARM now uses libvlc as its multimedia backend instead of FFmpeg and QMultimedia. That was one of the keys. The setup runs on a Pi 4 and a Pi 5 with a plain SD card. 4K and HD video playback runs smoothly on both devices. And the problem which killed my motivation back in 2018 is gone: multizone with video and webviews at the same time simply works now. The libvlc solved the video part, the Qt fixes solved the webview part.
See the result in this Raspberry Pi Digital Signage Setup Tutorial, the final conclusion of a journey full of disappointments that I never really gave up on.

There are known limitations. Libvlc needs X11/xcb, so it only runs in an XWayland context, and there is currently no control daemon for remote restarts or reboots. Both are on the list, but at some point you have to stop nitpicking and ship something that works.

My biggest lesson was to stop waiting for the perfect version of anything. The obsession with perfection kills ideas, motivation and energy. But as I wrote above, that is another story.

The Pros and Cons of Using a Raspberry Pi for Digital Signage

The Pros

Stable production for years and not permanent new hardware every couple of months like many cheap Android media player overflowing the marketplaces
A company behind it with a real open source mindset, constantly supporting and updating drivers and the operating system to current versions
An engaged maker community has created an amazing ecosystem around this device

The Cons

Slow hardware and interfaces
Sometimes poor strategic company decisions
Lack of eMMC flash
Poor video acceleration in FFmpeg
No battery-buffered real time clock until the Pi 5

What does the Nine Year Older Niko recommend now?

In summary, the difference to my old article from 2019 is not that big. Yes for small installations, no for big ones.

Yes, if:

If you are low on budget, you are able to handle Linux and need to manage a modest number of devices over a network, you can use a Raspberry Pi 4, or better a 5, without any hesitation. Go for it. Especially, as long as you can easily get to the location and fix errors.

I would say it is even a much better choice than many Android HDMI sticks or the overhyped Amazon Fire Stick. In many HDMI stick projects I have seen overheating problems or Wi-Fi dropouts. My personal opinion, especially about the Amazon stick: they just label a consumer device as digital signage and advertise it as a technical enhancement. Probably some modern Midas touch. Overall it is a black box without easy control over updates and remote maintenance. A Raspberry Pi at least has transparent driver support and continuous updates, proven for over a decade.

No, if:

For bigger installations, especially with several far away locations, the risk is too high. In the end, the Raspberry Pi is a tinkering system created for prototyping and makers. Of course, it is usable, but for a big network you need rock solid stability. That is not the place for a tinkering device.

You should consider serious and proven hardware manufacturers which do not compete just with price. Every buck you obsessively try to save can cost you a multiple of it later, at least when a support team has to travel to the location for a fix. One service trip eats ten Raspberry Pis.

The Raspberry Pi did not become the perfect digital signage player. I just stopped waiting for it. Finally, after all these years, I still like this little machine.

Marketing Has Become a Harassment Industry

Niko Sagiadinos — Wed, 24 Jun 2026 15:17:10 +0000

TL;DR

Cookie dark patterns. Fake urgency. 7 reminder emails. Impossible unsubscribe flows. Marketing isn't helping anymore. It's harassing at an industrial scale.

I am an open-source programmer in the digital signage industry. I love good marketing. The kind that actually helps. That solves problems. That makes you think, "Damn, I'm glad I found this."

But let's be honest: That's not what most of us experience anymore.

What we get instead is a pestering machine. Websites that manipulate you into accepting trackers. Shops that spam you before your order even ships. Services that make cancellation a psychological warfare exercise.

And the emails? Don't even get me started.

This isn't marketing. This is what happens when you optimize for metrics instead of humans. When you confuse "reach" with "bombardment."

So here's my rant about how modern marketing has turned into professional stalking with better automation.

Websites - Give Me All Your Data

You notice it especially when researching products or writing an article. Do yourself a favor: turn off your ad and tracker blockers. Just once.

Google makes you land on a page, and BAM — a cookie banner.

Not just any banner. A manipulative asshole of a dialog, designed to confuse you. "Accept all" in bright blue, bold, and prominent. "Reject"? Hidden. Gray. Small. Or buried three submenus deep so you'll give up and approve every damn tracker.

You fight your way through. Click through the obstacle course. Finally find what Google promised you at position #1. Start reading and – ZAP – a shitty overlay pops up.
"Subscribe to our Newsletter". Or a dump AI chat wanting to "help" you. Or both at once.

And then after removing you realize: The article is a scam. The headline had more substance than the entire text. SEO garbage, generated to farm clicks, not to help you.

Fly & Travel

Ever notice how on Agoda, Booking & Co., there's always "only a few rooms left"? What's this permanent manipulative bullshit? Do they think we're that stupid?

And Agoda? They've perfected the art of being annoying. You open the app. Not to book, just to look, and immediately: Overlay. "Sign up for 10% off!" You close it. Another overlay: "Enable notifications!" Close. "Download our app!" Close. "Last chance for this deal!"

You haven't even searched yet. You just wanted to check prices.

But no. Agoda won't let you do what you actually want until you've fought through their gauntlet of interruptions. It's not a travel app anymore; it's an obstacle course with a booking button somewhere at the end. Same for airlines, which manipulate you to book useless insurances, seats, SMS notifications etc.

Shopping

You buy t-shirts. Somewhere. It doesn't matter where. My concrete example was Alpenwert.

Before the goods arrive, half a dozen emails arrive. And a letter. To my home. Trying to convince you how clever I was to shop there. With a coupon. That I absolutely must leave a review. That I should buy even more.

After 7 days I asked where the goods were. Response: An AI-generated self-congratulatory email with a hasty apology. PS: "We're proud to be the only ones shipping plastic-free!"

Two days later: two t-shirts. In DHL plastic bags. Each is individually wrapped in plastic.

I unsubscribe. Write to support that I will never buy from them again; they should delete my account and want nothing more to read from them.

A few days later: More mail (snail mail). More email. "Rate your shopping experience!"

This isn't an isolated case. Almost every online shop thinks they need to keep bombing you. Newsletters that look like help but just scream "Shut up and buy!" "We miss you" emails from portals you visited once.

A week later: "Come back, here's 15% off!" Another week: "Your cart is waiting!"

Side Note: Ecological Bank Advertising

I got an advertising letter from my bank with a printing on the envelope. A green tree with the slogan "Banking ecologically sustainable."

What drugs are they on?

The Unsubscribe Hell

Try unsubscribing from Amazon Prime, Canva, or another service.

Never less than 4 or 5 clicks. At every click you're bombarded with messages about what benefits you're losing. "Are you sure?" "Really sure?" "But look at everything you get!"

And if you keep using the service until it expires? One wrong click. Bam – subscriber. Again.

Email Spam: The Curse of Reach

Apparently I've done something right the past few years. Especially those who think I could be a great customer have discovered me.

Offer Email. No response.
Reminder email. No response.
Another reminder email. No response.
Another one.
And another.
The logic: "If I just bother him enough, he'll eventually bite."

Spoiler: No.

But nobody cares. The main thing is the automation runs. The main thing is the "cadence" is optimized. The main thing is some bullshit metric says that after the 7th email, the conversion rate increases by 0.3%.

Mobile Apps

Remember when apps were supposed to make life easier? Yeah, that was cute.
Now you open a free app, and it's just ads. Everywhere. Always.
You want to check the weather? Ad. Want to use a calculator? Ad. Reading an article? Ad between every paragraph. Playing a simple game? Ad after every level. And not just one—forced 30-second video ads you can't skip.

"Close in 5... 4... 3..." And when you finally can close it? The X button is 2 pixels wide, deliberately placed where you'll accidentally tap the ad instead. Oops, opening App Store. Again.

But wait, there's more! "Watch this ad for a bonus!" You watch. Another popup: "Double your reward for another ad?"

You watch. "Triple it?" At this point you've watched more ads than actual content.
And the notifications?

You're not using the app. The app is using you. You're the product, watching ads, generating data, clicking "Allow notifications" because the app won't work otherwise.

And the free trial trap? "Start your free trial!" You close it. Open the app again: "Start your free trial!" Every. Single. Time. Until you either pay or delete the app out of pure rage.

This isn't software. This is a hostage situation with a download button.

Social Media

Remember when social media was about connecting with people? Now it's an engagement farm that's perfected the art of manipulating you back into the app.

"People are looking at your profile!" No they're not. It's automated bait. Click through and it's some recruiter from nowhere, or worse. LinkedIn's own algorithm pretending someone viewed you just to boost their metrics. "You appeared in 47 searches this week!" Cool. Who? "Upgrade to Premium to find out!"

Facebook & Instagram

Your feed is 80% ads and "suggested content." You look at ONE piece of furniture, and suddenly it's couches for weeks. Want to post a photo? "Boost this post!" Translation: Pay us, or your actual followers won't see it.

Instagram Stories? Now 50% ads timed perfectly to look like your friend's content until — surprise, surprise — it's crypto trading or weight loss tea.

All of them

"Enable notifications so you never miss an update!" Translation: Let us interrupt your life 47 times a day with irrelevant garbage designed to trigger your FOMO.

You're not using social media. Social media is farming you for engagement, data, and ad impressions. And they've gotten so good at it, you don't even notice anymore.

Is drinking paint thinner a job requirement in marketing?

Seriously. I now keep a list of companies I will never buy from again. Because they bothered me. Because they couldn't stop. Because they thought reach means constant bombardment.

But that's not really the point. The point is, they have all forgotten what marketing actually means.

It's not about assaulting people until they give up. It's about making them happy to hear from you.

When was the last time a marketing email made you happy?

What Can We Do About It?

Here's the thing: We're not powerless.

Every time you hit unsubscribe, every time you choose a company that doesn't pester you, every time you close an app that's more ads than content, you are voting with your attention. And attention is the only currency these companies actually care about.

Practical steps:

Use ad blockers and tracker blockers. Unapologetically.
Unsubscribe aggressively. Make them work for every email.
Leave honest reviews mentioning spam and dark patterns.
Choose companies that respect your time. They exist.

And yeah, about that blacklist idea:
I'm seriously considering building it. A public web app where people can report companies that cross the line from marketing to spamming. With examples. With rankings. A crowd-sourced "wall of shame" for the worst offenders.

Maybe the only way to make this stop is to make the harassment visible. Public. Documented.

But I want to hear from you:

What's your worst marketing assault story? Which companies have you blacklisted? What features would make such an app actually useful? Should it be a wall of shame, a rating system, or something else entirely?

Drop your ideas in the comments.

Because marketing isn't dead. But it needs to remember what it's supposed to be: helpful, respectful, and something people are actually glad to receive.

Until then? Keep that unsubscribe finger ready.

Originally published at sagiadinos.com

SaaS or Self-Hosting? What I Would Actually Use?

Niko Sagiadinos — Wed, 22 Apr 2026 16:30:06 +0000

Since 2011 I've been developing digital signage software, today mostly open source, and I co-own a company that sells both: SaaS licenses and self-hosting support. No hidden agenda here, just 15+ years of watching what actually happens when businesses choose one over the other.

When SaaS makes sense

If you're running a handful of screens for a short-term campaign, or you just need something up and running today without touching a server, SaaS is the honest answer. Low upfront cost, automatic updates, nothing to maintain.

No IT department needed, no server to babysit. For small setups with no sensitive data and no long-term commitment, it's perfectly fine. It's also a legitimate way to test a business idea before committing to infrastructure. A low barrier to entry is a real advantage when you're still figuring out if something works.

The same applies to identity management. Hooking into an existing SSO or using a provider like Azure AD or Okta means your team can log in from day one without setting up anything. Practical, fast, no friction. Until it isn't anymore.

Where it gets uncomfortable

The subscription that felt cheap in year one looks different in year three. But that's not even my main concern. What I see more often: vendors get acquired, prices double, roadmaps shift, and suddenly your screens depend on decisions made in a boardroom you have no access to. Your data sits on infrastructure you don't control, often in jurisdictions with different privacy laws than yours. And when the provider has an outage, you wait. That's it. You just wait.

This isn't a digital signage problem. It's an SaaS and also cloud problem. Broadcom acquired VMware and overnight turned reasonable licensing into something many companies simply couldn't afford anymore. Microsoft can lock your entire organization out of Teams and Exchange the moment a license lapses, payment fails, or a political decision is made.

Twitter killed its API and took dozens of businesses that had built on it down with it. Google has a graveyard of discontinued products that people and companies relied on. Heroku killed its free tier and thousands of small projects went dark the same day. The pattern is always the same: it works great until someone else makes a decision.

In digital signage the consequences are just more visible. Your screens go black. In a hotel lobby, a hospital corridor, a retail store. No workaround, no fallback. You wait for someone else to fix their problem.

Self-Hosting

Self-hosting means you run the software on your own infrastructure. Your server, your data, your rules. No one can double your prices, kill the product, or lock you out. You decide when to update, whether to update, and what to do with your own data.
That's already a fundamentally different position to be in.

With FOSS it goes further

Open source adds another layer. The code is auditable, you're not trusting a black box. If I stop developing GarlicSignage tomorrow because I choose to continue my life as a buddhistic monk, the code stays. Someone can fork it, maintain it, build on it. The community doesn't depend on my business decisions. That's not a feature, that's a guarantee.

For regulated environments like healthcare or the public sector, auditability isn't a nice-to-have. It's often a requirement. You can't put a closed-source black box on a hospital network and call it compliant.

The honest part about self-hosting

Self-hosting isn't free in the sense of effortless. Someone has to set it up, keep it running, and deal with it when something breaks. That's a real cost, just not one that shows up on an invoice.

For a small business with no technical background, "just spin up a server" is not helpful advice. You need someone who knows what they're doing. That might be an employee, a freelancer, or a managed hosting provider. Either way, it's a dependency of a different kind, one you at least have some control over.

Updates don't happen automatically. That's a feature if you value stability and hate surprises, and a liability if you ignore them for two years and suddenly have a security problem. Self-hosting rewards people who take it seriously and punishes those who don't.

Backups are your responsibility. Monitoring is your responsibility. If your server goes down at 3am, no one is going to fix it unless you or someone you hired does. There's no support ticket that makes it someone else's problem.

And then there's the setup itself. Depending on what you're running, it can be straightforward or a rabbit hole. A well-documented open source project with an active community makes a massive difference here. A poorly maintained one with no docs is a different story entirely.

None of this is a reason to avoid self-hosting. But going in with romantic ideas about full control without understanding what that control costs you in time and attention is how people end up abandoning it halfway through and blaming the software.

The question isn't whether you can self-host. It's whether you're willing to own it.

What it Actually Comes Down to

This was never a price discussion. SaaS costs less to start and more to leave. Self-hosting costs more upfront in time and attention and pays off the longer you run it.

But the real question is how much control you're willing to hand over, and to whom. I offer both models because both have their place. But if you ask me what I'd run my own infrastructure on: something I can see, touch, and own. Not because I'm ideological about it, but because I've watched too many businesses rebuild from scratch after someone else made a decision for them.

My skepticism about depending on other people's software decisions goes back further than that. In 1992 I was an enthusiastic OS/2 user. Technically superior to Windows, great object-orientated GUI concept, backed by IBM, and then slowly strangled. Partly because it wasn't profitable enough, partly because Microsoft made sure it wouldn't be. Everyone who had built on it had to start over. That stuck with me.

Originally published on sagiadinos.com

Open Source Digital Signage: What the License Doesn't Tell You

Niko Sagiadinos — Thu, 19 Mar 2026 17:51:50 +0000

"Open Source" sounds like control. In practice it often means: free to get in, stuck later.

The license tells you nothing about whether you can actually run the system yourself, whether your screens keep running when the server goes down, or whether your content is stored in open formats or locked into a proprietary schema. That's decided by the architecture.

What Actually Matters

Four things separate genuinely independent systems from vendor-dependent ones:

Self-hosting: Does it run on your own infrastructure, or does it require external servers you don't control?
Player/CMS separation: If the server goes down, do your screens go dark? A decoupled architecture means players continue their last schedule independently.
Open standards: Proprietary playlist formats lock your content to one vendor. SMIL is the open W3C alternative.
Deployment model: Docker or bare-metal vs. vendor-specific runtimes.

A system that ticks all four stays portable long-term. One that doesn't will eventually hold you hostage.

Six Platforms Compared

I evaluated GarlicSignage, Screenly Anthias, Concerto, Xibo, DigitalSignage.com, and signageOS against these criteria.

Software	Open Source	Self-hosted	Vendor Dependency
GarlicSignage	✔	✔	None
Screenly Anthias	✔	Partial	Low
Concerto	✔	✔	Low
Xibo	✔ (core)	✔	Medium
DigitalSignage.com	Partial	Limited	High
signageOS	Partial	✖	High

The short version:

Screenly Anthias is genuinely open source, but designed for single screens. No central CMS.
Concerto is best for campuses or organizations where multiple departments manage their own content with a moderation workflow.
Xibo has the broadest feature set and an active community, but production setups will likely touch paid components.
DigitalSignage.com uses open source messaging as an acquisition funnel. Core functionality runs on their cloud.
signageOS is enterprise device abstraction across 41+ hardware vendors. Not for self-hosted use.
GarlicSignage is SMIL-based, fully self-hosted, Player and CMS are strictly separated. Setup requires technical knowledge.

The Uncomfortable Pattern

Several platforms in this space publish parts of their code as open source while keeping device management, hosting, or core features tied to their own services. Open license, closed system.

That model is commercially legitimate. But if you're planning to run 50 or 200 screens on a platform, you should know whether you own the infrastructure or you're renting it before you build on it.

Disclaimer

I'm the developer of GarlicSignage. I've tried to evaluate the other platforms as fairly as possible, but take that context into account.

The full architectural comparison, including details on Player/CMS decoupling and SMIL support, is in the original article.

Stop Calling LLMs AI

Niko Sagiadinos — Wed, 05 Nov 2025 08:34:43 +0000

TL;DR

This article explains why LLMs are useful tools, but calling them "AI" is dumb marketing bullshit that leads to bad decisions, wasted money, and unrealistic expectations.

Hypes are Everywhere

When I scroll through LinkedIn, Reddit, or various blogs, I always read the same annoying phrases about our future: AI will soon replace nearly every engineer, will change the world, or, depending on who's talking, enslave us.

It's Just Marketing, Stupid

AI is just a marketing slogan. Because this is what marketing does. It shouts loud and sells smoke and mirrors.

What we call AI technically is only a simulation of "intelligence."

Take Large Language Models, for example. Not magic, not conscious, not smart.

Large: the immense amount of data it has been trained on.
Language: the primary function is to process and generate human language.
Model: it is a statistical model, a computational framework, not a living entity.

Same Story with Image Generators

I know it is getting boring, but nothing has changed and nothing will change: the so-called AI trained on the world's knowledge and draws people with three or four fingers.

I still get this in 2025 with different tools like Dall-E, Gemini, Stable Diffusion, Flux etc. Especially if you need content that is more complex than a simple portrait of a cute smiling person.

Different tech, same limitation: they're pattern-matching machines, not intelligent creators.

Intelligence is a Loaded Term

"Intelligence" in humans is multifaceted, encompassing reasoning, problem-solving, creativity, emotional understanding, social skills, and more.

An LLM can perform certain tasks that might be considered "intelligent" (like generating coherent text, answering questions, or even writing code). But this "intelligence" is narrow, specific to the data it's trained on and the algorithms that govern the responses.

Language models lack common sense, intuition, and the ability to truly learn from experience in the same way a human does. Their "understanding" is statistical, not conceptual.

That's why you get hallucinated facts, broken code, and three-fingered portraits. Sure, there might be workarounds, but you can't patch away a fundamental limitation. These aren't bugs. They're features of a system that mimics understanding without actually having any.

Personal Experiences

I have been working with LLMs for years and also use them as support in my current garlic-hub project.

They have advantages in researching, translations, summaries, code explanations, concepting, prototyping, and documentation, but not for writing production code.

Even with precise prompts, you’ll get too often inconsistent, crappy code that breaks the moment you touch it.

Let's try to write unit tests based on your own classes when they consist of more than getters and setters.

Among other oddities, you will find the following:

testing of private methods
mocking of inherited methods
even mocking the testing class
inconsistency in the naming, although prompts are specific

Let's be clear: unit tests are designed to test isolated, manageable pieces of code. If a tool marketed as "intelligent" can't even write tests for a single class reliably, how is it supposed to automate software development or rule the world?

But You Need to Use it Right

If something doesn't work as expected, the typical response is: "You're using it wrong."

The AI evangelists insist you need to change how you program; stop being a programmer, start being a software engineer.

Their vision: create detailed documentation of the modules you need and let the agent do the work, including unit tests.

If something's buggy or needs to change, you update the documentation, let the agent regenerate the code, and review again. They call this "vibe coding," and according to them, it saves tons of time.

Sounds reasonable at first glance? Let's dig into that.

The Time Saving Myth

Of course, starting something new leads to fast results. At first! Eventually, it consumes more and more time.

Why?

Technical debt: AI-generated code is often suboptimal, buggy, difficult to maintain, poorly documented, insecure, or not scalable. It just works is not enough.
Debugging and correction: Debugging, fixing bugs, or adding new features to this code base later on is more labor-intensive than writing clean code manually.
Lack of understanding: The reality is that people might review the first times, but as it seems to work as expected at first, often they blindly adopt code without understanding the implementation decisions. This makes maintenance and changes a high risk.
Redevelopment: If the system needs to grow or scale, vibe code can become so unusable that a complete redevelopment is necessary – negating all the initial time savings.

The immediate productivity gains (rapid prototyping) are essentially a “high-interest loan on the future” of the code base, which will later become due in the form of high maintenance costs.

History is Repeated

The same often happens with using 3rd-Party libs like in Node.js or frameworks. First, they save you time, but creating software is only the start. Maintaining in the long run is the real challenge.

Remember the no-code circus? Similar crappy promises, different label, same dead end.

Perceived Efficiency Study

An interesting METR study shows: Experienced developers only think they are 24% faster with AI, but they're actually about 20% slower

If you ask AI Bros about this, they will yell that these study is based on wrong assumptions, and you need to learn much about how to use vibe coding. Remember this "You Need to Use it Right"?

But marketing talks only about "intelligence". Every AI coding company tells us how easy their tools are to use and advertise "reviews" of people who claim to realize huge projects in a few days without even programming skills.

But at the moment you start measuring a tool according to the promises, and it fails, the excuses come suddenly: You need to dig into endless hours and months of learning.

So what's the conclusion? You should spend months studying to achieve a rather questionable time saving that is more felt than real?

You will never read this from the AI-Bros.
What you also never read is about quality assurance and code maintenance.

The Junior Developer Problem

Another point is often ignored, too. To review code, you need skills, years of experience and maybe some fails.

If "vibe coding" becomes standard, how do junior developers learn their craft? You can't learn to review code you never learned to write. We'd be creating a generation of developers who can prompt but can't program. They'd be like consultants without expertise.

LLM Training Reaches Limits

The so-called revolution from LLM is based on scraping, storing and searching huge amounts of data. What the ignorant world calls AI is just a highly trained auto-complete feature.

But there's only one Stack Overflow, one YouTube, one Wikipedia to scrape. We've already done that, and now we're running out of training material. The Conversation, Business Insider

The widely propagated solution? Use synthetic data, which means: LLMs generated data to train other LLMs. Nvidia is already building a synthetic data generator called Nemotron

Meanwhile, more and more text on the web is LLM-generated, and it's nearly impossible to distinguish machine generated text from human written content.

How hard is it to see where this leads? Training AI on AI-generated content will inevitably cause model collapse and degeneration?

AI Bros do not discuss this and companies chasing investor money keep pushing their "revolution" at all costs.

Self-Driven Hype

Unfortunately, this mix of agitators, marketers, and their uncritical followers has created a relentless hype cycle.

Plenty of mediocre ex-managers and corporate has-beens crave public visibility. Some are paid to push a narrative; others genuinely see themselves as visionaries who deserve an audience.

All of them open their mouths to fill the air with empty, meaningless words. Their followers, in turn, are simply cheerleading. If you express skepticism, the retort is often: "Hey, Bill Gates is a billionaire. He knows what is going on." No, he knew nothing. He's speculating just like thousands of others. But for some reason, people trust vague predictions from wealthy people as if wealth equals expertise.

This creates a self-fulfilling prophecy: shortsighted decision-makers fear missing out if they don't jump on the AI bandwagon. So they start slapping "AI" on everything, whether it makes sense or not.

In the end, the hype just fuels a reckless, resource-guzzling industry that burns cash and electricity.

More Absurdities from My Industry

My home is the digital signage industry and while others face similar nonsense, here it’s downright absurd.
Companies constantly invent pointless "features" just to slap 'AI' somewhere on their landing pages.
Like

Display chatbots: because apparently people want to have conversations with a screen showing ads, instead of just reading the information.
"AI-optimized" ad placement: algorithms that optimize for metrics nobody asked for, ignoring actual campaign goals. The AI decides what's "best," not your business objectives.
Predictive Audience AI: tools that claim to forecast audience behavior and generate impressive projections based on laughably small datasets. Garbage in, "insights" out.
Age/gender estimation: computer vision that's been around for years, now rebranded as "AI-powered." It fails in noisy environments, struggles with viewing angles, and provides data that's rarely actionable anyway.

None of this solves real problems. New software features should be driven by customer pain points, not by marketing departments desperate for buzzwords.

Whenever you see a digital signage company shouting about AI, remember this: it’s not built to help you or your business. It’s built to sell you.

Stop Calling LLMs AI

I'm not worried about a Terminator future. There's no technical singularity coming from this approach.

This industry is now running into problems, because they've already scraped most available data.

Plans to generate synthetic data to train will lead to degeneration.

An LLM is a useful tool, that impressively simulates human behavior. No more, no less. It can perform tasks that might seem intelligent.

But their capabilities are just reflections of data and algorithms and it is not a sign of true consciousness or human-like intelligence.

Here's the reality: LLMs are calculators that learned to talk. Nobody panicked that calculators would replace mathematicians. Stop pretending autocomplete will replace engineers.

SpicyCamCast: Lightweight Camera and Screencast Integration for JavaScript

Niko Sagiadinos — Wed, 29 Jan 2025 12:50:56 +0000

Why I Built SpicyCamCast

While developing a new digital signage application, I needed reliable screencast and webcam recording capabilities. Existing libraries, though capable, often came with unnecessary complexity or were not clear enough. I saw an opportunity to create something more straightforward.

SpicyCamCast emerged from this need – a minimal, purpose-built library that handles media capture with minimal fuss. It's not just another webcam library; it's a practical solution born from real-world digital signage development challenges.

The result is now published on GitHub.

SpicyCamCast is a minimal JavaScript library (under 3KB) that simplifies camera and screencast integration in web applications. Built with modern JavaScript features, it provides an intuitive API for managing video streams and capturing photos.

Key Features

Lightweight: Less than 3KB, keeping your application bundle small
Modern JavaScript: Leverages ES6 classes, private fields, promises, and async/await
Dual Functionality: Handles both camera streams and screen recording
Flexible Photo Capture: Supports multiple formats (JPEG, PNG, WebP)
Device Management: Easy video device detection and selection

Quick Start Guide

Camera Integration


import { SpicyCam } from './src/SpicyCamCast.js';

const videoElement = document.querySelector('video');
const spicyCam = new SpicyCam(videoElement);

// Start camera stream
spicyCam.justStart()
  .then(() => console.log('Camera started'))
  .catch(error => console.error('Error:', error));

// Capture photo
const canvasElement = document.querySelector('canvas');
const photoDataUrl = spicyCam.capturePhotoAsJpeg(canvasElement);

Screen Recording

import { SpicyCast } from './src/SpicyCamCast.js';

const videoElement = document.querySelector('video');
const spicyCast = new SpicyCast(videoElement);

spicyCast.startScreencast()
  .then(() => console.log('Screencast started'))
  .catch(error => console.error('Error:', error));

Capturing Photo

const canvasElement = document.querySelector('canvas');
const photoDataUrl = spicyCam.capturePhotoAsJpeg(canvasElement);
console.log('Captured photo:', photoDataUrl);

SpicyCamCast provides flexible photo capture from active video streams. Capture in multiple formats:

// JPEG capture
const jpegPhoto = spicyCam.capturePhotoAsJpeg(canvasElement);

// PNG capture for lossless quality
const pngPhoto = spicyCam.capturePhotoAsPng(canvasElement);

// WebP for optimal compression
const webpPhoto = spicyCam.capturePhotoAsWebp(canvasElement);

Each method returns a data URL string that can be used directly in elements or uploaded to servers.

Conclusion

SpicyCamCast aims to simplify media capture for web developers. By focusing on essential features and providing a concise API, it offers a lightweight and efficient solution for integrating camera and screencast functionality into your projects.

Whether you're building interactive web applications, creating digital signage experiences, or developing video-centric tools, SpicyCamCast provides a solid foundation for your media capture needs.

I encourage you to explore the full documentation and examples on GitHub - SpicyCamCast.