hey bro so the lights I have are phillips hue and they use a protocol called zigbee which is like a mesh-based local smart home protocol. There's a great piece of software called zigbee2mqtt which will bridge that to MQTT which is a network socket based protocol that any machine with an internet connection can access, and that's how I'm bridging my lights to the network. I have a daemon that bridges my own protocol to MQTT and that's p much how it works. I'd suggest checking out the zigbee2mqtt supported devices page for a list of bulbs. Zigbee bulbs are kind of expensive and recently I reverse engineered the IR remote for those cheap chinese LED products so I'll do a vid on that too :) if you go the zigbee route you need some hardware to act as the 'zigbee coordinator', which can be a raspberry pi with a USB zigbee coordinator dongle. I'm using the SONOFF ZBDongle-E

emu but I own both a PS3 and a physical copy of skate 3 and ofc im using my dualshock 3 to play

Paradigms are separate from people who like to misinject complexity into their formal work

@@kerch00 i disagree. From my experience, their idiologies always results into complexity. Probably because their paradigm is the wrong solution for the problem that needs to be solved.

​@@LorenzVdvParadigms are not really tools as you speak of, they describe the architecture of languages. One doesn't just solely program functional in java even though it's possible. It's this reason why JavaScript is terrible since you are able to, and people do, mix these different types of programming together. Java is good for enterprise since it's Oop and imperative, C is good for kernel work since it's procedural and imperative. Haskell is not good for much but research because it's not imperative.

100% the only sensible comment in here. I think the problem in tech is also that people "like" certain tools or technologies and that becomes the basis for decision making on solving problems. They then advocate for said tools/technology as if it's the end-all-be-all silver bullet solution to everything "because they've always used it, and it works". Just because you 'can' fix a problem a certain way, doesn't mean you 'should'.

​ @kerch00 but like you said, languages allow for multiple paradigms. Paradigms dont make u use a language "as designed", they just hyper focus on certain features from the language and claim you must use these features and using other features are bad practice. The reality is that every feature has it's purpose and every problem has a best fitting solution. You cant use a few solutions to solve every problem. Like Mike acton said: "The problem is the problem" meaning you cant use 1 solution to fix every problem. Problems are unique. And paradigms ignore this fact.

ooh sounds cool. can u say anything about it or under NDA or smth haha

which, depending on ur definition of fun could also be fun...

ye 100% agree, ig those are just the kind of problems im solving atm

oh my lord we are the same person. U might be interested in my endpoint based rpc protocol for embedded sys that hybrids events and rpc hoff.industries/release-mup.html have u done like a spec doc for urs I can check out?

write a basic TCP socket server with some clients, you could implement a 'chat server' to start off with which is pretty simple. You'll have to design a protocol for initialising, sending messages, leaving, etc. which is a lot of fun

hey bro, have been doing this style of vids for a while and had a disclaimer at the start the visuals werent critical and you can just listen instead. if u didnt realise i was actually playing the game in real time while talking, it's fun for me and think it clearly marks a different style of content from the other stuff on my channel. I try my best to make sure that the added visuals in these ones are not mandatory because I have got this feedback before, some people like it and some would prefer to just listen. Thanks for watching and I appreciate the feedback. did u see me jump over the shark at the end tho? that was pretty cool u gotta admit

​@@hoff._worldif it was scripted, that was damn near perfect, shark jump ftw

@stefanalecu9532 these 'chatting' style vids rnt scripted, I have some dot points but its generally me yapping :D I legit forgot I even placed my marker at the shark and was like aight might as well try hahaha

real dude we are eventmaxxed and eventpilled that's sweet, gotta do smth with rabbitmq or kafka at some point myself

that's an awesome project and yeah I can see how you'd want a hybrid approach for that. you could as you say force events over HTTP requests but it might end up being a square peg in a round hole... with it being decentralized I can't think of a better architecture then event based no? were there others you considered also?

@@hoff._world I think it would be really hard to implement something like messaging using something else than events, maybe there is something besides events I'm not aware of, but I haven't considered anything else. Messaging is one of those things where you just need events to make sure things can be received any time and also resent if something goes wrong.

wait til i do a vid on my electric foil surfboard :P

couldn't agree more. Learning about all the different ways to structure applications keeps things fun - right now I'm having a blast using events for everything but in a year or two I imagine it will be pretty boring... same if it was any other paradigm. So then it will be time to learn a new one :)

BTW, the game scene itself has to be a tree(propagating transformations, ray casting and etc.), how do you create relationships between “nodes” in DOD?

nice so ur implementing those paradigms yourself??

Ye, in C++ though, but it comes about soo cool! I’ve got something like ‘co_await socket.read/write(bytes)’ and ‘co_await socket.accept()’ working with epoll. One of the things I really like is that it can work in one thread, without the cost of atomic operations, but with all the niceties of “asynchronous” execution.

​@@UsatiyNyando you have these somewhere public? I'd be interested in the implementation

@@stefanalecu9532 ye, in UsatiyNyan/serious-execution-library repo on GitHub. Primary example is in serious-io-library repository. Multithreaded impl is WIP, though ;)

twitter verified ☑️

legend xx

dababy VIBEZ

That would be pretty good I reckon

it's crossed my mind, unfortunately I'd be exposing myself as a massive fraud who's never written a line in his life. nah kidding, main issue is timezone (im AEST) + busyness, there's no shot I could hold down a schedule but maybe if I announce one like a week in advance could work... no promises but ill think on it!

if it could I would still rather not pull in all that complexity for what I knew would be at max 300 loc

@@hoff._world yea it would probably add more complexity than necessary indeed

@alex.289 it is always interesting tho to see other options put forth, in software engg and infrastructure stuff there's always multiple ways to do the same thing :)

I have never actually written anything in ruby. I hear rails is pretty good, or by network programming do you mean socket based stuff?

@@hoff._world socket based, i once planned a project, basically a fancy firewall and a professor recommended ruby which kinda surprised me because i never thought ruby would be used for this type of projects, later i found out that there are actually more projects for "low level" networking in ruby than i expected

@estebanmurcia8451 interesting, yeah that surprises me too since it's interpreted you'd probably consider it a high level lang. Come to think of it there are also more socket programs and such written in python than I would expect so yeah I can see it

didnt wanna use a VPN because I want this to be always on and having everything go thru my home network all the time would probably be kinda slow re: coming next I think I should stop making promises I can't 100% keep :')

@@hoff._world hahaha no worries about the future videos. Sometimes things become larger and more complicated than expected, sometimes other topics pop up and are easier to do, or we just stop being interested in something. All of these are fine and happen, nothing wrong with that :) Regarding not using a vpn due to all traffic always going through the home network, my understanding was that this was something you could choose to enable, not something that was unavoidable? For example, in a "point-to-site" case, your LAN would have the vpn server running on your top-level router. This is the "site" part, and would allow incoming traffic to be routed to all/some local subnets. On your device, i.e. the "point" part, you would have the vpn client running and this would tunnel all traffic going into it to the vpn server, as your ssh setup does now. You could obviously tunnel all traffic on your device through the vpn, and this could indeed be slow. But the default would be that your local network subnets are visible on your device, likely under some different subnet address and only traffic to this new subnet is tunneled (e.g. your home network is on 192.168.*.* but is visible on your device as 10.0.*.*, you simply access your local network services via this new 10.0.*.* network). I may still be misunderstanding your use case or constraints And this may not be how how all vpns work, some might enforce greater security at the cost of tunneling all traffic, or may not be configurable/flexible enough to allow my above mentioned setup.

@mblenczewski neato u learn smth new every day that does sound like it could be good. to be honest haven't experimented so much with self-hosting a VPN of any capacity - freebsd's wireguard implementation was only recently considered 'production ready' so was planning on messing around with that when I have the time. The way this setup works at the moment is only port based, it just sets up a listener on that port and routes traffic on that through the enc tunnel, everything else goes thru the normal connection. With the method you're describing it would be that you simply interact with them as if they were regular hosts on your LAN except on a different subnet which would also be a completely valid way to solve the problem, thanks for sharing :)

@@hoff._world your current implementation maps to multiple "point-to-point" vpns (one for each sshd host), each exposing their services onto the localhost subnet, I think. To my mind, the upside of ssh tunneling is remapping ports, which you don't get by default with a vpn. And ssh tunneling isnt talked about enough as it is, so it is always good to mention it. Enjoyed the video regardless :)

thanks x

fr fr ohio skibidi cooking porkchops for the sigma crew

😳😳🫡