dahauns
It really pains me to be that cynical, because I do find their products incredibly fascinating and inventive. But for anything but their lowest-end toy products the design aspirations - and boutique price tag - clash hard with the reality of their quality track record.
I know I'm a rather late here and essentially just ranting a bit while waiting for github to finally do as it is told, sorry :)
But that's exactly the (frustrating) issue - as I've laid out in another post - no, they don't work as well. It's not about others being better in every aspect (yeah, they usually aren't), but about expected baseline features that are simply missing.
(And to be honest, I've become a bit jaded regarding the resulting discussions :) No, that thing doesn't just suck in general. No, it's not impossible. It's Apple's implementation. External Display Support flashbacks incoming ;) )
I do not have to that even with my ~30€ JBL buds.
This statement only has any merit if your usage pattern is 100% limited to Apple devices, otherwise it falls apart.
It would be fine if they fell back to "at least as good as the competition" in a mixed use case, but in the mixed case they are worse than what even low-budget BT buds often offer (no BT Multipoint, no ear recognition, etc., hell, not even a battery level over BT...and even pairing/reconnect is often a crapshoot reminiscent of the state of BT Audio 10-15 years ago). It was honestly a really disappointing realization.
The "office building" setting meant resticted areas, sure, but it features TONS of reflections - especially transparent reflections (which are practically impossible to decently approximate with screen space techniques).
Oh, and: The Northlight Engine already did more than most other engines at the time to get "90% there" with a ton of hybrid techniques, not least being one of the pioneers regarding realtime software GI.
It's about having a high degree of systematization and standardization and detailed guidelines around command structure and behaviour. The same with parameter naming and handling. About actually being able to work with typed data at input/output/pipes instead of only raw bytes, with all the benefits that entails (and a "standard library" of cmdlets/modules liberally making use of that). And so on. Having the whole .NET runtime available as a first-class citizen if needed is a nice bonus as well.
Don't mistake lack of familiarity for obtuseness.
$file = Get-ChildItem "C:\some path\having spaces.txt"
Write-Output $file.DirectoryName
Write-Output $file.Name
Write-Output $file.BaseName
Or if that's still to verbose: $file = gci "C:\some path\having spaces.txt"
echo $file.DirectoryName
echo $file.Name
echo $file.BaseName
People should really get over their aversion against powershell.Just because it's the mess we are all intimately familiar with, doesn't make it less of a mess.
Weeell...here's the thing. Erm. You didn't push through to the end. You just got the "bad" ending.
The game does very much have a proper ending, and reaching it is surprisingly straightforward.
You just have to beat it twice.
https://github.com/eu-digital-identity-wallet
Everything's very much WIP, but it aims to provide a detailed Archictecture and Reference Framework/Technical Specifications and a reference implementation as a guideline for national implementations:
https://github.com/eu-digital-identity-wallet/eudi-doc-archi...
https://github.com/eu-digital-identity-wallet/eudi-wallet-re...
https://github.com/eu-digital-identity-wallet/eudi-doc-stand...
You'll find several (still evolving) Technical Specifications regarding ZKPs (including a discussion area) in the latter.
...erm.
To adress the elephant in the room: Who exactly is supposed to be verifiable to never have looked at the original source? You or the LLM?
Works just fine here (1920x1200 125%, 4K 150%, 1080p 100%).
In my (unfortunate) experience, DateTime/Timezone handling is one of the things most prone to introduce sneaky, but far-reaching bugs as it is. Introducing such a behaviour change that (usually) won't fail-fast, will often seemingly continue working as before until it doesn't and is deceptively tricky to debug/pinpoint/fix ist just asking for a fast lane into chaos.
And even with JS going the extra mile on backwards compatibility, I don't think most other languages would introduce that kind of breaking change in that way either.
TBF, I felt so perfectly trolled with this one I couldn't help but chuckle... :)
The model has worked well for many decades for a 100 billion$ revenue company like Bosch, good to see others taking a cue from them.
(Also goes to show that even constructs like these are not safe from corporate fuckups - see the emissions scandal...)
I really like C#, but I wouldn't go that far - unions are at least on the horizon, but I've sometimes come to miss the power and flexibility of TS's structural typing...(And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc :) )
Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy. (Although admittedly, I'm not really up-to-date on the current state of VS in day-to-day work)
But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Music actually worked quite good regarding positioning (and yeah, to get that kind of precision from speakers they'll have to be well positioned, room calibrated and any strong flaws in room acoustics corrected, otherwise phase info is all over the place and it gets as muddled as you describe) - but there still was noticable coloring of the sound that didn't go away after recalibration. And TBH that's more important for me with music.
Where I sadly wasn't blown away was movies with full Atmos - especially height channel stuff I would have hoped to be significantly better than old-school HRTF...but it wasn't really (well, apart from the tracking, of course, which is cool).
The usage scenarios though...well, basically everything not an AppleTV 4k I can connect to an AVR, i.e. BluRay, TV/SetTop boxes, HTPC, and my personal biggie: any kind of gaming device (including the aforementioned PC). From what I've read, at least the app compatibility with spatial audio on ATV4k has gotten better ('bout time, Amazon!), but several european streaming providers still don't seem to work (e.g. Sky, Dazn) Spatial audio on the go is admittedly not a priority for me, though
But Java was the high-level, GCed, application development language - and more importantly, it was the one dominating many university CS studies as an education language before python took that role. (Yeah, I'm grossly oversimplifying - sincere apologies to the functional crowd! :) )
The height of the "static typing sucks!" craze was more like a "The Java type system sucks!" craze...
The audio experience itself, sure - "Want high-end audio without breaking the bank and remodeling your room? Get a pair of decent headphones." has been sound (heh) advice for decades.
The surround sound part, though? Eh, not quite yet. I mean, on paper, they have the ingredients - (personalized) HRTF and head tracking. But in practice I found even the personalized HRTF somewhat underwhelming, and knowing what's possible from the VR world the gap is still significant (IMO the Valve Index off-ear solution is still the pinnacle in immersive positional audio without surround speakers, even without personalization of the HRTF, I haven't really tested the AVP implementation yet, though) - which leads me to second, IMO even larger issue:
Extremely limited usage scenarios. For the living room, it's basically just supported Apps/content on AppleTV. Compared to the reality of a standard AVR (or even just Soundbar) plus surround speakers setup - take any multichannel input (LPCM, DD, DTS MA, Atmos you name it) and output surround sound - that's...just not a substitute. And that's not even getting into latency issues with gaming/interactivity (a general BT issue, though, at least it's slowly improving...).
I mean, it has its own RFC called "Procedures for Maintaining the Time Zone Database": https://www.rfc-editor.org/rfc/rfc6557
I'd say that's as far from "some random person in Nebraska" as you can get...
(And if you'd do a representative survey among developers having had to deal with time zone shenanigans, I'm fairly certain "thanklessly" won't hold either :) )
Well, that's the issue, isn't it? Both Intel and AMD (resp. their board partners) had issues in recent times stemming from the increasingly aggressive push to the limit for those last few %.
This is about sane, stable defaults. If you want the extra performance far beyond the CPUs sweet-spot it should be made explicit you're forfeiting the stability headrooms.