I continue to fail to see how you reach certain conclusions, but I don’t see any value in pursuing this discussion further. Apparently based on our individual experiences that seem to have lead to or exacerbated some biases, it seems that we see things so differently that I can’t even tell whether you are or believe that you are arguing in good faith. To be clear, I am not on the opposite side of some debate with you; I am not in favor of riots, defunding police forces, or anarchy. I continue to assert that you have not provided sufficient evidence to support your original claim. I could give four concrete examples from my personal experience that directly conflict with your perspective but not a single example of an officer helping me. That does not mean that officers don’t help or intend to help, I just question the ratio of their motivation. I don’t believe that my experiences are unique and there are constant reports of various forms of abuse by police. Probing further, I believe you have made additional invalid points that I don’t care to refute, especially as neither of us is able to prove anything about almost any perspectives expressed here. We simply disagree to the point that we apparently find each other’s statements to be nonsensical.

Again, the training materials are irrelevant to the motivational outcome evidenced by officer behaviors. Repeating your statements and swearing does not support your argument. In fact, I believe that these tactics work against you in the general public eye. Swearing is evidence of a loss of control, often due to frustration, where frustration is often part of learning. Argumentum ad naseum leaves the impression that you don't have better supporting arguments. I read your comments the first time and there's no point repeating them, except maybe for your other readers, as you stated.

That being said, you have not effectively countered any of my arguments or evidence, nor your new claim that any officer action that doesn’t align with your perspective is an outlier. I am not referring only to my personal beliefs. I am referring to my experiences with officers as well as evidence available to the general public that contradicts your statement that “officers do generally want to help people", which is supported by common reports of police misbehavior, my personal experiences with officers, and research such as the Stanford Prison Experiment. You also used the weasel word "generally". That being said, you have achieved your goal of argumentum ad nauseam/infinitum, as I do not care to participate in this particular exchange any further, as you provide no new facts or evidence.

> And the police and military include the concept of illegal orders into their training as a result.

I’m curious if you think the military always follows only “legal” orders, or if any illegal orders have been followed by the military in recent years (for example, attacking boats around South America, or specific actions such as apparently targeting a girls’ schools and wedding in the current Iran conflict, as well as attacking non-military equipment such as oil facilities, and of course destroying clearly civilian resources as well). Even if there is evidence of drug trafficking on these boats, that does justify the USA murdering all on board, especially the double-tap event. The capture of Maduro is also questionable, as are the assassinations of leaders in Iran. Or are contractors (merceneries) and USA TLAs allowed to carry out what would be illegal orders to the military?

> I could do a proper debate, its just that slashdot is not a venue worth much time.

Note that your posts on this site and in this thread often do not evidence this supposed belief of yours.

But I completely agree with you; I mostly waste time here for the entertainment value (I do like to argue!), not because I expect to actually influence someone’s perspective, especially one such as yours or anyone agreeing with your comments. In reading, I am mostly here to learn, but it is frustrating to see falsehoods and illogical arguments. We should all simply stop responding to the rage baiting on both sides, as it only sharpens divides. For this reason, I try to discuss logic and critical thinking rather than using bad faith argumentation tactics, spreading falsehoods, insulting people (though sometimes I have something like Keyboard Tourette Syndrom).

> my comments are sometimes oriented to the more rational reader that is not actually speaking up.

I have the same objectives as well, but maybe confirmation bias applies in any case where anyone agrees with either of us. And I really doubt that either of us is convincing anyone that doesn’t already agree with us to change their perspective. Basically, we’re all just shouting into the social media void to egotistically hear the sound of our own voices, thinking that we may actually be reaching a wider audience. I don’t have anything to go on other than what I’ve read, seen, or experienced myself, which does not support your conclusion.

My point was that cadet training materials are not evidence in support of your assertions that officers generally want to help people. Instead of countering my argument, you simply repeat yourself and then make another unsubstantiated claim ("Its not a career you go into otherwise."). This appears to others as argumentum ad nauseam/infinitum)

Additionally, an individual's reasons to chose a career do not necessarily dictate motivations behind behaviors afterwards. Also, I would suggest that most people chose careers for multiple reasons, not a single reason. Police have a well-documented history of supporting each other over the public at large, which my personal experiences confirm. Consider also studies such as the Stanford Prison Experiment - people given undue power over others often gravitate towards its abuse.

Every time you I see you in discussion, your arguments don't appear to be logical and you don't accept when others point out facts and make logical arguments that counter your statements. If you actually believe the things that you write, it might be in your best interest to question some of them when others point out your bad faith arguments, flawed logic, and clear falsehoods. This could improve your debate skills. It would probably be even better to admit such errors to others, which would increase your potential credibility.

Police training programs are not actual evidence of anything that would support your argument that officers generally want to help people. Training programs and police policies dictate neither officer thoughts nor actions. For example, pilots are taught not to crash planes, and there are policies requiring go-arounds, but a pilot recently crashed a cargo plane in violation of both. Goals != outcomes.

> officers do generally want to help people

Citation needed. This has absolutely never been my experience more than ten interactions with different police officers. They're there for the money and the power and to protect each other first, whatever that takes.

I definitely agree that “AI” is extremely valuable for coding, but it takes a qualified person or team to oversee it. I certainly don’t believe in vibe coding or complete app generation. Along with preliminary architectural advice (sparring partner), I would tend to use it for relatively small pieces with direct oversight by a developer. The prompting here is critical.

One concern is that “AI” could actually lower the sale value of software, which could become more of a commodity or even something where people without any background can build their own applications. This would seem to work against any vendors using these systems, reducing their profitability and hence their ability to invest more in “AI”. Microsoft and Google could be the winners here, as their other product lines generate revenue (and data) that could support further AI investments. Anthropic and OpenAI don’t have those other product lines, and I don’t even care to give a stink about SpaceX AI. Another concern is that without that qualified person or team, software generated by “AI” could have serious security and other defects.

Maybe a bigger issue is that software development is only a fraction of the market that these systems claimed they would soon dominate. That complete addressable market is what investors thought would support the data center investments and potential high valuations. Even if they could address that market, the investments only really makes sense if there is little competition, which would basically mean a single cloud vendor and not much use of local models. That doesn’t seem to be the trend, and again works against Anthropic.

I don’t claim to be an expert on any of this; just opinions. In my experience, business strategy along with sales and marketing tends to be as important or possibly more important than product.

> It remains to be seen if even using their models can be profitable

Whether or not he stated the reason for the slowdown honestly (which don't think anyone should believe, and even the Coxon departure could have been staged), then one concern is that use of AI (cloud providers, specific models) might only be profitable or be maximally profitable only for bad actors, for example hacking systems for financial gain or other purposes.

The much more likely explanation seems to be that they can't deliver on expectations they've marketed, resulting i potential investor lawsuits, and that they could be held responsible for what their software does or what others do with it, and that they don't have a viable business model in any forseable circumstances (especially considering models that run locally) and can't keep the required chips completely off the reasonable market forever, especially to support trillion-dollar valuation. In other words, they may have missed their IPO opportunity, and this may even be some attempt to get it back.

I have definitely learned and otherwise benefited from shellcheck, but it's not enforced the way a compile or even pre-run complete syntax parse would be, so too easy to skip without a supporting code management process. There's also bash -n, though I have never used it, and nothing would force one too.

Your point about variables that contain lists is almost reason enough to avoid shell scripting altogether. The requirements and syntax for various forms of quoting (such as backticks and equivalents) can be a challenge as well, specifically with nested statements. This seems to suggest the use of variables, which just raises the problem of using spaces to separate entries in lists of things that can contain spaces. These issues make shell code more difficult to write, read, and maintain. I've never actually seen a good solution to both problems and I guess future generations will be dealing with the fallout as long as computers exist. Personally, I also like curly braces for code blocks, which for me is another point against shell (and I guess python too).

My conclusion would be to minimize use of shell unless one can justify it with and against the points raised in this thread, which seems to align with your original comment “but why?”.

Random note while we’re on the topic of shell scripts: thirty years ago when I was still writing C and C++ I used to write and maintain a lot of shell scripts for what I think we would agree are relatively appropriate uses. At that time I really preferred csh (a bit more like C) for scripting and tcsh for interactive shells, but sh is just too ubiquitous to consider alternatives now and bash addresses much of what csh and tcsh did.

What any of this has to do with AMD pushing rust into the GPU stack is beyond me.

I think we agree. At some level of complexity, shell is definitely the wrong approach, especially for anything that should have tests, reusable code, compile-time error detection, strong typing, efficiency, and so forth. But for simple things like converting flacs to mp3, most of the CPU is going into the conversion, not the process spawning, the logic is pretty straighforward, and there's not much to test. Along the way on that project, the AI must have suggested that I also do some visualization of the media library, because I see a script that does some generates visualizations in that code repo - I used shell just because I was already writing in shell. I also used an AI to write a relatively lengthy video/image slideshow script once, but again it's mostly just parsing command line arguments, interrogating a file system, and calling command line tools that do all the real work. I don't know python. If it's simple, I basically prototype in shell and then if it gets long or needs logic for which there is no command line tool I would probably try to port to rust, but at that point I'm generally out of my current programming depth anyway and creating more risk. So maybe .bashrc and anything that's just basically just calling command line tools makes sense, but anything more than that belongs in a programming language rather than a scripting language and with a real programmer. My point was more that the AI was pretty helpful in the process, though maybe it also should recommend an alternate language at some level of complexity.

Sorry, one more reason: for things I want to call from .bashrc. It helped me with this one that removes duplicates from history and sorts it so that latest commands appear last (YMMV). I could probably do this with any language, but the shell tools made it easier, and an AI gave me pointers. shopt -s histappend

export HISTCONTROL=ignoreboth
export HISTSIZE=10000
export HISTFILESIZE=10000

HISTFILE="$HOME/.bash_history"

if [[ -z "$HISTFILE" || ! -f "$HISTFILE" ]]; then
echo "Error: HISTFILE is not defined or does not exist. Cannot clean history." >&2
return 1
fi

temphist=$(mktemp)

nl "$HISTFILE" \
| sort -f -b -k2 -r \
| sed 's/[[:blank:]]*$//' \
| sort -f -b -k2 -r -u \
| sort -n \
| cut -c8- \
| sed 's/^[[:space:]]*//; s/[[:space:]]*$//; /\([^[:space:]]\{1\}.*\)\{8\}/!d' > "$temphist"
mv "$temphist" "$HISTFILE"
#history -r
alias hb='history | tac | bat -l sh'

Note Slashdot removed indents and I don't care to fix that, and that AI can also help create and decipher regexes.

I usually use shell scripts just to cobble existing commands together and add minor features, sometimes mainly from looking at history, or when she'll functions feel too long for .bashrc or whatever. I use it because I know the syntax already, and the man pages are convenient, and there's no compile, and they're pretty easy to extend. For example, convert all .flax files in all subdirectories to .mp3 and replicate metadata to them - easy in shell, not sure what other language would be easier, less code, and/or better performance. I agree that anything much beyond that is probably better off as a program. Some sysadmin made me convert shell scripts to Perl years ago to reduce "expensive" process forks and I think that language is a mistake, though it arguably has similar features. Back then, fork and db connect were two relatively expensive calls.

Pretty good at shell scripting too. Very well-documented.

Years ago I used an LLM to generate most of almost 10,000 lines of rust, generally in small pieces. I was impressed. There were certainly issues, but I think those were largely issues with rust, specifically crates (too many options, documentation not always perfect or complete). From my perspective, rust is rather complicated, especially the crate issues. I think the AI did about as well as it would with any language. I ended up in a few loops ("do this, ok that didn't work, do that, ok that didn't work, do this again, no do that again"). I got it to work, but it definitely took some human wetware as well as trial and error to solve those problems. I assume it's better now. At worst, the AI makes it easier to learn about rust and crates. Rust is rather verbose, so code generation saves a lot of typing and potentially typing errors. I never maintained the code, which was just a proof of concept. I felt like the LLM didn't have a great understanding of abstraction in general, though that is probably not specific to rust.

I guess it should have made the suggestion to a limited number of devices, which could have benefited everyone. It could have used the alternate road size and the fact that there was a stop sign at the end (I think a T intersection, not a four way - which was likely a major root of the problem) to predict the outcome. I assume that after it noticed that traffic was piling up in the alternate route, it stopped recommending it, after some threshold, such as comparing estimated travel time on the original route despite the jam. It could have used average jam clearing time information. So there may be a data availability issue, as any algorithm would need relevant data, not all of which may have been available to it. This was probably ten years ago and I'm just wondering if there may have been any improvements after incidents like this, which likely wasn't the only one. I'm also curious what other kind of incidents such an app may create. Of course it's possible that many or even most of these people weren't using the app, and weren't sending their individual vehicle information to the server, but some were sending speed information. Maybe they could access flock/axion cameras!

I wonder if you would get the same experience with chromium as you do with chrome. I avoid chrome. When it stalls, I wonder if it's sending data back to the mothership, or checking for updates, or what the heck it's possibly doing. Actually I often have this question when there is any lag in any software, like it's trying to resolve a deadlock or something. What else could possibly consume so much cpu or network or whatever (with time as a consequence)?