wild_preference

So, your friends list consists of married couples and kids. How are you confusing that with the overall demographics of Facebook?

Tinder used to require a connection with your Facebook account so that you could only use pictures that you've used in your profile-picture history on Facebook.

I thought it was brilliant because now all pictures have to at least pass the social proof of being one of your public profile pics. It's more trustworthy. Though they've since relaxed the requirement, probably because they didn't want to be so tied to Facebook.

It's true that you can often google/facebook search matches on dating sites. I have done that before just to get a better idea of who someone is. But that already exists.

But I think there is value in enforcing a Facebook profile linkage to a dating profile. It's hard to bullshit, and it's harder for someone to then waste your time.

I don't understand. Bots aren't that big of a deal, and it's not unlike encountering a woman who doesn't want to meet up: you find out very quickly and you move on.

Until bots are going on dates and sleeping with you, I don't see how online dating is "powered by bots." You glaze over them the same way you ignore a spam post on a forum.

Abstraction isn't free, either. The more you build, the more you're gambling that it abstracts over all future requirements.

When you're eventually wrong, someone must pay the incredibly expensive price of deabstraction. Which can become so untenable that it makes more sense to escape-latch out of it for a new business requirement. If you disagree, then shrink the deadline until you do.

What happens with technical debt is that every new/changed feature incurs disproportional costs. And all costs, at the end of the day, boil down into time. Even the best developer has the same finite resource of time as everyone else, and they are stuck choosing between the best of suboptimal solutions once bounded by deadlines.

This is why, when encountering a mess of a codebase, it's naive to conclude "wow, what a bunch of amateurs." And that's exactly what I thought at my first job out of university. Eventually I realized that software is just hard and there is never enough time. The more experienced you get, the better you are at writing code that can be changed or thrown away. But you're still only minimizing the bad, not eliminating the bad, so on a long enough time scale with enough monkey wrenches of time constraints and requirement churn, technical debt is inevitable.

Booters are cheaper than $thousands. And while it may cost someone $thousands to keep you offline for days, it probably doesn't. And even if it did, you probably want a better response than "guess we're offline now, lol, l8r" when someone chooses to spend $dozens shutting you down for a couple hours.

If DDoS protection isn't the point, what is?

I don't think it's discussed enough in our circles the various aspects of the internet that are more or less broken. Like how easy it is for anyone to take you offline. How easy it is to spoof IP addresses. How useless IP address blocking is. How we demand infinite bandwidth for a low, fixed, monthly price yet don't want to be on the hook when our toaster is DoSing our neighbor and causing real financial damage.

But at the same time we share these little haproxy/fail2ban tips that don't work under actual threat, and then we lament that people use services like CloudFlare instead of talking seriously about how we depend on the free services of large companies, whether it's CloudFlare's DDoS protection or Google's reCaptcha, to prevent real abuse.

A scary reminder of how we're only at the very tip of the social engineering / identity faking problem. An incredible amount of our systems are just based on an honor system, yet targeted attacks are so, well, targeted that these systems are slow to change.

Like how I reset my Bank of America 2FA three years ago with just my name and billing address of my card.

It's kind of like internet abuse and DDoS in a way: I see HNers recommending something like CloudFront. Yet after being on the receiving end of a dedicated attacker that was able to bleed my financials, I would never use it again. And since it's not a widespread problem by nature of being a targeted attack, people continually have to learn the hard way on an individual basis, if they even get unlucky to begin with. So there's no real widespread need to change.

Or, how many HNers unknowingly use a webhost that null routes them under attack yet never experienced that?

They're referring to monomorphization. Rust, for example:

> You might be wondering whether there is a runtime cost when you’re using generic type parameters. The good news is that Rust implements generics in such a way that your code doesn’t run any slower using generic types than it would with concrete types.

> Rust accomplishes this by performing monomorphization of the code that is using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled.

In my experience, ugly code is more a product of churn (like moving target business requirements) than incompetence.

You may have started with a nice abstraction for one case, but you don't have time to reabstract every step of the way.

Outside of the HN comment bubble, nobody uses Bootstrap. And it doesn't explain the examples in TFA.

One wheel is just too unstable. Forget ever hitting any speed on one.

Scooters and ebikes have the advantage of all energy going into propulsion instead of stabilization.

Fastmail.com has the worst I've seen: stop paying them and someone else can register your email address.

Think of the security implications there.

Well, it's not much different than cars then where people drive foolishly all the time and there aren't enough cops to catch them all.

For example, I almost never see people reserve the passing lane for going fast or passing which is dangerous. People almost never use blinkers. Except, unlike scooters, they are driving vehicles that weigh two tons and are going 65+ mph. And they even require licenses.

So that's a pretty low bar, and not very damning if scooters have some etiquette issues.

irccloud.com ($50/year) is a good option for people who don't want to run their own server. Only costs $13/year more than your solution.

Though paying money to receive messages while offline (or fiddling with ZNC) is one of the reasons IRC getting its lunch eaten by everything.

One problem with IRC is that everyone is using a different client. It's like how you can set it up so you receive messages when you're offline... but nobody else does that, so it's not a real solution.

Of course, the context here is a client that does indeed implement extra features, and you're right that a text format per message would be an interesting way to implement this: the client could simply hide those messages from the normal view and slot them into the thread system. People using other clients would just see some extraneous line noise like "Replying to <username>|<timestamp>: hello world".

For fun, notice the Chinese IIS 404 page.

http://computer-programming-forum.com/foo

My guess is that someone just wants this to rank in search engines to any degree and then boost some SEO juice off it.

I tried using old Usenet archives for a content site before and couldn't overcome Google's dupe penalty despite my own value-adds.

Try to register.

If you can agree that intelligence is just an information processing challenge instead of a magical god-given treasure, then general AI is inevitable.

Though note that you couldn't come up with an argument against the future of AI development in six points. They were all independently irrelevant, like denying future medical breakthroughs because doctors didn't wash their hands 100 years ago. Your points are all distracted, like suggesting Elon Musk's tweeting habits today doom all future humans from ever reaching Mars.

People already walk in them. Might as well bring another vehicle into the mix to keep those pedestrians out!

Interesting that the keys now have a little skirt to apparently stop particles.

Though I had to use my 2013 Air recently while my 2017 MBP was in the shop (keyboard aka whole front panel + battery replacement) and wished they'd just kept the high-action keyboard that could weather the grime between cleanings.

Now apply what you said to the mess of style.css that the churn of developers before you has appended to on an as-needed basis.

Except nobody has the time nor role to organize and maintain your project's CSS like Spectre.css' developer could. And nobody wants to because CSS accumulates technical debt rapidly. Everyone opens up that file just long enough to do what they need and then they get out before the house of cards falls down. To avoid adding rules that break existing UI, they add a new class and a new rule just for that class to be safe.

And let's say you're a CSS master. Which doesn't help all that much beyond being able to maneuver in the mess that was created. The above paragraph happens in projects where everyone knows CSS just like a project can evolve into spaghetti code between capable developers over the terrain of changing requirements. And being a CSS master equips you to understand a CSS framework too, so I don't understand why you keep alluding that CSS knowledge makes frameworks obsolete. I'd rather read organized framework code than whatever the bespoke clusterfuck people end up when left to their own devices under the constraint of time and deadlines.

Frameworks help contain complexity. They aren't just a tool for beginners and non-professionals.

You're making the wrong assumption that messes in programming are only made by not knowing the language. I remember thinking the same thing at my first job out of uni, but I was quickly straightened out at my first job when I realized that being good at a language meant almost squat against the real reasons: real world applications fighting between churning requirements, business concerns, and scarce developer resources like time.

Frameworks aren't at odds with knowing CSS or any other language. You're missing the point with "CSS isn't hard!"

And you're wrong. CSS is incredibly hard to maintain. It easily becomes an append-only list of rules. Medium.com for example hired a team a CSS developers including a co-creator of Bootstrap just to work full-time on its CSS.

This is a good example of developer hubris and the HN trope of "it isn't that hard, why don't other idiot devs just do <X>? It must be because they're incompetent." I'm not convinced you've drunk your own Kool-aid in production on a non-trivial project. Because then the trade-offs would be obvious to you and you wouldn't think one is better.

Can you seriously say it's hard to distinguish the ads from content here with a straight face?

Bootstrap 3 docs had ads too.

I didn't think any of them looked as good as Spectre.css for my project.

Next?

Well, given that WHOIS information is sufficient to start a social engineering attack, people are rightfully concerned.

IRC: No code-block formatting. Can't even receive messages when you're offline, out of the box. No message delete/edit. No built-in file hosting, must upload elsewhere and link it. No drag-and-drop. No real ergonomics in general. Way behind on community-building/-management features. Only particularly liked by the sort of person who considers tweaking their .conkyrc as a Friday well-spent.

I hang out on freenode every day. But I have higher expectations of chat in 2018 when it comes to what I would choose for an actual organization. So does everyone else.

IRC isn't blowing anyone's mind. Especially that first time they try to reply to someone but their message is never received because the other person closed their laptop.

One reason is to bypass the sandboxing requirement of the App Store.

And once you're off the App Store, users won't be nagged to update your application, so you're responsible for getting your users to update all by yourself. At which point some form of over-the-air update is more ergonomic than making users hit your download page to pull in the latest version.

The 12-inch Macbook has an F-key row which is what gets replaced with the touch bar.

I only estimated that they were going for 100% laptop coverage. But I can imagine a future where Apple keyboards have a touch bar option. Though not as important because Macbook touch bar penetration can drive developers to integrate with it, alone.

At which point it's not much different than gestures when it comes to answering your questions. What happens when you use a Logitech mouse on your macOS desktop instead of a Magic Trackpad?

Note that touch bar integration cannot have unique features, so it's never required. The challenge is to get developers to care about it which is the prerequisite for users to care about it.

I tried to address this in my parentheses, but Karabiner specifically lets you bind CapsLock to both: Esc when tapped alone, and Ctrl when held down in combination with other keys.

And your post also answers you sibling comment: Ctrl modifier is useful outside of just Emacs.

Try it out. I believe the API changed in the macOS release before Mojave, so they relaunched Karabiner under the name Karabiner Elements. This option is under the "Complex Modifications" tab.

If I was writing a list of tricks for macOS power users to try, this would be my number one. Up there with binding a global show/hide hotkey for iTerm (I use Ctrl-Space, thus CapsLock-Space).

Consider mapping CapsLock to Esc (and Ctrl when long-pressed) with Karabiner. I haven't used my physical Esc key since 2014 or something. Might help with your issue.

Hate it or not, Apple has to make it relatively commonplace if they want macOS apps to bother developing for it instead of ignoring it. Their short-term goal is 100% of MBP users, and surely, eventually 100% of all macOS laptop users.

Keeping it optional indefinitely, then, defeats this goal.