It feels like any platform that allows for one-way initiation of a conversation is bound to increase in spam as the platform grows in usage (phone calls, email, SMS, various social media, various messengers, etc.).
Do any platforms require that both parties add one another? (And/or allow for restricting an account to such a mode)
e.g. if user123 and user789 wish to communicate, then user123 must add/contact user789 AND user789 must add/contact user123. Until both do so, then nothing happens.
It's more work to legitimately establish contact with someone, but that seems like it pales in comparison to the effort produced by spam/scams.
Same thing with verifying identities. In order to actually establish proper contact with someone, you need to communicate with them via some outside means (ideally in person) in order to establish the connection. Requiring both parties to enter/scan some ID/code/whatever seems like it would only facilitate proper verification (though not guarantee it, of course).
I'm sure that I'm missing something, though. I assume I'm just not familiar enough with these platforms and that some/all of them provide such a feature. It's just odd to me that spam sounds like such a problem when it feels like the above solution would be highly effective and simple to include.
Small correction: you can put it almost anywhere. If you have a quoted search, you need a space between the bang syntax and the quotes, even if the bang syntax comes after.
For example, if you search for ["foobar"!g] (without brackets), you will not be redirected to Google, but you would be if you did ["foobar" !g].
In the past few years, I've gradually come to realize how much batteries (in anything) can actually cost me in things other than just upfront monetary price.
For example, even if a corded $THING costs as much as its cordless counterpart, with the cordless one, I have to think about things like:
- Charging schedule
- Whether the device is draining battery when I'm not using it
- How long before the battery needs replacing
- How much a replacement battery costs
- How to dispose of the battery when it needs replacing
- Whether I'm even able to replace the battery
- How well the device functions without a battery or with a dead/dying one
Without going down that particular rabbit hole, things like right to repair attempt to help with some of those things. However, the corded version avoids all of them categorically.
So it's not that I'll never buy a battery-powered $THING again. Just that I really try to consider all of those "hidden costs" before choosing instead of just rather-blindly going with the battery-powered version (like I did before). In other words, having a battery installed in a device really needs to provide a consistent and realistic value for my personal use case before I'd choose it over a corded version.
If we ever create a battery with effectively infinite recharge cycles, then my stance might change, but I'm not holding my breath on that ever happening. For several reasons.
If it moves with me (drill, impact wrench, etc) it should almost certainly be cordless. If it is stationary (table saw, vacuum, etc) it should almost certainly be corded. Some tools are both.
I've done well with a corded drill (we only use it occasionally in the house/garage near outlets). My 10yo cordless battery packs died and the new LiPo batteries (same vendor) have a different form factor.
I will preface everything with: if you don't see yourself getting value out of vim... don't use it. It's that simple. Vim has been one of the greatest things in my life for most of my life, but that doesn't mean it will be for you. Everybody is different.
Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.
I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.
First the technical implementation
Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.
To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.
Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.
A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:
au BufNewFile,BufRead Jenkinsfile setf groovy
None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]
Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.
Getting a bit more philosophical
If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.
In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.
The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].
The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.
Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.
[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.
[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.
[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".
[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.
Resins aren't always perfectly still when curing. Especially if you need large volumes of the stuff. Not to mention, time becomes a factor pretty quickly. The faster the cure for the resin, the more exothermic it is (along with higher risk of thermal runaway), which increases the chance of shifting.
Not to mention, you'd also need a really effective solvent for resin that doesn't also happen to be a solvent for whatever the mosaic is made of. Perhaps the mosaic is made of resin beads.
All that being said, it's virtually guaranteed that a valid attack on these methods exists. There's no such thing as perfect security. It's always a case of evaluating your threat model to make security attempts that thwart a constantly moving array of types of attack.
I'd go for injecting non-electrically conductive liquid that can both freeze and evaporate, freezing the liquid, remove electronics, tamper, replace, pull a light vacuum and air to remove liquid/allow evaporation
As someone from NC with a LOT of family from eastern NC specifically, I'd like to provide an addendum to "bless your heart".
I see it frequently cited as always meant sarcastically/disingenuosly. It certainly can mean "screw you", "go away", or "... so much fail".
However, if there's one thing people should understand about southern/NC etiquette, it's that passive aggression is the primary form of aggression. There are plenty of southerners who would never tell you to GFY straight to your face. That doesn't mean they aren't thinking that and trying to say that, though. Perhaps even with a "bless your heart".
Given all of that, "bless your[/their] heart" is absolutely to be taken at face value about as often as it shouldn't. That level of plausible deniability provides the highest level of potential passive-aggressiveness.
I can't speak for absolutely everybody, but at least if someone from eastern NC says "bless your heart", they could mean anything between "GFY" and "I'm so sorry that happened, please come to my house so that I can shower you with hospitality". You might never know which they meant, and that's intentional.
I'm not at all condoning the behavior of corporations, but the corporation itself is no more capable of having malice for you than a tornado or meteor. A corporation's appearance of hostility is a byproduct of its primary function to acquire things-that-store-value.
That doesn't preclude the people within the corporation from having malice for you, though.
Not necessarily store value, but being able to acquire or hire things and people that allow more value to flow through the company. Which are things other people want so much they'll pay for them.
You're alluding to the benefits of building interfaces to what people are already familiar with, but touchscreens are still a learned behavior. There is nothing about our physiology that affords anything with a touchscreen beyond touching it.
Touchscreens add flexibility (and lower production costs), but that flexibility comes at a cost. There is no universally agreed-upon usage for them. Certainly not to the degree that "[all] people" understand them the same way. It's all too common to run into a touchscreen-based interface that you haven't seen before and simply not realize you were meant to drag that one element, tap another, or long-press something. Discoverability can be useful, but that quickly loses its value when operating a vehicle -- at least beyond its entertainment system.
Buttons, knobs, wheels, sliders, and levers all have physical characteristics that signal some use. Keep in mind that those can also be (ab)used incorrectly! For example, imagine a knob that you shouldn't turn but must push or pull only. Or perhaps a button that you must twist.
It's the same reason we did a slingshot maneuver rather than just point a rocket straight at the moon: leverage.
Metaphorically, you use time as a fulcrum to exchange a larger total travel distance for not dealing with as much gravity head on.
If we want to go to Mars, it makes sense to establish a moon base that we can use to store fuel and other supplies. Rather than having to escape (as much of) Earth's gravitational field and then head to Mars immediately after, we can utilize what we've gradually built up on the moon.
I was under the impression that the aero braking greatly reduces the amount of fuel required to land on mars vs the moon, and due to this the Saturn V had enough lift to put a crew on mars.
If Apollo-era hardware can get to mars, why rendezvous at the moon?
His point wasn't anything specific about landing on the moon or even the details of the mission. At least not the main point from what I can tell.
He had the opportunity to stand in front of involved decision makers and demonstrate to them that they were not communicating well. At all. And that lack of communication made it seem impossible, to him anyway, that they could even come close to landing on the moon in the planned timeframe without some major changes to how they worked.
He chose poor examples that didn't help his point at all (from my opinion).
I didn't get his point, other than - copy the first landing, you have the manual - and that seems like he misses the point. Maybe I got that impression because all the counter arguments he reasoned were made from the apollo lens, but in the end I didn't hear any solid argument from him, only a "teaching moment" from somebody that doesn't understand the context.
What was really impactful for me was when he showed the comparison of the Apollo mission plan image / diagram and compared it with the current one. He didn't even say much he just silently let the audience look at the two side by side, and it scene speaks for itself.
I also think the fact that no one could answer how many refuelings were needed or planned for the mission warrants attention, as mentioned by other commenters.
Do any platforms require that both parties add one another? (And/or allow for restricting an account to such a mode)
e.g. if user123 and user789 wish to communicate, then user123 must add/contact user789 AND user789 must add/contact user123. Until both do so, then nothing happens.
It's more work to legitimately establish contact with someone, but that seems like it pales in comparison to the effort produced by spam/scams.
Same thing with verifying identities. In order to actually establish proper contact with someone, you need to communicate with them via some outside means (ideally in person) in order to establish the connection. Requiring both parties to enter/scan some ID/code/whatever seems like it would only facilitate proper verification (though not guarantee it, of course).
I'm sure that I'm missing something, though. I assume I'm just not familiar enough with these platforms and that some/all of them provide such a feature. It's just odd to me that spam sounds like such a problem when it feels like the above solution would be highly effective and simple to include.