brooksgarrett

I'll second you. I full time admin our K8s infrastructure and clusters. It's a great solution for our production workloads and I've bootstrapped RancherOS/k3s a handful of times to look at using it at home but K8s is purpose built for cloud. I can get all the same benefits with significantly reduced complexity with Docker + Systemd at home.

Necrosoft.

Except we will never actually know...

73 DE WP3NIS

I went back and rewatched it. I completely forgot they forced it. I first saw this a couple months ago when our TC used it for extrication refresher. I have to admit, even though it is staged and the car is completely intact, watching those guys is money. Super smooth execution. The way he handled the halligan solo to create the frunk gap was pleasing to watch.

We don't. It's a cool video for a training night but really it's a pretty standard dash roll. Electric cars present a very real danger but so do ICE. High pressure fuel lines with pumps that don't shut down. Diesel engines which "runaway" with air intake leaks.

Every call is a special situation where you start with a baseline tactic and evolve the approach as needed. 20 minutes is overkill but the whole time we were watching it here we were discussing extrication in general. "Would you do this or that? What would you look for here? Did you see their step cribbing placement?" The Tesla responder guide is awesome and available online and is all you "need" to know where and what to cut. The video is more a conversation starter.

I'm not sure what ram speed has to do at all with extrication. The biggest problem area I see with the model 3 is the fact that a large portion of the high voltage carriers are centerline on the vehicle. In our department using the center post for dash lift/roll allows us to work both front seats without obstructing patient egress via the side/door. In the Model 3 you don't have the option to roll from the center.

I'm willing to bet my Hurst spreaders will get the frunk open sans battery. If you're cutting the car, it's already totaled and limiting damage to the frunk would be the last concern on my mind.

No. The internet is in a box and Jenn broke it.

In one, you intentionally give false information and lead the government believe you in good faith complied. In the other, the data is inaccessible and the government is aware it is inaccessible. They can then evaluate risk and seize the device or take some other action from that knowledge. IANAL and I don't play one on TV.

ETA: To complete the threat analysis, and if they seize two devices, one with a password protected key and a LUKS volume without headers? I'll take LUKS.

I took a workshop on custom Kali builds where they specifically spoke about LUKS headers and shipping them via email/gdrive to yourself and removing them from the physical device. It renders the partition useless. This was viewed as a better alternative than something like TrueCrypt with decoy passwords since if the government can ever prove you did it then that's obstruction. With the headers gone and no local copy you can't provide what you don't possess.

Not data but a strong anecdote to support your assertion: https://www.forbes.com/sites/jasonevangelho/2019/04/08/linux...

Here is an AWS developer discussion that details their response:

https://forums.aws.amazon.com/message.jspa?messageID=851817#...

Quote for those without access: There is a known bug with Route 53 DNS servers in which we are not RFC compliant in how we handle a specific kind of invalid query. Namely, when Route 53 gets a query with an unknown EDNS version, Route 53 treats the query as a non-EDNS query instead of responding with BADVERS as ednscomp expects.

We expect to have this bug fixed within a year or two. The good news is that this bug is not impacting, so you'll be ok even if we're slow to fix this. The "dnsflagday" news means that servers that don't support EDNS will be treated as unavailable to resolvers. But Route 53 generally supports EDNS0, valid queries will continue to work regardless.

Firefighter for over 10 years and an IT career spanning Red Team/Blue Team and now SRE, I can't recommend enough taking the FEMA Independent Study course in Incident Command.

https://training.fema.gov/is/courseoverview.aspx?code=IS-100...

Even if you don't adopt the system it will help you frame and understand how complex IR can be. Having a scalable system to a) grow with resources and b) grow with external interactions is crucial to have BEFORE you need it.

I agree. I've never been on a fireground and had someone yell, "We lost the house because you didn't divide by 12!" Fireground math is a very rough science. Every engine in our district has pre calculated charts for every cross lay and discharge so you aren't doing the math on scene. Additionally, once you deploy line you have a radio and can ask the engineer to increase or decrease pressure with no math required.

A much bigger issue is the lack of recruitment and volunteerism in the American fire service. People simultaneously don't want to increase property taxes to fund career departments and they also don't want to volunteer. Communities can't have it both ways. Lack of staffing is a far greater risk than whether I'm dividing by 10 or 12.

If you have fire based EMS then that will account for the vast majority of your call volume, full stop. Accidents requiring extrication are rapidly decreasing as cars are becoming safer. Additionally, homes are becoming drastically less at risk of fire (to the point many municipalities now include residential suppression sprinkler systems as a building code requirement.)

As an anectdote, my district has around 10 miles of interstate and 20 miles of major highways. Our call volume is, in order of prevalence,: 1. Fire Alarm (Only 2 have ever been actual 'fires') 2. Medical Assistance (We are EMR, not EMS) 3. Grass fires / Trash fires 4. Accidents 5. Building fires 6. Something else

Our neighboring district has a ton of farms and little to no major roads. They may receive a total of 20 calls per year compared with over 300 in our station. (Both low volumes but the type of response is reflected.)

Speaking from experience, it's primarily due to 'tradition.' All of your combi-nozzles and rate control valves are rated and marked in GPM (Gallons per minute) and hose is purchased and stored as 50' sections. NFPA specifications for the hose required on a first due engine are in feet.

A department can't decide to use metric alone. The entire industry first would need to support at the minimum both standards.

I think that is a compelling narrative. I truly hope this takes off. I know several attorneys and other small shops that would value such a time saving service. The only major barrier is still getting them to design and publish the content. Solving that in the manner previous hosting companies made WordPress a one click install will be a major win.

After more reading you offer significantly more value than a pure static site with custom redirects and API passthrough. I just wonder about differentiating from CloudFlare.

How is this different from GitHub hosted source(Free), compiled by TravisCI (Free), hosted in S3($15/year), secured byand fronted by CloudFlare (Free).

This is my setup (minus CloudFlare for CDN). http://brooksgarrett.com/blog/jekyll-github-travisci-s3/

Is the value in simply abstracting away the (fairly technical) setup which would normally be a barrier for non technical businesses?

The biggest problem with this question is the breadth of the term 'hacker'. Hackers tend to clump into whatever projects they are currently working on. Try starting off in places like #ubuntu and other projects (that interest you!) that are very newbie friendly. Master a topic and try helping other newbies with that topic. It takes time but my personal experience is the best way to be involved in the 'hacker' culture is to be recognized as someone who brings value and contributions back to the group, regardless of the size of those contributions.

I think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.

The absolute best way to know that is to know the public host key and verify your keys. Additionally, you don't have to resort to high ports to achieve a best of breed. Just !=22 is enough to avoid majority of skiddies.