It was in parentheses, that does usually imply irrelevant sideband information.
Perhaps more importantly, the “handsome and talented” sidebar was actually a tongue in cheek acknowledgment that the author himself was speaking, I suspect, compare the usernames and they match up suspiciously well.
I don’t think it has anything to do with their gaming specific capabilities, just their general philosophy matches poorly with the games industry.
Apple insist on having their own apis and they don’t maintain compatibility for older software for very long, these 2 facts explain things fine on their own. Game devs don’t want a major support burden, they’re happy to patch here and there but constant dropping of apis or even architectures is a lot to handle. The bigger impact is that macOS ends up with a lot less old games that still run, if you need a critical mass of games to become a gaming platform, that constant bleed of legacy games will always slow macOS down.
As for gaming specific features, Metal is a perfectly fine api whose only real problem is that it’s different from the other platforms. Maybe not the best, but certainly not terrible. They also have a really nice capability floor, it’s practical to make a modern game work on any Mac from the last X years (maybe the neo complicates that a bit).
There’s probably a few gaming specific capabilities they could improve on, mouse input especially, but that’s never been the real issue.
1. They don't exist, so if you own the game you still want it to work on your computer without maintenance updates
2. They still exist, so they don't want to have to update it every year because they can use that effort on making a new game and continuing to exist while still being able to sell from their existing catalogue because it still works
Either way it's in a game developer and gamers interest to have stable platforms
Yes, I can sort of understand Apple's argument that people should be running an email app that's been updated in the last 20 years, but I don't think it's defensible for software like games (or any offline productivity software, for that matter).
They've said that Rosetta 2 will stick around for games after it's phased out for other software, but it's hard to give much credence to that. Wouldn't be enough to make me want to bother publishing or buying games on Mac. They've dropped OS 9 compatibility (after having Classic), they dropped PowerPC support (after having Rosetta), they dropped x86 support after years of the OS supporting both 32 and 64 bit. And if they're keeping it available for games why not let me run other Intel Mac software?
Hard to imagine Rosetta 2 sticking around more than a couple years when Apple gets bored of supporting it.
Optimization and bug hunting makes supporting multiple graphics api's a pain. I really don't understand Apple's stubborn refusal to make vulkan drivers. Between Apple and the better performance on SteamDeck, I can see PC game developers seriously considering Vulkan over directx.
Sony's PS3 is an interesting comparison. It had some borderline ridiculous hardware by the standards of console development. I mean that both as a positive in terms of theoretic capability, and as a negative in terms of practical usability. Sony had a huge market, so I think they were banking on developers bending over backwards to build things to the strengths of the PS3 which would be such an undertaking that it'd almost undoubtedly have left the PS3 version of stuff as definitive, and other platforms operating as second class citizens. Unfortunately for them developers took the path of least resistance and ended up doing the exact opposite.
If game devs want to reuse their Vulkan code on Apple device, they can use MoltenVk or the more recent KosmicKrisp.
> Optimization and bug hunting makes supporting multiple graphics api's a pain.
The problems usually lurk in the graphics drivers, and not in the 3D API layer (e.g. optimization and bug hunting isn't much difference even when your code only supports a single API, and especially Vulkan drivers from different vendors may behave wildly differently on Windows, at least compared to D3D).
> I can see PC game developers seriously considering Vulkan over directx
Lol. That train has left the station long ago (around the time when Stadia was shut down, Vulkan saw a small uptick because of Stadia, but that soon fizzled out). Games need to support multiple 3D APIs anyway once they release on consoles. One or two more for the PC and Mac version doesn't make much of a difference (and most games are built on top of an off-the-shelf-engine anyway).
When a game glitches because of a driver bug, its the game developer that gets the bug reports (and the heat) and often has to isolate the problem to convince the gpu driver-team to fix it.
You may note that I specifically said "PC game developers" Your whole but consoles argument, completely misses the mark.
> When a game glitches because of a driver bug, its the game developer that gets the bug reports (and the heat) and often has to isolate the problem to convince the gpu driver-team to fix it.
Exactly, and having a Vulkan-only codebase won't make that problem go away. And IME it's much more likely to encounter vendor-specific driver issues on Windows Vulkan drivers than for D3D drivers.
Vulkan drivers on Linux are in a much better shape because they are centralized under the MESA project (except NVIDIA's drivers, which also have significant behaviour differences to the MESA drivers, at least in the window system glue).
> You may note that I specifically said "PC game developers" Your whole but consoles argument, completely misses the mark.
Why should a game developer support the tiny Mac market, but ignore the much bigger game console market though? From a business perspective, Mac support simply doesn't make sense, it's too much hassle for too little return (and the hassle isn't about the different 3D API, Metal is actually one of the best parts of the whole Apple developer ecosystem).
The drivers for D3D and Vulkan are separate, so supporting both opens you up to a whole new slew of bugs.
Mesa is largely an Umbrella. While some of the code is shared by in large, AMD works on radv, intel works on vulkan-intel and of course Nvidia work's on its own proprietary driver rather then very limited NVK.
Many games are first released on PC and only ported if they get big enough. So there are no considerations for cross-platform support in the original development.
Describing something in less detail doesn’t in fact make it simpler.
It’s nice you’ve done this before, so have I, but until git history it remained weirdly lacking in user friendly support infrastructure compared to most “common” tasks. Git history isn’t a major improvement, but it’s an improvement on a major weak point.
Easier to haul my luggage on a train designed for that purpose than take a car and spend longer parking it than the entire train journey. I live 10 minutes from Gatwick, have never driven there, and don’t understand why anyone would want to if there’s any alternative.
That’s going a bit far. I’m in the games industry and have used opus regularly, it’s a great codec for games, often the hardware decoding is so restricted that we’re using software regardless so we might as well use something like opus.
The licensing restriction is unfortunate, but only restrictive for those with very specific goals, under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.
I suppose a public domain game might hit the same limitation, though as a non-lawyer I would guess the chance of anyone with standing trying to sue anyone implementing from this spec is realistically zero (though I don’t fault stb for being unwilling to roll those dice!)
> under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.
And it's not as though libopus is an outlier in using a BSD license. A lot of other commonly used libraries have similar licenses; a few examples that come to mind which are likely to show up in games are zlib, curl, Lua, and SDL.
The game doesn’t have to be publicly licensed, the issue is for a library used by this game - or their engine. This remark is what blocks anyone from Valve making their own opus compatible library to use on their engines and supported libraries from what I could tell.
MRIs are fundamentally expensive. Yes we can bring the price down a bit, and we can set more money aside for them, but they’ll always be limited by their price.
Even if this technique is much worse (I can certainly believe it is) the price might allow uses that would never be practical with MRI even with the best financial support. For example, ultrasound might be viable for use in GPs or small medical facilities which could never dream of justifying an MRI machine.
Why would they remain fundamentally expensive? It is a fixed machine (so eventually you recoup the investment) and running consumes nothing other than electricity and a paper gown. MRIs cost under $200 in Japan.
The methods described in the main article refer specifically to neurovascular imaging. In order to have a higher resolution, they’re making use of microbubbles (which need to be prepared and injected just prior to imaging).
There is no world where vascular imaging with a methodology like this is better than what I can do today in a GP clinic with a handheld GE or butterfly (or similar) US probe for anything that matters:
- for dvts and thrombus I can already image them
- if it’s in the brain the last thing that is useful for you to do is fuck around in a small clinic when you should be getting to a major tertiary centre as soon as possible
They are claiming to want to detect CTE which normally is only diagnosable in an autopsy, I thought. Can current MRI do that? Right now we get former NFL players offing themselves with gunshots to the chest, intentionally leaving the brain intact for postmortem scanning, so posterity can figure out what was wrong with them. It's painful to think about.
My impression isn’t that they are trying to improve CTE imaging (did it say that in the article?!) but somehow approach the resolution of being able to run the blood flow data through a black box so they can demonstrate what the occipital cortex is processing. I mean, that’s literally the first part of the article?
Can MRI/CT demonstrate CTE.
Well, like a lot of things which as alzheimers, that is still a pathological diagnosis for the most part, to the best of my knowledge (not post mortem scanning but out some brain tissue on a slide), but this belies the general fact that getting the tissue diagnosis is really not that important to anyone except a pedant, because yes MRI will show changes in grey/white matter differentiation and size compared to age and sex weighted cohort; and CT will show similar; and in fact it is the history and examination that practically matter to both the patients and their family.
So while it’s nice to have a totally 100% bulletproof ‘diagnosis’ for labelling purposes, practically on history and exam it’s not going to change how they are managed or what they and their family do say to day; given that both CTE and basically any of the dementias don’t have any treatment associated with them, and the current neuro imaging we have can deliver much higher resolution than what this is promising anyway (I mean even CT angio, and it’s not using ‘advanced imaging processes’ to create data out of noise)
Yes totally, and ultrasound already does wonders in that regard. It's a good strategy to focus on the specific use cases that match the strengths of the tech. I think MRI will be useful in validating and mapping out those cases.
Scenario 1: 20% of staff tested failed. Individual targeting is pointless because the issue is systemic. This has happened in aviation, it’s common for accident investigators to conclude that the entire company culture (or even the entire industry) has failed to handle a problem. They don’t waste time in cases like this pointing at individuals.
Scenario 2: you test very regularly and nobody fails the tests. Except Bob, he fails the tests. In this scenario, your threat analysis document will recommend retraining, firing, or restricting Bob specifically.
Scenario 2 almost never happens because nobody has data that good. If your sampling frequency or ability to conduct tests are limited, no specific sample is enough to cover the entire problem. If you focus on a punishing (or just re-educating) the 20% who failed then your next test will fail for (potentially) 20% of the 80% who weren’t retrained, and thus didn’t learn anything.
TLDR: you need to choose the approach based on the situation, but we collectively tend to treat security poorly enough that we’re almost never in the fortunate situation where scenario 2 fits.
Disagree, though you’re right it’s a little bit similar to the eu flag, but only a little, plenty of countries manage with more similar flags.
Flags don’t exist for the period where they’re gaining recognition. Compromising the significance of the iconography for the temporary gain of not being misidentified during the period it isn’t recognisable would just mean if it gains recognition it will forever be less than it could be.
In other words, with flags you need to play to win, not to survive. Better that the attempt have a higher risk of failure with a great flag than a lower risk with a mediocre flag.
The pale blue dot is an excellent way to represent a global outlook and “we’re all in it together”, not sure I can think of a better pedigree for this concept. I’d perhaps have been tempted to make it a smaller blue dot, but flags do need to be recognised at a distance, so it can’t be too much smaller.
This is true, but since you always need a bit of hope in all the bad news, worth noting that if you focus solely on electricity generation, the fossil fuels from generation decreased last year. That’s the first time it’s happened when demand increased as normal (ie if we disregard things like covid which decreased fossil fuel use by suppressing demand). Electricity use went up as normal, but renewables went up faster, cutting out the normal fossil fuel increases. Whilst this isn’t quite going to be a guaranteed every year thing yet, it’s going to happen more and more, and in a few years we can expect to see the last year where fossil fuel use for electricity goes up, followed by an inevitable decline.
Of course there’s a lot of other uses of fossil fuels than just electricity, so we’re still using more each year and probably will for a while yet, but it’s still a major milestone and a change in how the world works that can be celebrated, especially given so many things are switching towards electricity as a basis at the same time.
We are fixing the problem too slowly, but the ball is rolling faster and faster now, signs a promising that we will eventually fix it, now the question is how much damage will be done before we get there rather than whether we’ll get there.
Earths atmosphere doesn't react to our celebrations, it reacts to our emissions.
The error is to concentrate only on electricity generation, because nothing is gained by increasing share of electricity generated by renewables, if the total CO2 emission don't decrease. It's quite possible that use of fossil fuels will shift from electricity generation to other uses, as we can already see in China with coal-to-gas and chemicals boom. Will we see more gasoline, diesel production from coal?
Perhaps more importantly, the “handsome and talented” sidebar was actually a tongue in cheek acknowledgment that the author himself was speaking, I suspect, compare the usernames and they match up suspiciously well.
reply