I disagree. I see shell syntax as an “inversion” of normal quoting rules. Normally quoting is the default but to achieve anything special you have to use an escape. Conversely, in shell, quoting is not necessary but any special character will likely have unwanted behaviour unless you quote.
This is handy for quick scripting as a natural extension of a command line interface. A counterexample might be an equivalent script using the Python subprocess module. For a simple script, the required extra quoting overhead is not worth the trouble. For something complicated it’s essential and a shell script is no longer suitable. For something in the middle, a carefully crafted shell script (eg. one that passes shellcheck) may be the most suitable solution depending on the situation.
Both cases have their place. It’s about using the right tool for the job.
One consolation is that you can use proprietary cloud based AI to make software that you can run locally and then depend upon. As long as you ensure that the software meets the quality standards you had before this revolution in terms of (non-AI-based) maintainability etc, you are in no worse a position than you were before, and your software development is massively accelerated as long as the proprietary cloud based solution is available and without lock-in.
> Notable are the endorsements, which are balanced over all three options...
I don't think this is notable. The process requires five seconders, so you're just seeing the set of people who seconded asynchronously before there were obviously enough that others didn't bother. The culture is to avoid unnecessary noise and leave it for the vote.
Email seems like an odd choice for sensitive messaging where you're in the position to manage the technology on both ends. Private XMPP or Matrix with E2EE has better privacy properties.
That's interesting, thanks. For me this feature is mandatory, and I won't risk buying a car (second hand usually) unless I see it working with my phone first. I drove 200 miles to buy a car once and walked* away because of this. The seller acted surprised.
That's not enough. If I purchase something, I expect to rely on being able to keep it. Its value to me could well be much higher than just the purchase price.
Revocation should come with consequential damages together with the cost of recovering them.
If an attacker can do that, they could also do that with my real birthday had I used that. My birthday isn't a secret against anyone who wants to look hard enough. Therefore this method doesn't provide any kind of security against attackers gated only on knowing my registered birthday. I never claimed that it did.
I like using a date of birth of 1 January. It's plausible but also hopefully suspicious how many people seem to be born that day if others do the same.
I think this is a backwards way to set up VMs. "Installing a guest" is the wrong concept. Use a VM image pre-prepared from your favourite distro to skip that step. cloud-init is the standard way for it to specialize to your use case.
Adding contraints makes it take longer to deliver a result. I probably cannot install today's engines SDKs and related tooling for example. I'd have to write my own. Doable, and would make me a better programmer, but you won't see results for a long time.
As it happens, I do this. I have various projects burning for years and yet to be published because in my hobby time I value good engineering over results.
> For example, aerated autoclaved concrete has better structural strength, doesn't need additional insulation, completely non-combustible, and is cheaper to build.
Apparently it ages out though and becomes unsafe when it does, resulting in a scandal in the UK:
"There is nothing fundamentally wrong with reinforced autoclaved aerated concrete (RAAC) as building material or system. Many buildings from the 60s and 70s built from many materials are now having problems due to inadequate maintenance, and old age."
I'm not exactly sure what this is supposed to mean. I've never heard of this problem with regular brick or concrete structures.
Copyright law is an artificial legal construct, not a moral code.
I think appropriate attribution is a moral code, but I am not able to attribute every idea I have to all those who helped me develop the general intelligence that I use to develop such ideas.
I don't pay for my mind to absorb the world's information, either. And when I publish to the Internet, or give a talk, I also typically don't charge. Even when I publish under some kind of copyright restricted licence, that restriction has never (by law) extended to restricting transformative use that you might perform using your mind.
This idea that absorbing information requires paying a toll needs to change. It was never the case in copyright law anyway (and the courts are beginning to agree). Even if it were, copyright law was founded on the basis of encouraging creativity by creating an economic incentive. Appeal to "compensating the rights holders" therefore needs to be based on the economics, not just some principle about "rights" that never applied to this case anyway.
Placing various artifacts (eg. build artifacts) inside the source tree always seemed like a historical mistake to me. It leads to various accidents such as people checking in their credentials and accidentally bundling such files in source distributions, for example. These consequences are real.
Debian build tooling places build artifacts in the parent directory on the assumption that this is acceptable, but it then surprises people since it's not the norm anywhere else.
Perhaps this ship has sailed. But I think it's worth pointing out that if you have an option, don't design things that place things inside the source tree if you can avoid it.
Arrests seem like overkill. Ask them to stop, issue a fine, whatever. Sure I get you're asking for any enforcement at all. But hyperbole has a polarizing effect on discourse we should try to avoid, IMHO.
I've seen this kind of thing happen not through bias but because good people know good people, where by "good" I mean highly competent. They knew each other through university and other regional connections, so they happened to have the same ethnicity as one might expect from such a regional commonality. One got hired, referred another, and it cascaded. They were great to work with and highly competent, so I don't think there was bias even though it might appear that they're was.
This is handy for quick scripting as a natural extension of a command line interface. A counterexample might be an equivalent script using the Python subprocess module. For a simple script, the required extra quoting overhead is not worth the trouble. For something complicated it’s essential and a shell script is no longer suitable. For something in the middle, a carefully crafted shell script (eg. one that passes shellcheck) may be the most suitable solution depending on the situation.
Both cases have their place. It’s about using the right tool for the job.