- nsguy parentYeah, we agree on that last bit. Though technically exploding is also a "wrong result" as we saw with Crowdstrike...
- 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.
- Yeah... I understood the ask ;)
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.
I've definitely seen tabs with the chords on top, in Ultimate Guitar it depends on whoever transcribed it, random e.g.: https://tabs.ultimate-guitar.com/tab/misc-traditional/greens...
- 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.
EDIT: - https://en.wikipedia.org/wiki/VM_(operating_system)
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?).
- Rexx (EDIT: https://en.wikipedia.org/wiki/Rexx )
- 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.
[fixed typo]
- Was doing some Googling and came across: https://en.wikipedia.org/wiki/Breakout_(video_game)
I never heard this story...
- IIRC reading some Intel CPU design history some of their designers are from a CS/software background. But I agree. Software is naturally very sequential which is different than digital hardware which is naturally/inherently parallel. A clock can change the state of a million flip-flops all at once, it's a very different way of thinking about computation (though ofcourse at the theoretical level all the same) and then there's the physics and EE parts of a real world CPU. Writing software and designing CPUs are just very different disciplines and the CPU as it appears to the software developer isn't how it appears to the CPU designer.
- I think the key word above was modern. I felt able to design a simple CPU when I finished my Computer Architecture course in university. I think I forgot most of it by now ;) There are a few basic concepts to wrap your head around but once you have them a simple CPU is doable. Doing this with TTL or other off the shelf components is mostly minimizing/adapting/optimizing to those components (or using a lot of chips ;) ). I have never looked at discrete component CPU designs, I imagine ROM and RAM chips play a dominant part (e.g. you don't just built RAM with 74x TTL flip-flops).
- Obstinant can just be a nay-sayer though? Someone who isn't even trying to solve the problem their way but someone getting in the way of problems being solved at all.
I have a lot of respect for people that are confident in something who are willing to actually go and do that something, even if they're wrong. Persistence in this context is persevering through being wrong and not giving up until you figure out a way to solve the problem.
- Sure. The profiler is going to give you information related to what it is looking at. If your bottleneck is disk I/O then you need to look at disk I/O. If your bottleneck is some other mechanism that's not purely cycles then you need to look at the relevant metrics.
Your slowness is always a function of the underlying building blocks, their performance distribution and bottleneck. And sure, two 90th percentiles can make for the 99th percentile. A profiler won't magically convey the information about what sequence of operations a request is doing under the hood.
I agree that having visibility into the requests via tracing can help zoom in on the problem. But so can having metrics on the underlying systems, e.g. if you have a queue in your system you could look at the performance of that queue.
I'll admit that most of my experience is tuning for maximal throughput rather than a given percentile, usually systems with high performance/throughput yield a much flatter distribution of latencies at a given workload. A rule of thumb. I also tend to think about my "budget" in the various parts of the system to get to my desired performance characteristics, a luxury you don't have on "legacy" systems you need to troubleshoot some behaviour on where tracing also lets you get a "cut" through the stack that shows you what's going on.
- I had a similar issue recently. Someone suggested a technical solution that based on my experience has zero chance of being correct. It was said with great confidence that makes me doubt my experience. Great confidence but zero supporting details or experience. For someone observing from the side there's no way to tell who is right and my double-take doubting my own experiences can appear to make the extremely confident but likely wrong person be the right one. For someone that really knows stuff, being 100% confident on nuanced/complex issues is very hard, you're used to moving forward with 90% or 80% or 95% confidence. I.e. you're very likely right, but there are can be surprises or something you didn't anticipate. For someone confident but wrong they have like 100% confidence for something that's 0% chance of success. As you say, this is a lot more difficult when you're put on the spot, e.g. the CEO might question what's the right decision in a meeting (the king in your example.). Often there's not enough time for a deep study and even after studying a problem it might still not be 100%.
Tough situations to handle.
- Book looks very interesting.
random nit (obviously not having read the book): I would say p99 behaviour can be captured in profiling, it's just going to be the p99 of the profiles. E.g. if you sample 10,000 stack traces out of your executable, 1% of those are going to be in that p99, sort of by definition. Tracing through requests (e.g.) is useful but I wouldn't make as strong as a statement as that's the only way of understanding p99 performance based on my experience.
- In theory you can get a pretty good idea of where instructions came from in the source code though the optimizer does, shall we say, obfuscate/spread that a little bit (which is why debugging through optimized code or looking at core dumps from optimized code can be tricky- but you can still mostly do it, there's just some lack of precision in the mapping back).
Maybe the bigger problem is at what point do the profiles feed back. Since a compiler may generate many object files which are then linked to form the final binary you'd sort of maybe want to do this in the linker vs. earlier on.
I guess specifically with the kernel there's an extra layer of complexity. It looks like they use `perf` to record the profile which is cool. And then they apply the results to the binary which is also cool.