Disposable vapes waste have big environmental impact. Use regular vapes with e-juice
It upsets me that disposable vapes are not more prohibited. Where I live I often find vapes discarded in parks and other areas where they can be a fire hazard.
There's a ridiculous amount of tech in a disposable vape
361–370 of 673 posts
Re: There's a ridiculous amount of tech in a disposable vape
#362Earlier quoted context omitted.
Everyone was locked out in a building am staying at (40 something stories) for several hours. When I asked the concierge if I can have a look at the system, it turns out they had none. The whole thing communicated with AWS for some subscription SaaS that provided them with a front-end to register/block cards. And every tap anywhere (elevators/doors/locks) in the building communicated back with this system hosted on A…
> Absolute nightmare. Yes, but still probably a million times easier for both the building management and the software vendor to have a SaaS for that, than having to buy hardware to put somewhere in the building (with redundant power, cooling, etc.), and have someone deploy, install, manage, update, etc. all of that.
Its absolutely possible to have both a SaaS based control plane and continue functioning if the internet connection/control plane becomes unavailable for a period. There's presumably hardware on site anyway to forward requests to the servers which are doing access control, it wouldn't be difficult to have that hardware keep a local cache of the current configuration. Done that way you might find you can't make changes to who's authorised while the connection is unavailable, but you can still let people who were already authorised into their rooms.
Re: There's a ridiculous amount of tech in a disposable vape
#363For these devices the microcontroller needs to be super cheap. Microcontrollers like the Puya PY32 Series (e.g., PY32C642, PY32F002/F030) can cost in the $0.02 - $0.05 range for the kind of many-million volumes applicable for disposable vapes. These are 32-bit ARM Cortex M0 MCUs, running at a 24 MHz clock or similar, some with 24 KB of ROM and maybe 3 KB of RAM! To put into context: this is 3x the ROM/RAM of the ZX81…
idea for a hobby project for someone better versed in hw than me - create a computer that can at least run basic with the MCU from the disposable vape.. :)
first one to run doom on a vape would do great numbers on youtube
Re: There's a ridiculous amount of tech in a disposable vape
#364Earlier quoted context omitted.
We are sitting on 5,970,000,000,000,000,000,000,000 kg ball of matter. We have a giant nuclear furnace in the centre of the solar system that's providing us with energy.
Some resources are still scarce. And a lot of those 6E24 kg is iron and nickel we can never get to. Another big fraction is basically molten stone. And we really should stop putting more carbon into the atmosphere. Also, if you go for measures like mass processed, the weight of microchips, pcbs, parts is only a tiny fraction of what has to be processed and build in the supply chain. Agreed that it is smarter to use o…
> Agreed that it is smarter to use oil for plastics then to burn it directly.
My argument is that as long as we are still burning oil and gas, we might as well burn old plastic instead of new oil and gas.
If/when we stop burning oil and gas, then we can think more seriously about recycling plastic.
Re: There's a ridiculous amount of tech in a disposable vape
#365Earlier quoted context omitted.
> with redundant power, cooling, etc The doors the system controls don't have any of this. Hell, the whole building doesn't have any of this. And it definitely doesn't have redundant internet connections to the cloud-based control plane. This is fear-mongering when a passive PC running a container image on boot will suffice plenty. For updates a script that runs on boot and at regular intervals that pulls down the la…
Those devices can be trivially power cycled, and won’t have as many issues with dodgy power. Some PC somewhere with storage is a bigger problem.
> Some PC somewhere with storage is a bigger problem
Both an embedded microcontroller and a PC have storage. The reason you can power-cycle a microcontroller at will is because that storage is read-only and only a specific portion dedicated to state is writable (and the device can be reset if that ever gets corrupted).
Use a buildroot/yocto image on the PC with read-only partitions and a separate state partition that the system can rebuild on boot if it gets corrupted and you'll have something that can be power-cycled with no issues. Network hardware is internally often Linux-based and manages to do fine for exactly this reason.
Re: There's a ridiculous amount of tech in a disposable vape
#366Earlier quoted context omitted.
> with redundant power, cooling, etc The doors the system controls don't have any of this. Hell, the whole building doesn't have any of this. And it definitely doesn't have redundant internet connections to the cloud-based control plane. This is fear-mongering when a passive PC running a container image on boot will suffice plenty. For updates a script that runs on boot and at regular intervals that pulls down the la…
You know what else would suffice plenty? Physical keys and mechanical locks. They worked (and still work) without electricity. The tech is mature and well-understood.
The reason for moving away from physical keys is that key management becomes a nightmare; you can't "revoke" a key without changing all the locks which is an expensive operation and requires distributing new keys to everyone else. Electronic access control solves that.
Re: There's a ridiculous amount of tech in a disposable vape
#367Earlier quoted context omitted.
That's programmer incompetence. Unfortunately pervasive, especially with devices like parking meters, EV chargers, and similar, where the feedback loop (angry customer) is long (angry customers resulting in revenue decrease) or non-existent.
It could be a management problem instead also, while developers are just following instructions sent by management
And nobody with options would settle for the low pay and terrible working conditions, so the quality of the output also reflects that.
Re: There's a ridiculous amount of tech in a disposable vape
#368Re: There's a ridiculous amount of tech in a disposable vape
#369Earlier quoted context omitted.
> Which is why when folks nowadays say "you cannot use XYZ for embedded", given what most embedded systems look like, and what many of us used to code on 8 and 16 bit home computers, I can only assert they have no idea how powerful modern embedded systems have become. Yet, I still need to wait about 1 second (!) after each key press when buying a parking ticket and the machine wants me to enter my license plate numbe…
And the self service kiosks/checkouts at supermarkets. So infuriating! Like I'd have to try to make something that slow myself on purpose! Besides the fact that scanning a barcode seems beyond much of the general population, they do it so sloooow.
Some of these are just dumb terminals with the entire state handled on a server. I've seen a bunch of them freeze at once where no UI would respond (but the interactions were buffered) and then when the network hiccup was over they all unfroze and reflected the input.
Re: There's a ridiculous amount of tech in a disposable vape
#370Earlier quoted context omitted.
And the self service kiosks/checkouts at supermarkets. So infuriating! Like I'd have to try to make something that slow myself on purpose! Besides the fact that scanning a barcode seems beyond much of the general population, they do it so sloooow.
The self service kiosks are intentionally throttled when scanning barcodes, at a guess to prevent people accidentally scanning the previous/wrong item - I once had some problems with one and a staff member flipped it into supervisor mode at which point they were able to scan at the same rate you'd see at a manned checkout.
I think that's handled by the barcode scanner itself, at least on the ones I've used. The scanner will not recognize the same code immediately, but will immediately pick up a different code.
What's slow is that after each scan it needs to check the weight which means it lets the scales settle for one second before accepting another scan.