Enlightenment here comes when you realize others are doing the exact same thing with the exact same justification, and everyone's pain/reward threshold is different. The argument you are making justifies their usage as well as yours.
405 karma · joined April 20, 2013
Enlightenment here comes when you realize others are doing the exact same thing with the exact same justification, and everyone's pain/reward threshold is different. The argument you are making justifies their usage as well as yours.
I've been email self-hosting for a decade, and unfortunately, self-hosting your email will not help with this point nearly as much as it seems on first glance.
The reason is that as soon as you exchange emails with anyone using one of the major email services like gmail or o365, you're once again participating in the data collection/AI training machine. They'll get you coming or they'll get you going, but you will be got.
The way I've put this into practice is that instead of letting claude loose on production files and services, i keep a local repo containing copies of all my service config files with a CLAUDE.md file explaining what each is for, the actual host each file/service lives on, and other important details. If I want to experiment with something ("Let's finally get around to planning out and setting up kea-dhcp6!"), Claude makes its suggestions and changes in my local repo, and then I manually copy the config files to the right places, restart services, and watch to see if anything explodes.
Not sure I'd ever be at the point of trusting agentic AI to directly modify in-place config files on prod systems (even for homelab values of "prod").
It's worth an assessment of what you _think_ running ssh on a nonstandard port protects you against, and what it's actually doing. It won't stop anything other than the lightest and most casual script-based shotgun attacks, and it won't help you if someone is attempting to exploit an actual-for-real vuln in the ssh authentication or login process. And although I'm aware the plural of "anecdote" isn't "data," it sure as hell didn't reduce the volume of login attempts.
Public key-only auth + strict allowlists will do a lot more for your security posture. If you feel like ssh is using enough CPU rejecting bad login attempts to actually make you notice, stick it behind wireguard or set up port-knocking.
And sure, put it on a nonstandard port, if it makes you feel better. But it doesn't really do much, and anyone hitting your host up with censys.io or any other assessment tool will see your nonstandard ssh port instantly.
Would you like to debate the reality of anthropogenic climate change next? This will be another area where any links you dig up will only point to a single conclusion.
Except it's not—fluoride in the drinking water concentrations is proven safe and it doesn't affect brains.
> Im not clear the validity of those claims
Thoroughly scientifically debunked. Repeatedly, over decades.
> That seems the core issue- without bias from stakeholders, is the benefit of fluoride proven and the risks disproven? It’s hard to answer because a study needs to span many years and exclude many variables.
No, it's not hard to answer, because all those studies have been done and the results were that fluoride is safe.
> And in general I think that is what needs to happen with these type debates.
What needs to stop happening is people ignoring objective reality just because the results happen to align with the other "team's" position on something.
The disconnect here is that your professors are assigning you work like this because the purpose of a university education is to broaden your horizons, challenge you, and force you to think about _how to think._
The fact that you're treating it like trade school is your problem, not the university's.
> I distinctly remember being penalized for any insight that didn't fit marking criteria back in high school english lit.
Good for you. High school writing has nothing to do with university-level papers.
> Well, most lectures just aren't very helpful. They move slower than if we just read the docs. Some lecturers are also just incompetent with barely any understanding of what they're teaching in the first place...
Your issue, again, is that you're arrogantly assuming you don't have anything to learn from things you personally haven't prioritized. A major role of a university education is to beat that idea out of you by showing you how wrong you are. Pity it isn't sticking.
> ...though this probably wouldn't be as big of a problem in better universities like Ivy Leagues where the author works
What the actual fuck, dude? Ivy League? Right in the second paragraph: "I teach at a regional public university in the US."
I went into this article kind of annoyed at the stereotyping of "these kids today," but way to go reinforcing the article's points. Damn.
Not trying to be contentious, but I've got a 5-digit slashdot ID and I've never heard that phrase explicitly used in my entire life as a term of art by software devs, including at or around 1999.
Definitely not saying that nobody was using the term, but "widespread use" is a big claim that requires some substantiation. It absolutely does not align with my lived experience of the time.
In-person sales work at least in part because salesbros are trained to handle and overcome objections. They do it in many ways, and most of those ways take advantage of the fact that people by and large tend to want to act agreeable and kind to each other kind of by default. If you opt for the in-person meeting, the salesbro knows they have the opportunity to guilt or nudge or suggest you into buying additional services, or a longer service agreement, or a higher SLA, or whatever.
So, OP isn't the customer because they're announcing they're not interested in the dance. Many (not all!) IT vendors prefer the dance because it makes more money.
I say this as a former presales engineer for EMC (before it was EMC/DELL), serving large enterprise named accounts in the Houston area. If my boss saw me in the office, he'd kick me out and tell me I should be out taking clients out to lunch or to Astros games or whatever. I spent probably $2-3k/week on entertainment, and it was basically imaginary money to EMC, because if me and my salesbro blew $20-30k hooking a client, we were going to be doing it on a $2-3 million Symmetrix deal with 70-80% margin.
So yeah. OP isn't a customer because they don't want to play, and (most, not all!) companies can extract more revenue out of customers who DO play.
As to why Varnish + Nginx versus just Nginx + FastCGI or proxy cache, I was chasing the performance dragon. AIUI, Nginx's fastcgi and proxy caches just store the static-ified versions of dynamic content in flat files, and those files are accessed via the file system, which means they get cached into RAM whenever the file system decides they get cached into RAM. I had the free RAM, and Varnish's RAM-first approach felt like it would be faster. Plus, this was all for personal hosting, and playing with Varnish was fun. (Or at least "fun.")
Clarification: the "caching plugins" are just administrative tie-ins to Varnish and Cloudflare, not actual plugins that make WP perform any caching at the WP application layer. The site doesn't use W3 Total Cache or WP Super Cache or any other popular WP cache plugin.
(edit - at the wordpress application layer, i mean—talking about that specifically, not layer 7 cache in general)
It's also currently very beta. The management tools are currently CLI-only; it can't be used on a boot volume; it's case-sensitive (not case-preserving, but actual-for-real case-sensitive); it checksums metadata but not all file data.
Apple intends for it to be their whole-ecosystem file system (and it's already showing up in iOS - https://arstechnica.com/apple/2017/01/ios-10-3-will-be-apple...), and the rollout will be fun to keep an eye on.
Today, APFS is an interesting beta project and if you're an apple developer—especially one whose apps do more than casual manipulation of the file system—you should start getting your hands dirty with it. From an end-user perspective, getting proper support of snaps and clones will be a welcome relief, especially since it seems blindingly obvious that APFS snaps will replace Time Machine's current mess of links.
But yeah, it's beta. You can't use it in production yet (can't even boot off of it). Will need to wait until later this year to get a more mature version of it before it can be adequately benchmarked and evaluated in prod.
I'm less sure about iSCSI targets, but iSCSI is a block-storage protocol. If you can format an iSCSI volume with HFS+ today, you'll probably be able to format it with APFS tomorrow.
We did run a big piece by Jim Salter a couple of years ago on next-gen file systems that focused on ZFS and btrfs (http://arstechnica.com/information-technology/2014/01/bitrot...), but yeah, I'd love to have more filesystem-level stuff showing up. The response is generally very, very strong—turns out people really like reading about file systems when the authors know what they're talking about!
edit -
> I should say that I'd only support an article like that if Ars allows parts of the written text to be incorporated into OpenZFS wiki/documenation.
That's more complicated, unfortunately. I am not a lawyer etc etc and I am only speaking generally here, but Ars and CN own the copyright on the pieces we run (though syndications like Adam's piece today are different), and wholesale reuse of the text without remuneration isn't something that the CN rights management people like. Fair use is obviously fine, so quoting portions of pieces as sources in documentation is not a problem, but re-using most or all of something isn't (necessarily or usually) fair use.
(again, not a lawyer, my words aren't gospel, don't take my word for it, etc etc)
Link wherever you'd like, of course, but the more traffic this pulls in, the more ammo I have to be able to get Adam contributing to Ars as a regular freelancer!
(edit - hi, adam!)
(edit^2 - corrections corrected. Apologies for the errors. I am just a simple caveman. Your mathematics confuse and annoy me!)