|
I only got it by googling, our CCC is becoming more and more techie 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
Staring at NGINX stanzas and starting to go cross-eyed; thinking that I'm losing my mind...
Until I build a self-signed cert and realize that all port 80 traffic is being eaten upstream. Thanks a bunch for the heads up, provider.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: Thanks a bunch for the heads up, provider.
Ew. I would be quite upset. I run a couple websites from my home with SSL, and would be really annoyed if port 80 was blocked by the provider for the cert authentication process.
I've heard that providers don't want you running your own server unless you pay for at "business" rates, but I've never seen one block port 80.
I'm assuming you've checked the router?
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Eh, it's government so I don't have much say in that part. It's definitely upsteam, though, and was likely someone's "good ideal" about how to secure our public-facing services.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Getting used to blender and natron, trying to build a video intro for my upcoming demo
(blender video generated by image sequence from Natron)
Test 0 - YouTube[^]
(all-Natron compositor)
test - YouTube[^]
I'll probably change the banner, but I wanted to get used to the compositors in the tools.
I admit it ain't that flashy, but after a week of playing around, I had to stop and actually write some code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 19-Apr-19 7:09am.
|
|
|
|
|
Work Weirdness:
0) In Chrome, the videos render as a white screen.
1) IE and Edghe bother render the video just fine.
At home with Firefox on both Linux and Wuindows, it renders fine.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Your first video was followed by this YouTube suggestion:
"445,000 YEARS Sumerian Expert Renders Scholars Utterly Speechless with Decipherment" 
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
What browser do you use? They don't appear to work in chrome.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 19-Apr-19 9:01am.
|
|
|
|
|
I use Chrome Version 73.0.3683.103 (Official Build) (64-bit), and both videos play just fine.
Software Zen: delete this;
|
|
|
|
|
Using 73.0.3683.75 here. I suppose that's reasonably up to date. It's done this to everyone in the office that tried to view them.
Strangely enough, my snagit screencast video and any video I've taken with cameras all play fine in Chrome. These to videos were created with Natron and Blender, and they play fine everywhere but Chrome (at work).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Chrome 73.0.3683.103 here, and it's working fine, as well as other browsers.
I downloaded the video (youtube-dl) and loaded it with Avidemux - it's not seeing anything out of the ordinary.
Slick logo, BTW.
|
|
|
|
|
I can't take credit for the logo. I'm just using it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I suspect the gubment IT gremlins.
Software Zen: delete this;
|
|
|
|
|
The world is coming to an end, folks... John's gone Hollywood. 
Software Zen: delete this;
|
|
|
|
|
When I'm done with the prototype demo(s), I'm gonna start doing code varticles. I already have some intro stuff ready.
|
|
|
|
|
It looks pretty good. There are a lot of artifacts from heavy compression but I don't know if you can do anything about that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
i guess i could try a different codec/container, but i'm not a video expert, and i don't know what youtube does to videos after you upload them. I uploaded it at 1080p. I think you need to go full screen to see it as intended.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
So a demi-rant... Why don't people get that REST sucks for a wide variety of applications. Being in the automation world I run into this problem a lot. People make a device, and probably make no effort to ask anyone like me what are needs are, they put a web server in it and design a simple REST API.
The problem is that automation systems are fundamentally dependent on low latency awareness of changes in the state of devices, because users set up systems like ours to react to those changes. If it doesn't happen for a second or two after the actual change, then it's often useless or at best annoying.
So now you have a a bunch of devices out that that you just have to pound relentlessly with GET commands in order to try to catch any changes in a reasonable amount of time. And then of course they get the bright idea to make it 'easy' by only allowing the transfer of the entire state of the device (like the Hue), so you have to transfer the entire state of the device multiple times a second in order to catch a change that might not happen for many hours or even days at a time, but has to be caught quickly when it does.
And, then the customer has some other thing that also needs to do the same, so it's pounding the same device relentlessly and now the device is overloaded and starts responding more slowly in general, or crapping out periodically.
It's like so many people just don't even think beyond a REST API or HTTP, and throw it into everything, whether it's remotely appropriate or not.
Explorans limites defectum
modified 18-Apr-19 14:37pm.
|
|
|
|
|
There there.
I agree. It sounds like the device should be the client rather than the server. It should use REST to send data a Web Service.
modified 18-Apr-19 20:03pm.
|
|
|
|
|
You generally don't really want to go that direction for security purposes. The automation controller should always be the one that makes the connection if at all possible.
Explorans limites defectum
|
|
|
|
|
So, what's the solution?
An x second timeout on a GET that only returns when the underlying data has changed?
(Almost like a remote event handler?)
|
|
|
|
|
Don't use HTTP is one obvious one. Or, if you do, follow the ISY example and send async responses over a persistent connection.
Explorans limites defectum
|
|
|
|
|
I agree that REST seems like a poor choice for low latency.
Just a thought - latency can be reduced by using more modern frameworks that while they do serve the entire state initially only subsequently serve the elements of the state that have changed or use SignalR.
On the area of latency - even if you do use a protocol that is less data intensive than REST, if you are not using a private direct network connection your latency will surely always be at the mercy of things that are out of your control - or have I misunderstood what you are saying?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's not up to me, we are at the mercy of whatever the device manufacturer decides to do. Of course TCP/IP in general is a bad choice for most small automation doo-dads, but since it's the defacto, ubiquitous connection scheme that is going to be in there in the home, more and more companies use it. It's always the same, unplanned, excremental growth leads to the worst case scenario becoming the standard scenario so often.
The only device that uses HTTP well (that I've run across) is the ISY 994. It uses a persistent HTTP connection and just asynchronously sends notifications as GETs to the automation system when something changes. If you are going to use HTTP, that's how it should be done.
There are other simple schemes that work well. One is to keep a running 64 bit serial number. Every time a value is changed, bump the serial number and set it on that value. Keep a sorted list of such changes (Which is simple and efficient to do, push each one onto the top of a stack when it changes, if it's full dump the bottom one.)
When a client asks for changes, they pass the last serial number they got (zero if none yet), and the device can just find that number in the list (binary search since it is sorted by serial number), and returns him anything from there forward. If the number is below the bottom, he returns an error saying 'sorry you have to do a full resync'. If it works, the automation system just stores that returned serial number as the last one it got, and passes it back next time. The majority of queries just return a very small 'no changes' status since the serial number passed is the same as the one on top of the stack.
I use this type of scheme to VERY good effect in CQC in a number of places. My ORB supports it as well, with a special 'poll method' that takes a serial number as the first parameter and returns a boolean. If the serial number is the same as the handler on the server side, then it returns false and the server side ORB knows it doesn't have to stream back any of the output parameters.
Explorans limites defectum
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
