Slurrrrrrrrrrrrrrrrrrrrrrrrrrrrp
-
Exactly. This implementation makes no sense. Unless the logos are animated, need to change frequently, or supposed to show advertising (I hope not), a backlit plastic label would do the same job just fine. In fact, that has done the same job for decades at this point.
supposed to show advertising
I'm betting on this.
-
supposed to show advertising
I'm betting on this.
wrote last edited by [email protected]**sharp exhale** You're probably right. It's just like the gas pumps. A big soda cup takes a few seconds to fill up, and the system knows that's when you're holding the button down, staring at the tap. All that makes you an advertising target for the duration.
Is there some version of Occam's Razor where "enshitification" is the most likely answer?
-
Kind of discriminatory, what about the right??
That one runs BSD.
-
Dog's right testicles are running Java
So that's why it keeps swelling and needs constant purging of all that pus.
-
I've never seen one of these, but I assume it performs other functions - surely monitoring sensors, probably reporting that data, maybe allowing triggering maintenance functions, etc.
That said, processing and storage is so cheap on this scale that it's probably better (and cheaper) to go with a tried and true, widely supported system, than it is to optimize with custom hardware/firmware.
I assume it performs other functions
Advertising.
-
Idk, if they're plugging in one for each screen it sounds like a lot; there are libraries to do most of this. It wpuld only take me about a month or someone competent a couple days to write this. I kbow there's libraries to display, but i don't know what else this is monitoring/controlling. So that seems safe,
So there's a computer hardware cost that goes from ~5x(4?) Per machine to ~45x4 per machine. That's ~ 2 hours of code per machine difference that this would make, assuming you were paying ~80/hr to write it, which is reasonable.
Even assuming no code was needed for the pi, production takes twice as long as expected, and electricity costs don't matter (which, next to the condenser; they may not) you break even at ~16 machines. 20 if you want to throw in some other random arbitrary cost.
Even if you assune pi 0's, at, what 20/each? You still break even before 100 units.
So it would take less than a hundred machines for smaller chips to pay off. I'd believe an exec didnt (even ask someone else to) do this math, but how long have pi's had multiple video out's?
Idk, if they’re plugging in one for each screen it sounds like a lot; there are libraries to do most of this.
X11 can easily handle multiple screens.
Not sure about the Pi's limitations but COTS SBCs can too. -
I've never seen one of these, but I assume it performs other functions - surely monitoring sensors, probably reporting that data, maybe allowing triggering maintenance functions, etc.
That said, processing and storage is so cheap on this scale that it's probably better (and cheaper) to go with a tried and true, widely supported system, than it is to optimize with custom hardware/firmware.
I've seen a very similar print out when installing/loading Arch for the first time.
-
I think that if you drink a bunch of it fast enough, you’ll definitely blue screen.
Or Scream Blue.
-
Idk, if they’re plugging in one for each screen it sounds like a lot; there are libraries to do most of this.
X11 can easily handle multiple screens.
Not sure about the Pi's limitations but COTS SBCs can too.Can't read the text in the image but i'm informed it's a crash.
Which would mean that machine, or that virtual machine, is not on any of the other screens. Right?
-
You'd think a damn sticker would be good enough
But what about yet another bright light in someone’s face? Do you not want another bright light in someone’s face? Everyone loves bright lights in someone’s face!
-
I've seen a very similar print out when installing/loading Arch for the first time.
I meant the machine itself! The print out is your typical systemd boot, though they're usually covered by a distro splash but it can be disabled.
-
You're forgetting the main driving factor behind being able to personalize a screen vs a plastic label: advertising.
What I describe goes well beyond things with screens.
For example computer mice have a microcontroller inside (and unless it serves a mechanical function, not much more than that) and cars have several, only one of which actual handles a proper screen (it's actually a microprocessor rather than a mere microcontroller).
The simplest microcontrollers have nowhere near enough memory to handle any half-way decent display (some nothing at all, some can just about handle a two-tone 320x200 display over I2C or SPI, some can handle 640x480 16-bit RGB but without animations as they don't have enough memory to actual have a buffer for image composition) and yet they keep getting sold in massive numbers.
Pretty much all digital electronics out there no matter how invisible to users has been replaced by embedded microcontrollers or, in a some use cases, single function controllers (which are basically microcontroller programs converted into integrated circuits).
Embedded computing was a massive revolution in digital electronics.
-
You'd think a damn sticker would be good enough
Human replaceable printed paper labels, manual stick.
-
Is it just me who feels that having one processing unit per display is a waste?
I mean, I get it why they did it (it's way easier to just have one SBC per-display, both on the hardware and the software sides), but if designing such a system I would still try to come up with a single board solution if only because waste gets on my nerves.
I'd argue that a custom board is more wasteful since they are single use. Using a cheapo COTS processor that drives a single display and runs Linux is reusable in the long run.
-
Human replaceable printed paper labels, manual stick.
It could just be a backlit panel that you place a semi-transparent logo in front. Could be magnetic or slid into place. More resources than a sticker but probably far less than a system-on-a-chip running an OS and displaying the same picture on a monitor all day.
-
This implies every drink and its display is handled by its own computer running linux. Potentially mtndew has a different IP than coca cola.
I wonder if there is a refill cartridge with the flavour in it that the OS reads from to always display the right logo. Or maybe a touchscreen that the workers use to change it manually.
-
This post did not contain any content.
This person trying to blue themselves.
-
Can't read the text in the image but i'm informed it's a crash.
Which would mean that machine, or that virtual machine, is not on any of the other screens. Right?
Yeah, it seems as though it's one controlling (virtual) machine per dispenser, so 1:1 to the screens.
-
I'd argue that a custom board is more wasteful since they are single use. Using a cheapo COTS processor that drives a single display and runs Linux is reusable in the long run.
True, such a low number of production units design would really only make sense if you could find an off the shelf solution to drive multiple displays.
If these displays are not supposed to be animated and they're reasonably low resolution (say, 800x600 20bit RGB or less), they could be connected via SPI and pretty much every microcontroller out there has multiple SPI ports, so even a cheap SBC would work for that). However I expect that getting XWindows or Wayland in Linux to work with such displays would be a PITA.
I've only ever got software running under Linux to control a tiny 2-tone display via I2C - on an Orange Pi SBC - and it's totally its own thing which happens to be running under Linux sending low-level commands via the I2C dev and not at all integrated with X-Windows or Wayland. This would also work fine if the comms was via SPI (in fact the code barelly changes since I'm using a library that does most of the low-level work for me).
To just display a static image or a sequence of static images loaded from storage in a bunch of screens low-resolution enough to support SPI (so 800x600 or less) I expect something like that would be fine.
The more I think about it, there more I expect this thing could run on a single $50 SBC as long as the connector exposes at least an SPI device and 8 independent I/O lines (given how SPI works, shared SPI bus is fine with one separate Chip Select line for each screen as long as the SPI device under Linux can run on a mode that lets your code control the CS line itself, and the other 4 I/O lines are for touch detection) assuming touch position is irrelevant.
-
Yeah, it seems as though it's one controlling (virtual) machine per dispenser, so 1:1 to the screens.
Im really not sure it's vm's though. Thats separate displays.
