I have a site that uses iframe-resizer. After some code clean-up, every iframe on the app broke in seven different ways. Practically, this was the worst on pages that had infinite scroll or similar events triggered as the page moved. The resizer was triggering a scroll event which was triggering loading which was triggering more scrolling! To make matters worse, the scroll event handle was either non-existent or it was from jquery, and it was absolutely no help.
In the end, we had configured the attributes on the iframe tag incorrectly. The clean-up had caused them all to be null when compiled into the app, so they never got rendered properly. This didn't show up as null in the final HTML, and there were no helpful errors to guide us. It took a long time to root out.
As you modify a system with iframe-resizer and everything goes to hell, make sure any changes to the iframe tag attributes or configuration is actually getting compiled down properly still. It can save a world of headache.
Could not connect to the endpoint URL: "https://oidc.<region>.amazonaws.com/device_authorization"
I had not changed any settings. It just randomly stopped working.
While I'm not sure of the root cause, restarting the PC has fixed it for me more than once. I have also thought that renaming your ~/.aws/sso folder might do the trick.
Quick post to note how I got my Anycubic Kossel Pulley basically working. It took me forever to find how to do some of this, and I know I will forget it if I do not write it down.
Upgrade the firmware to Marlin 1.1.9. I ended up using 1.1.9.1 as of this writing.
Use DaHai's files and modify them to work with stock Steppers. Use Arduino IDE to load the firware after replacing Configuration.h and Configuration_adv.h (which I did not make changes to). Here are the changes I made to his Configuration.h:
Line 624-626: Change these from his upgraded TMC2130_STANDALONE to stock A4988
Line 705: I got crazy loud stuttering when first descending to the bed during a print. Lower this to get rid of that.
Line 868: I and several people online have measured and gotten good resulting prints with the Type 2 Probe Offset at -15.88
Line 938 to 940: These need to be true for stock steppers. DaHai's steppers did not need to be inverted.
Line 1358-1364: Define your temperature presets. I have used PETG to great success with a preheat of 70C for the bed and 230C for the hotend. This rises to print at 80C and 245C respectively during the print.
When following the leveling instructions, the video shows a "Set Delta Height" option that is absent in the version of the firmware I loaded. This caused me no end of headaches later when the method of subtracting the bed distance from both the Z-Height and Probe Offset produced weird math and never worked properly. Instead, I ran auto-calibration, saved the settings, then:
Noted my Z after going to Prepare -> Auto Home
Brought the nozzle to the bed using Prepare -> Move Axis -> Move Z until a business card wouldn't move when squished between the axis and the bed. I then noted the height
Changed my Z height only by this amount by subtracting the number from the Z height, and a negative Z Height is thus added.
Saved and Auto Homed
Set my Probe Offset to 15.88 per recommendations online.
Checked it again and only touched the Z Height when it was off. Repeat the Z height move if this is still not right.
With the printer calibrated, it was time to print. I just used Cura because I couldn not get Slic3r or Pronterface to work easily. Cura does not have the Kossel in it by default, but it can be easily added. JDHarris on Thingiverse even shared the configuration file they made which can be picked up by Cura after a restart.
I printed with PETG which has a high temp but no fumes. I found hairspray for adhesion worked best thanks to several awesome tips by people connected with the PDX hacker community. Thanks all!
After this, it just worked and keeps working. It's magical what a little math and open source firmware will do. That being said, it's my first printer. It is bound to break in ways I can't even imagine now. First order of business? Print things that make the printer better, as is tradition.
Update: Not all is well in Whoville. I've developed some Heat Creep with this PETG printing at 245C, and I haven't had the time to troubleshoot it. Wish me luck!
It turns out that using the convenience function ENCRYPT$ENCRYPT_ONE_RECORD on OpenVMS for AES CBC does something squirrelly. It will not let you pass in an IV. Instead, ENCRYPT$INIT sets the IV to 16 bytes of \0. In order to ensure your identical plaintext first blocks aren't identical after encryption, your first 16 byte block needs to be your true IV. This will get XORd with the null byte encrypted IV and sufficiently scrambled so your second block can be uniquely encrypted. OR just do it right and avoid the convenience method. Use ENCRYPT$INIT properly.
"For AES, the optional P1 argument for the AES IV initialization vector is a reference to a 16-byte (2 quadword) value.
If you omit this argument, the initialization vector used is the residue of the previous use of the specified context block. ENCRYPT$INIT initializes the context block with an initialization vector of zero."
Above is Dan Kaminsky's keynote at the inaugural DEF CON China. It was nominally about Spectre and Meltdown, and I thought it was immediately applicable to testing at all levels. Here are some moments that jumped out at me:
On Context:
"There's a problem where we talk about hacking in terms of only software...What does hacking look like when it has nothing to do with software." 1:55
"But let's keep digging." Throughout, but especially 5:40
"Actual physics encourages 60 frames per second. I did not expect to find anything close to this when I started digging into the number 60...This might be correct, this might not be. And that is a part of hacking too." 6:10
"Stay intellectually honest as go through these deep dives. Understand really you are operating from ignorance. That's actually your strong point. You don't know why the thing is doing what it is doing...Have some humility as you explore, but also explore." 7:40
"We really really do not like having microprocessor flaws...and so we make sure where the right bits come in, the right bits come out. Time has not been part of the equation...Security [re: Specter/Meltdown] has been made to depend on an undefined element. Context matters." 15:00
"Are two computers doing the same thing?...There is not a right answer to that. There is no one context. A huge amount of what we do in hacking...is we play contexts of one another." 17:50
[Re: Spectre and Meltdown] "These attackers changed time which in this context is not defined to exist...Fast and slow...means nothing to the chip but it means everything to the users, to the administrators, to the security models..." 21:00
"Look for things people think don't matter. Look for the flawed assumptions...between how people think the system works and how it actually does." 35:00
"People think bug finding is purely a technical task. It is not because you are playing with people's assumptions...Understand the source and you'll find the destination." 37:05
"Our hardest problems in Security require alignment between how we build systems, and how we verify them. And our best solutions in technology require understanding the past, how we got here." 59:50
On Faulty Assumptions:
"[Example of clocks running slow because power was not 60Hz] You could get cheap, and just use whatever is coming out of the wall, and assume it will never change. Just because you can doesn't mean you should...We'll just get it from the upstream." 4:15
"[Re: Spectre and Meltdown] We turned a stability boundary into a security boundary and hoped it would work. Spoiler alert: it did not work." 18:40
"We hope the design of our interesting architectures mean when we switch from one context to another, nothing is left over...[but] if you want two security domains, get two computers. You can do that. Computers are small now. [Extensive geeking out about tiny computers]" 23:10
"[RIM] made a really compelling argument that the iPhone was totally impossible, and their argument was incredibly compelling until the moment that Steve Jobs dropped an iPhone on the table..." 25:50
"If you don't care if your work affects the [other people working on the system], you're going to crash." 37:30
"What happens when you define your constraints incorrectly?... Vulnerabilities. ...At best, you get the wrong answer. Most commonly, you get undefined behavior which in the presence of hacking becomes redefinable behavior." 41:35
"It's important to realize that we are loosening the assumption that the developer knows what the system is supposed to do...Everyone who touches the computer is a little bit ignorant." 45:20
On Heuristics
"When you say the same thing, but you say it in a different time, sometimes you're not saying the same thing." 9:10
"Hackers are actually pretty well-behaved. When hackers crash code...it does really controlled things...changing smaller things from the computer's perspective that are bigger things from a human's perspective." 20:25
"Bugs aren't random because their sources aren't random." 35:25
"Hackers aren't modeling code...hackers are modeling the developers and thinking, 'What did [they] screw up?' [I would ask a team to] tell me how you think your system works...I would listen to what they didn't talk about. That was always where my first bugs came from." 35:45
On Bug Advocacy
"In twenty years...I have never seen stupid moralization fix anything...We're engineers. Sometimes things are going to fail." 10:30
"We have patched everything in case there's a security boundary. That doesn't actually mean there's a security boundary." 28:10
"Build your boundaries to what the actual security model is...Security that doesn't care about the rest of IT, is security that grows increasingly irrelevant." 33:20
"We're not, as hackers, able to break things. We're able to redefine them so they can't be broken in the first place." 59:25
On Automation
"The theorem provers didn't fail when they showed no leakage of information between contexts because the right bits went to the right places They just weren't being asked to prove these particular elements." 18:25
"All of our tools are incomplete. All of our tools are blind" 46:20
"Having kind of a fakey root environment seems weird, but it's kind of what we're doing with VMs, it's what we're doing with containers." 53:20
On Testing in the SDLC
"We do have cultural elements that block the integration of forward and reverse [engineering], and the primary thing we seem to do wrong is that we have aggressively separated development and testing, and it's biting us." 38:20
"[Re Penetration Testing]: Testing is the important part of that phrase. We are a specific branch of testers that gets on cooler stages...Testing shouldn't be split off, but it kinda has been." 38:50
Ctd. "Testing shouldn't be split off, but it kinda has to have been because people, when they write code, tend to see that code for what it's supposed to be. And as a tester, you're trying to see it for what it really is. These are two different things." 39:05
"[D]evelopers, who already have a problem psychologically of only seeing what their code is supposed do, are also isolated from all the software that would tell them [otherwise]. Anything that's too testy goes to the test people." 39:30
"[Re: PyAnnotate by @Dropbox] 'This is the thing you don't do. Only the developer is allowed to touch the code.' That is an unnecessary constraint." 43:25
"If I'm using an open source platform, why can't I see the source every time something crashes? ...show me the source code that's crashing...It's lovely." 47:20
"We should not be separating Development and Testing... Computers are capable of magic, and we're just trying to make them our magic..." 59:35
Misc
"Branch Prediction: because we didn't have the words Machine Learning yet. Prediction and learning, of course they're linked. Kind of obvious in retrospect." 27:55
"Usually when you give people who are just learning computing root access, the first thing they do is totally destroy their computer." 53:40 #DontHaveKids
"You can have a talent bar for users (N.B.: sliding scale of computer capability) or you can make it really easy to fix stuff." 55:10 #HelpDesk
"[Re: Ransomware] Why is it possible to have all our data deleted all at once? Who is this a feature for?!... We have too many people able to break stuff." 58:25
The AC on my land yacht (2009 Mercury Grand Marquis) has been in the fritz for a while. Last winter, it gradually stopped switching from max AC/recirculate (a necessary in Vegas), then got stuck on norm AC until it rested on Defrost/Floor. I was able to fix it with some basic troubleshooting, YouTube sleuthing, and two bucks in o-rings.
The same video showed me how to diagnose the vacuum problems. The black hose providing vacuum from the engine seemed fine: I was getting 20 inches of vacuum with the car turned on when I hooked up a bleed pump with a gauge (mine came from Harbor Freight, shown in the video). To test the actuators, all I had to do was hook a 'jumper' pipe from black to the other pipes. Each one seemed to hold air, and the actuators sprang to life once again. For the first time in a year, I had cold air blowing from the vents. The problem couldn't be in the lines. I pulled the controller head for a closer look.
The head itself is a bunch of electronics, a control panel, and one removable plate with four solenoids. The vacuum hoses come into this through a manifold, and the head controls trigger the solenoids to route vacuum from the black hose to the others. This triggers different actuators under the dash. Something was amiss in the manifold.
I returned to YouTube looking for rebuild instructions. I found this extremely helpful video from a Chicago mechanic. The solenoids contain an o-ring that dries out, wears out, and loses the ability to hold vacuum. I obtained close to the recommended o-rings from Lowes (#36, 5/16 OD, 3/16 ID, 1/16 thickness) as I was not willing to wait for Amazon. A little Oatey silicone lubricant made the tight squeeze work a little better. I found I had to seat the solenoid heads at least once before total reassembly. It was too difficult to do so at the end and fight with the other small parts at the same time. 45 minutes later, I had full control of my AC restored.
I can't believe it was this simple to fix the controller. I think I was intimidated by the AC (having spent $1500 last year to have the dealer redo the whole system from seals to refrigerant). I didn't want to break anything. A few targeted troubleshooting steps helped assuage any fears of irreparable harm, and now I have a comfortable cabin once again.
