notakio

I simply meant that if you monitor a given application using on-system network tools, you quickly get an accurate idea of what/who that application talks to. And browsers are super-chatty to all sorts of destinations that are not immediately apparent to an end user who is just clicking around the web.

Besides lsof and netstat?

We're still good now.

Whoops. I used hyperbole, and it went undetected. Here: s/the deciding factor/a deciding factor/g. We're good now.

One should be wary of anyone selling you a solution to your problems they know nothing about. Naturally, the only way to be entirely secure is to shutdown all the applications and decommission all the computers, a solution which the business side tends to finds unreasonable. Thus the tender balance between business needs and business risk emerges as the deciding principle.

But the numbers are the numbers in heterogenous environments, regarding security problems by platform. And if it rains perpetual Windows-based incidents on your security staff, and you don't consider the numbers when evaluating what you will and will not do, compute/services-wise, then you are statistically likely to see the same rate of incidents, at whatever cost that comes to the business, indefinitely.

If every car in your neighborhood that gets broken into is manufactured by a single manufacturer, it is in your interest in asking why that is, and perhaps considering that fact when shopping for a new car.

Very curious. Just based on the incidents we see, and analyze over time, almost all of them are compromised Windows systems. When I say "almost", I'll provide these stats: ~4500 Windows incidents over 5 years, vs. two Linux incidents.

Similarly, looking at vulnerability counts by vendor doesn't paint a rosy picture of our largest vendor Microsoft, either. But it pales in comparison to the incident statistics, which speak for themselves.

To Microsoft's credit, they've managed to turn their weaknesses into a secondary industry, wherein they now no longer sell just the disease, they also sell the cure. "Oh, your Windows systems have security problems? Have we told you about our expansive security solutions? They're only an additional $your_budget_doubled per year!"

No, LetsEncrypt was not an EFF project to begin with. Look, it works how it's documented to work. If you wish it worked some other way, to solve your particular suggested workflow, you're likely free to fork it and make it work that way.

Good luck.

No, it's not the LetsEncrypt people who make certbot. Certbot is an EFF project, managed by separate people. Additionally, most of the DNS implementations will require the use of a specific plug-in/library for your selected DNS platform, and those, also, are developed separately.

Regarding "the DNS record they had you add to begin with is still there", it generally isn't. Part of the automation process for certbot using the DNS-01 challenge is the removal of the DNS record, following successful validation of said record. In any complex DNS environment, leaving TXT records around just increases the debris.

This is compounded by their propensity to rename everything at periodic intervals.

For the Microsoft.com domain, proper, there seem to be no existing CAA rules, allowing each and every CA on earth to issue certificates based on whatever criteria the CA requires. What could possibly go wrong with that approach?

I have not. I'm afraid I am a gaming luddite, though for no particular reason other than having a lengthy list of mental "to-dos" in front of it.

The article contains solid advice that certainly transcends coding, alone; in my free time, I try to essentially "find work". Sometimes that work consists of writing software to solve weird little home "problems" that may or may not be actual problems. Sometimes that means building something as a joke, just for fun. Sometimes that work consists of over-engineering a water heater box-turned-space shuttle for my daughter. Or recording my dog's wheezing and turning it into "classic industrial" music. It all feeds the same internal need, though; to learn, to build, and to produce something, rather than to passively consume other people's products. It keeps my brain alive, and I find improved performance/innovation in other work-related projects, as a result of just staying active, mentally.

And if you're the kind of person that travels in one of these, you likely also have a few additional vehicles in front of and behind your vehicle filled with highly-paid professionals ready and willing to carry you the last mile if your vehicle stops reason for any reason, to include mechanical failure.

The whole armored vehicle market is a relatively small one; it's interesting to learn that BMW is direct participant; I previously had no idea. I foresee a lot of wasted time scouring eBay looking for a project my family will resent me for later in my immediate future!

I was surprised to not see IR beacons on LEO units. In military operations with air surveillance, individuals/vehicles often use IR flashing and IR reflection to mark themselves to air assets. If MPD has the money for 1) an air surveillance unit (this cost is not trivial; SFPD, for example, hasn't had their own aviation section in decades due to the cost), and 2) decent thermal optics on said surveillance unit, then it surprises me they don't spring for sub-$100 IR beacons to distinguish their own personnel from everyone else, and enable rudimentary "blue force tracking", as it were.

Agreed. I invariably lose hours to Folklore every time I end up there. I previously worked for an original Mac team engineer, and he had some fascinating stories, but Hertzfeld's writing allows me to revisit those and so many more tales from that period of Apple/Silicon Valley history, and all without annoying my former boss for more stories.

I vote for users. I'll stay down here with compute, I know how this ends.

`brctl status` will return sync status data without requiring Finder. It isn't pretty, but it's usable via stdout and whatever tooling you'd want to use.

SFPD won't do anything about property crimes, to include vandalism, other than to take a preliminary report, on a schedule determined by the department (eg: you call them, they show up 8-12 hours later, uninterested in taking your report). This is because, currently, their DA's office isn't going to prosecute any property crimes.

That can all change, but speculating about the nature or timing of any changes like that is well outside my area, so I'll sit and watch from a distance.

And, again, I'm not vested in any outcome here. It'll work out however it works out, and I'm 2000+ miles away from it, so it won't have much effect on my life.

I have no dog in this fight. If anything, my final takeaway was that my impressions were entirely anecdotal and/or experiential, and not based on any sort of legitimate analysis with useful data. It should probably be done, but my point was more that it's only getting more complicated as people take action based on their perception, whether that perception is supported rationally or not. So now, on top of a reasonably already complex engineering problem is an additional layer to correct for: irrational human reaction.

I moved out of SF ~2018, and only recently revisited, and the increased frequency with which I saw robocars was immediately concerning to me, largely based on the potential for things to go wrong, and with just how frequent they were.

My second thought was, after hearing friends and family still there echo nothing for disdain for them, "how long before someone starts setting these on fire?" as some sort of nuisance campaign against the things. Turns out, 1) you don't need fire, and 2) not that long, since the cone thing started happening about a week afterwards.

In this case (Lejeune vs Pendleton), there would likely not be a substantial socioeconomic difference between the collective backgrounds of Marines who did basic training at either one. But comparing either camp to OCS at Quantico would, in fact, show a pretty stark delineation between the socioeconomic backgrounds.

Via a link posted here, perhaps. A "soft" DDOS, if you will.

Yep. Most electric companies will be more than delighted to run a second line to your home, as they then get to collect those sweet installation costs from you. So if you're willing to pay, they're probably more than happy to let you.

I've used the Pi (both a 3 and 4) as a temporary server when moving (read: leave the old server up at home until move-day, while placing a Pi in the new home, configured to take the www load normally pointed at my old server. I'm hosting 14 sites from home, none of which are high traffic, but under those circumstances, the Pi held up just fine. Once move-day comes, I'd make the DNS change to point at the new Pi, pack my stuff, move, then reverse that process once I've brought the old server back online.

I'd say unless your web app is resource-hungry, the Pi is totally viable as an option.

They are also historically credited with inventing usury, so presumably yes. This describes the situation fairly accurately: https://thetemplarknight.com/2010/12/22/templar-usury/

Essentially, the Roman Catholic Church turned a blind eye to the Templars usury, largely because of the value provided by the Templars in enabling an endless stream of warriors for Christendom. They did set some arbitrary limits on the amounts that were permissible, but didn't have much in the way of methods of auditing or enforcement.

I only ever got to play with BeOS on a Daystar Digital quad-PPC machine I "inherited" from work when it got replaced with more Mac hardware. I've always wanted to pick up an original BeBox, but even in the heyday of "cheap exotic hardware" (NeXT, SGI, etc) that was the mid-to-late 1990s, I never saw one pop up. As such, I am suitably envious (and find myself setting up alerting for my newly re-invigorated search for this grail, while downloading the Haiku .iso to spin up a VM, which, I assure my boss, is a fantastic use of my working hours), and greatly appreciative to have had the opportunity to read this today.

It has been illuminating for me over the past few weeks to have lost hearing in my right ear as a result of a lingering sinus infection; I understood that identifying the direction a sound might come from would be difficult with only one ear, but I had no idea how crucial it was for speech comprehension, particularly when any other noise is also present.

I've found that I can barely even discern that speech is present within a mix of noises, much less am I able to comprehend the speech until such time as I can reduce the other noises to a minimal level, and directionally point my ear at the source of said speech. Conference calls were quite a delight there for a while.

I've found the Pis to be surprisingly resilient, heat-wise. I built a handful of inline monitoring servers running suricata, pulling yml configs from puppet, and forming an ad-hoc network with one another, with devices in a reasonably harsh manufacturing environment for six months' testing (near welding robots, and in network cabinets that average 180F during "non-load" hours) and didn't see a single system failure, crash, or reboot during that time. Literally the only thing I had problems with was maintaining consistency for the ad-hoc network, and that was largely owed to the amount of interference on the manufacturing floor, combined with greater-than-suggested distances between the devices.