My least favorite of that eras Gerald Genta designs. The original Royal Oak is comparatively far more attractive. Both are outdone by the 222 (different designer though), but it's all subjective.
You could at least disable Active Desktop to dethrottle your PC. Meanwhile, my work W11 PC has a second+ delay for explorer right click and there's nothing I can do about it.
You can actually restore the old right-click menu on W11 with some regedit.
Not ideal in any way, and a setting would have been a much better way to toggle this, but it is an option.
I've found that ( at least for me ) that was caused by some entries doing some checks before showing up. Getting a context menu editor and removing some of them can help.
Doesn't matter, it's a shit user experience and Microsoft's fault for putting the onus on the user to fiddle around at that level, rather than putting a hard, very low limit on how long shell extensions can hold up the context menu before they're banned from it.
> rather than putting a hard, very low limit on how long shell extensions can hold up the context menu before they're banned from it.
Do you want the users to blame Microsoft, all Microsoft employees including catering and cleaning workers, and Gates personally? This is how you make the users blame all the before mentioned but not the culprit.
Oh, I'm not trying to defend Microsoft in any way. Everything they make has been going downhill faster and faster.
Just suggesting a possible way to work around it.
This only lasts until dark patterns can be inserted that disrupt the ease of use that agents are currently providing. If I can't force the end user to watch unskippable ads or trick them into spending money on a service they don't need, what are we even doing?
I recall stuff like the Intel icc compiler being expensive and desirable, and things like client access licenses, hardware licenses (to allow using non-trivial amounts of RAM and multi-processing) and support plans for proprietary OSes being rather expensive. Consulting a SCO Unix price sheet from that era, a license that allowed 150 users and up to 32GB of RAM was $10k.
Prices also varied around OS features used. Vendors loved to nickel-and-dime you (separate *-user client licenses for file services, print services, remote access, etc), generally to drive you towards bigger packages that seemed like a better deal.
Which is why you take the time to put usage docs in the repo README, make sure the script is packaged and deployed via the same methods that the rest of the company uses, and ensure that it logs success/failure conditions. That's been pretty standard at every organization I've been at my entire professional career. Anyone who can't manage that is going to create worse problems when designing/building/maintaining a more complex system.
Yah. A lot of the complexity in data movement or processing is unneeded. But decent standardized orchestration, documentation, and change management isn't optional even for the 20 line shell script. Thankfully, that stuff is a lot easier for the 20 line standard shell script.
Or python. The python3 standard library is pretty capable, and it's ubiquitous. You can do a lot in 50-100 lines (counting documentation) with no dependencies. In turn it's easy to plug into the other stuff.
People have been sounding the alarm about excessive water diverted to almond farming for many years though, so that doesn't really help the counter-argument.
> Armed civilians with their puny little guns and little organization are right out as soon as any part of the military joins a fight, that's why I only mentioned the latter to begin with.
We have several recent real-world examples of that not working out for the military. Assuming like minded people wont self-organize is a bad starting point, and jets and tanks have a tough time doing things like enforcing curfews. That's also ignoring that such a scenario would involve portions of said military force joining the civilian resistance, including those in leadership positions.
Besides, I've always hated this argument, because why fight the military when they can just target the politicians directly.
> We have several recent real-world examples of that not working out for the military.
Only when the military is not serious since they are not fighting for their own lands and the civilians are backed by another country. When the military is fighting civilians in its own homeland the civilians stand no chance unless they get massive help from foreign powers.
> Besides, I've always hated this argument, because why fight the military when they can just target the politicians directly.
Even if you do that its still the military that gets to decide the next leader, killing their leader does not lead to democracy. Nazism didn't end with Hitlers death, it ended with the country being taken over. Oppressive Communisms didn't end with Stalins death etc. There are always enough likeminded people that you can't end a horrible reign just by killing the leader.
Having encountered this spread across our orgs greenfield codebases which made heavy use of AI in the last 90 days: Restating the same information in slightly different formats, with slightly different levels of detail in several places, in a way that is unnecessary. Like a "get up and running quickly" guide in the documentation which has far more detail than the section it's supposed to be summarizing. Jarringly inconsistent ways of providing information within a given section (a list of endpoints and their purposes, followed by a table of other endpoints, followed by another list of endpoints). Unnecessary bulleted lists all over the places which could read more clearly as single sentences or a short paragraph. Disembodied documentation files nested in the repos that restate the contents of the README, but in a slightly different format/voice. Thousands of single line code comments that just restate what is already clear to the reader if they just read the line it's commenting on. That's before getting into any code quality issues themselves.
It's been around for over a decade at this point, so I'd say it's as likely to disappear as Ableton Live at this point. Bitwig was made by ex-Ableton engineers and outside of some of the more niche features, they're similar enough that anything you learn about Bitwig is transferable to using Ableton Live. Much more so than trying to move to one of them from Reaper, for instance. If you depend mostly on 3rd party plugins and less on what's built into the DAW, then they're effectively the same outside of simple navigation quirks unique to each.
I have active licenses for both and have used both for personal projects. I find Ableton to be slightly faster to navigate, probably because I've been using it for longer. If manufacturers of high quality multichannel interfaces had better Linux support, I'd migrate fully to Bitwig.
