I think the OP's point was that '/' is not a mathematical divide anyways. Sure, we can remove '/' and make that a happy face emoji but I don't think that changes the premise here.
Making sure you don't divide by zero is just one of those things programmers learn... like making sure you don't derefence null or go beyond the size of your array, or overflowing... not clear to me that masking that helps, maybe the ship wouldn't strand but instead it'd run into a bridge.
Israel is acting towards its declared objectives which it views as existential: The removal of Hamas from power in Gaza and the return of its hostages. Hamas is acting towards its declared long term objectives of destroying Israel at any cost.
It's ok for you to disagree with those objectives, or Israel's assessment of threat, but you can still see how a truce that leaves Hamas in power does not align with Israels' declared objectives. If you can offer a truce to Israel that removes Hamas from Gaza and Israel rejected that then I'd support your argument but that option is not on the table at the moment (partly because it does not align with Hamas' objectives). From Israel's perspective the proposed truce neither guarantees the return of all Israeli hostages nor the removal of Hamas from Gaza.
Israel's current government is also unlikely to work towards the proposed truce because it involves releasing Palestinian prisoners which will be seen as a win for Hamas and also a potential for future violence. This is where Israel is divided internally with many (most?) supporting a truce and parts of the government working against it. But most Israelis would still see the truce as temporary and agree that Hamas' survival in Gaza is not acceptable after Oct 7th. If Hamas was to e.g. leave Gaza (like the PLO left Beirut) then many options open up for ending the war and moving forward (including removal of the current Israeli government).
Again regardless of your opinion/politics you need to see this from Israel's side if you want to be able to achieve a solution. The Ukraine/Russia conflict is similar in that you need to understand what both sides are looking for and what they're willing to concede before you can end that war. Just saying that you think the war should continue until Russia is repelled from the entirety of Ukraine, while potentially a reasonable moral position, may not be a practical one or one that minimizes the number of people getting killed. I say that as someone who is 100% supportive of Ukraine. There's the idealistic outcome and then there's reality.
It's certainly true that if Israel has no other alternatives, and under the assumption it views Hamas' survival in Gaza as an existential threat, then it will continue to use force to achieve that objective, which will certainly lead to more people getting killed. Israelis and Palestinians.
If this is the scenario we're looking at, and we want to minimize Palestinian suffering and casualties, then we should be looking at how this force can be used in the most optimal way to achieve these objectives. For example, a truce that gives Hamas a chance to rebuild its defenses and re-establish control over broader areas of the Gaza strip is almost certainly going to lead to more suffering and casualties.
I think the reality is that demand for good software developers is only going to grow. This has been the trend since the 1960's and it shows no signs of reversing. There have been periods of slowdown and reversal (e.g. dot com bust) but the trend continues.
Good software developers are a scarce resource. There's a lot that goes into the mix of making one. AI can't replace them yet. They're critical for the success of many businesses.
We were in layoff mode but that seems to be reversing. Even if we see a bit more ups and downs the trend of more technology everywhere and the increasing demand for building and maintaining all that technology is not going away. The only real game changer is AI but when AI replaces all good software developers it has replaced everyone in the job market and we have bigger worries if we're even still around.
The US public is not as supportive of Israel as it used to be but support is still broad. The opinions you're reflecting are a small minority. I would expect that democrats lost votes on their "both sides" approach here since more centrists would have move to the right then people on the left who at best can not vote in protest. Stronger support for Israel would have not only reduced Palestinian suffering in the war but would have also likely gained support for the democrats.
For example, Israel was pressured to delay its offensive in the beginning of the war after the Oct 7th attack, which likely caused more casualties and prolonged the war and it was pressured in other ways that prolong the war. There was certainly nothing like "unwavering support", e.g. there was intense pressure to avoid an operation in Rafah, e.g. with the US administration saying the population could not be evacuated, but then Israel ignored that, and the population did evacuate.
On the other hand, there is virtually no chance that the US could have forced Israel to stop the war because Israelis view this as an existential threat. No threats or measures the US would take would override that view. This is likely why Biden is not able to stop the war by making a phone call.
I think it's important for people that want the war in Gaza to end and to see less casualties and suffering to understand this calculus. Israel's and Hamas'. What those people seem to be working towards in practice is a prolongation of the war, more suffering by everyone, and possibly the election of Trump in the US.
Totally agree. Not only would a coverage guided fuzzer catch this they should also be adding every single file they send out to the corpus of that automated fuzz testing so they can get somewhat increased coverage on their parser.
There may not be out of the box fuzzers that test device drivers so you hoist all the parser code, build it into a stand-alone application, and fuzz that.
Likely this is a form of technical debt since I can understand not doing all of this day #1 when you have 5 customers but at some point as you scale up you need to change the way you look at risk.
As far as I'm aware there's never a requirement to use a specific product/technology for compliance. The standards will require processes or something very general and the way a company complies is their choice. It's certainly possible that a company will buy a certain product because it checks some compliance box but I would expect there are many other ways to check that box.
In your example the tab is strictly finger-picking over chords since that's how the song goes but some tabs are lead guitar tabs which might be sliding from the 15th fret to the 3rd fret or other things that are not strictly picked from a chord shape. They might still be "from a chord" or "played over a chord" but when you play the tab you may or may not be using that shape at that position. It's still good to know what's the context so definitely having the chord is useful.
If I'm playing a song with a clear picking pattern over chords I might just learn the chords and strum them first and then learn the pattern or often the patterns are just standard and all you need is the chord chart.
But that's not useful. So you're saying just put on a CMaj13 grip for playing anything in a scale to the OP? On your 7 string guitar?
EDIT: Also you have to be missing at least one note... CMaj7 had 4 notes + 13 ... c e g b + a (the 13th) so CMaj7/13 Add 4 ?
The OP (as I understand it) was wanting to be able to know what shape/grip to use for picking the relevant notes... I'm sure it can be done but you have to also find the position and reasonable shapes that fit the notes in the bar.
I've used a 3090 and some of the predecessors and VM/CMS. The "monitor" was called CP (control program) IIRC.
XEDIT was a great editor. There was also Rexx (and previously EXEC and EXEC/2) as the system's programming language that you could use to customize virtually every aspect of the editor and automated tasks. Rexx had integration with the editor and also integrated with the OS there were lots of these small integration points that let you do really powerful stuff. Applications like email were implemented on top of the basic OS and editor. A very unique and powerful architecture (mirrored to some degree in OS/2 later).
The ecosystem was incredible. The virtualization support in the CPU let you run a complete multi-user system with each user having a visualized CPU within one virtual CPU. I.e. it was "fully" virtualized. What's more incredible is that a lot of these pieces, like the OS, were all written in assembly. Super robust. Super clean. Amazing documentation for everything. As top notch engineering as it gets.
The full screen terminal (e.g. 327X) were part of the architecture, delegating a lot of the interaction to the terminal. Interesting enough you could poll the terminals for input which we've used for writing some games. A friend of mine wrote a library for doing that. There were also colour/graphics terminals like the 3279 and could be programmed e.g. with a library called GDDM.
Another interesting bit is that IBM shipped the full source code for everything (I think this was by default). They also had a shared bug reporting system (anyone remember what that was called?).
I have a fair bit of experience writing tests for concurrent code that uses timers on Go. We started with an open source test library ( https://pkg.go.dev/github.com/benbjohnson/clock ). It had a lot of problems. This was many years ago, looks like it's seen some maintenance since so maybe it's better? Then we tried to fix it. Fixed all the obvious bugs but still had a lot of problems using it in practice. It's not enough to just handle the calls without context of who is calling them in concurrent code. Then we switched to using gomock which ended up also being hard to use.
It's quite tricky is sort of the bottom line. It's not enough to just create fake time there's a lot more to it.
Wouldn't the deadline be now+zero for real time audio applications? If I'm building a guitar pedal (random example) ideally I want no delay from the input to the output. Any digital delay makes things strictly worse and so any jitter matters. That said, the difference between zero and very close to zero does become a moot point given small enough values for any practical purpose.
If you have a buffer that's being clocked out and your goal is to keep data flowing, the jitter is going to influence how small your buffer can be. Let's say you're producing 56Khz audio, the best you can do is produce a [sample] exactly at that frequency. If you have 1ms jitter now you need a 1ms buffer so you have delay. If jitter is small enough, like 0.1ns jitter in some SIMD calculation, then for all intent and purpose it doesn't matter for an audio application...
You don't really do these any more on a modern CPU. This is stuff I used to do 30 years ago and you might still do if you're on a micro-controller or some other tiny system. The CPUs aren't slow. Tne main problem is if the OS doesn't schedule your process it doesn't matter how fast the CPU is.
Yes. Most modern Ethernet isn't running on shared media (i.e. there are no collisions) and for the most part no packet loss as long as there's no congestion. For networks and for the CPU, when you're fast enough the jitter matters less, if the cpu or the network "takes a break" (from the application perspective), it tends to be a very short break on really fast networks or cpus. e.g. if a packet gets in front of you in 10Mbps Ethernet that's a big deal for an audio application but a packet ahead of you in 10Gbps Ethernet isn't much of a delay for audio. 1ms vs. 1us sort of thing.