trelliscoded

The source seems to be a lack of a source. No one has offered up a smoking gun directly linking Russia to the DNC leaks. The most conclusive evidence anyone's been able to provide so far has been that the build times for the malware matched work hours for UTC +4, and Russian language settings were used by the build host.

None of this proves anything about who's behind it. For example, some other country could have simply hired a Russian firm to do the work.

There's also the possibility that this is a false flag operation. If a non-Russian entity had hired me to point the finger at Russia when deploying the RATs, I probably would have modified the executables in exactly the way that's being observed. Sanitizing malware to hide its origins boils down to two options: 1) sanitize everything so it looks like anyone could have done it, or 2) modify it to make it look like someone else did it. If you're politically motivated, 2) would probably be the way to go since your target is going to waste resources going on a wild goose chase.

Popped amaranth is a nice snack, too.

You're right, what I really meant was radiation pressure doesn't require reaction mass.

I just wanted to point out that thrust without expending mass is already possible without an emdrive.

Anything that asymmetrically radiates photons will generate a net acceleration. This very mechanism has been experimentally verified as the pioneer acceleration anomaly.

If the emdrive is some kind of special case of this mechanism, it's entirely compatible with existing physics. The proposals so far are based on mechanisms which are different, and incompatible with the existing understanding of the universe.

It's also worth noting that in 2016 the Chinese research team was unable to replicate their findings after accounting for a power cable that was magnetically inducing a force on the experimental apparatus.

Emergency procedures for administrating the network gear. There's two sections: 1) symptom->fix procedures, and 2) how to rebuild everything in the network from scratch in case it got wiped.

The reason it's in hardcopy is because you can't look stuff up on the Internet if the Internet is down.

Anticipate their emergency procedures, and ship them a binder wrapped with dire warnings should it be removed from the data center. Multiple customers have said this has saved their bacon.

Multicast on top of MPLS isn't really a thing with respect to the backbone routers.

I understood it. They covered this stuff in the discrete math class I took at community college.

Orion's Arm is a collaborative world building project for the far future. The articles on monopole physics and wormholes are quite detailed, and the implications of higher levels of sentience are very interesting. http://www.orionsarm.com

The SCP foundation has been mentioned, but a lot of people don't know they have a sister site. http://wanderers-library.wikidot.com

The wikipedia articles about unsolved problems in physics and emerging technologies are huge click holes for most nerds:

https://en.wikipedia.org/wiki/List_of_emerging_technologies

https://en.wikipedia.org/wiki/List_of_unsolved_problems_in_p...

Reading about neolithic archaeology is way more fun than you might think. 10,000 years ago people built these huge sites with literally stone age technology, and the nature of their rituals and beliefs are mostly unknown.

https://en.wikipedia.org/wiki/Neolithic#Early_settlements

Shodan is a search engine for devices on the Internet. Looking at other people's queries is a good way to get started. Every time you think, there's no way someone would connect one of those to the Internet, you find out that at least 10 people have gone and done just that. https://www.shodan.io/explore

Running an NTP server in the public pool gives you the IPv6 addresses of all kinds of whacko IoT stuff. Every once in a while p0f can't figure out a TCP/IP stack that's connecting to my server, so I connect back and there's sometimes a really weird device with an open telnet or HTTP port or something. About once a month I have to call someone to tell them that they misconfigured their firewall when they turned on NTP and I'm logged into an air conditioner on a cruise ship or another bizarre combination of thing and place that I never thought I'd ever say out loud. Browsing the logs is a never-ending source of amazement.

PSA: connecting to public NTP servers exposes you to people like me, don't do it unless you have to.

It seems to me that the #1 way to predict pilot performance in emergencies is whether the pilot has encountered the emergency before and lived. If so, running the pilot through the most scenarios possible in a given unit time would seem to be a good strategy to train pilots, and simulators would increase the rate of scenarios per unit time versus a real aircraft.

However, you can't get away from actually flying a plane. There's little things you don't practice in the simulator, like making sure you have your handheld VHF radio, checking for water in the fuel tanks, and how to balance cargo, that you'll never learn in front of a computer screen.

If it's anything like network administration, I'd say something like 20% real experience vs 80% simulated might be a good mix. People who favor just one or the other lack performance under adverse circumstances compared to admins who do both, I've noticed.

Probably because they're worried about keeping two providers in sync throughout the entire world, or they don't have a DNS wizard on staff.

I don't see why sync would be a huge problem; these days moving services usually involves slowly draining active connections from the old addresses while new connections go to the new address. If it takes a day for all the clients to move to the new address then fine, the migration just takes longer.

The user land is based on FreeBSD, which has run on arm for years.

An interesting idea. I know that most of the apps I use on my mac are Apple's, so if they ran on a low power arm cord while everything else was on an x86 core I imagine I'd have significant power savings.

Apple would have to get the GPU vendors to write drivers for their processors though, which would be a tremendous engineering effort. Intel would likely resist any such proposal for their Iris GPUs though, they're having enough of an existential crisis as it is without worrying about one of their largest customers moving away from their main product.

DDoS mitigation is already a mostly solved problem; IDMS/TMS and RTBH are things. Many networks don't install them though, and when they do they often only get tested once an attack starts. For obvious reasons, many network operators are highly reluctant to hose down production services with test attacks.

Adding crypto isn't going to help in the case where someone's hosing you down with reflected UDP traffic, as the packets are still going to transit your ingress link and clog it up for production requests. Sure, you can force the use of DTLS, but your load balancers are just going to go "well this is bogus traffic" and throw it away, but by then it's too late since it's already in your network.

Mandating egress filtering for traffic isn't going to help that much either, because then a botnet is just going to stop spoofing traffic. This makes it easier to mitigate it from the target's perspective, but with a large enough set of transmitters the target will still see an impact.

The bottom line is that if you want to allow connections from the entire Internet, then every lightbulb, refrigerator, and lawn sprinkler with a wifi chip is eligible to connect to you. Unless there's an effort to create international policies to stop vendors from shipping exploitable firmware for these things, this problem is just going to keep getting worse for those of us who can't afford good DDOS protection.

If you've had to troubleshoot network corruption at scale, you memorize packet details real fast :)

NFS clients can block on I/O forever if you aren't very careful with your file I/O design. I think it's usually better to use a message queue for every NFS use case I've seen lately.

For anyone who has some spare time, here's an enormous time sink:

http://www.orionsarm.com

Don't click on that if you have stuff to do today.

The YouTube link results in "invalid video ID" on my iPhone.

  Location: San Jose, CA
  Remote: Done it before, can do it again
  Willing to relocate: For the right price
  Technologies: {Windows, Linux, Cisco, Juniper, HP} administration, C, modern C++, Javascript/node, Linux, Darwin, Win32/64
  Résumé/CV: email if needed
  Email: mackeycam25@gmail.com

I'm an ideal senior devops, SRE, or cloud engineer. My background is unusual because I started as an embedded engineer, had network and system administration duties added, and finally learned how to do security by winning awards at some high visibility contests. Because I've built every hardware or software part of a technology stack in my career at some point, I'm unusually good at troubleshooting weird cloud problems.

I also have a decade of experience professionally administering complex networks. Even if I'm hired as a programmer, I always end up also being "the network guy" somehow, since I've written so much automation to do the job for me.