> it's also clear an economically disadvantaged country benefits mutually from this, and if it wasn't they'd be restricting tourist visas, etc
Countries are not a monolithic entity. The people in control of the flow of tourists are a tiny minority, and whatever incentives they have to open or close the borders do not reflect what the people who deal with tourists on a daily basis want.
It depends on the county of course, but in my experience service workers at many “touristy” countries seem to benefit directly from tourism.
For example, some of the workers at resorts in Thailand went to college and studied Tourism, a major I didn’t even know existed, and their wages come directly from the tourist industry.
What countries in particular are you thinking of where the locals are very unhappy to see more tourists? I’ve heard Japan might be in that category, and the United States certainly feels that way, but did you experience this yourself?
Hawaii, Barcelona, and some cities in Latin America like Medellín have had a few incidents to suggest that people are unhappy with tourists there.
A city I have stayed in banned AirBnBs to address an affordability crisis. Tons of locals went wild reporting houses they expected to were circumventing the ban. I remember looking at the press release and finding that all of the AirBnBs in the city amounted to less than 2% of the city’s housing stock.
From what I can gather, these sort of attitudes are an appropriation of reactionary xenophobia directed to an appropriate target in Barcelona, a cultural inferiority complex in Latin America (which receives virtually no tourists compared to all the expatriates they send to the developed world), and a legitimate existential crisis for the Hawaiians.
> The people in control of the flow of tourists are a tiny minority
The people ultimately in control of this policy are usually elected officials, so I’d (idealistically) say they have at least some incentive to make decisions that the general public wants.
Economic benefits by themselves are just one metric by which we can evaluate desirability, but do you have any reason to suggest that existing policy towards tourism is contrary to the prevailing opinion among those who interact with tourists on a daily basis?
> The people ultimately in control of this policy are usually elected officials
Even assuming we are talking about democracies, you still face the same issue: policies regarding tourism are decided at the national or supra-national (e.g. EU) level, while the effects are concentrated on specific neighborhoods of specific towns.
> do you have any reason to suggest that existing policy towards tourism is contrary to the prevailing opinion among those who interact with tourists on a daily basis?
Have you not heard of any popular protests against tourism? Speaking the local language helps here, but sometimes it is also reported in English.
> Have you not heard of any popular protests against tourism?
I mentioned in another comment that I know of vandalism that has occurred in Barcelona, some demonstrations in Medellín, and a long history of nativist sentiment in Hawaii, but I’m not convinced that these people represent a majority opinion even in tourist destinations. Have you seen any surveys or anything of the kind that would suggest a substantial portion of people are opposed to tourism?
By elderly people wo are already dying from natural causes and ask for a medically assisted death instead of unnecessarily prolonging their suffering. It is telling that so many people who suffer choose a dignified death once they are legally allowed to.
Thhe "God helmet" was likely a placebo device. From the very same Wikipedia article you linked:
> Other groups have subsequently found that individual differences such as strong belief in the paranormal and magical ideation predict some alterations in consciousness and reported "exceptional experiences" when Persinger et al's experimental set-up and procedure are reproduced, but with a sham "God helmet" that is completely inert or a helmet that is turned off.
I think this is the wrong way around. There might be an economic incentive to keeping something closed source, for example having licensed other closed source code. And remaining in control without oversight also might be an incentive. But the incentive to making something open source is that someone might improve your work, making your product better. It is somewhat arrogant to assume that nobody else out there could possibly improve this code or add value. Just like it is arrogant to assume that your competitors don't already know your 'secrets' and haven't reverse engineered anything they found interesting.
Speaking from the perspective of somebody who used to do this for a living.
> But the incentive to making something open source is that someone might improve your work
Device drivers, particularly on mobile, aren't evergreen sorts of software. New hardware is released several times a year, and maintenance after shipping is limited to critical issues. By the time it hits the market, the people who developed that driver have moved on to newer products.
> It is somewhat arrogant to assume that nobody else out there could possibly improve this code or add value
Whatever they did would have completely missed the release schedule. It may provide value to people who want to keep using a 10 year old phone, but how does that benefit a company that only makes income when they sell new models?
> Just like it is arrogant to assume that your competitors don't already know your 'secrets' and haven't reverse engineered anything they found interesting.
This made me laugh. You would be surprised by how minimal reverse engineering goes on in this space. It boils down to the same reason as before: by the time you have made any progress, the product you are reverse engineering is semi obsolete. The vast majority of the time it makes more sense to invest those resources into developing your own stuff.
That's my $.02 from having worked for four major GPU vendors out there. Upper management knows what they are doing, even if outsiders don't get it. The incentives simply aren't there for most GPU vendors most of the time.
Snapdragon doesn't do tile based deferred rendering the way Apple does (or did). Snapdragon does (or did) a form of tile-based rendering, but it is a completely different design, with completely different performance tradeoffs.
Worked there for 9 years, can confirm. I wish that our drivers had been open sources, because we poured our souls into them and took pride in the result.
> I work with mobile GPUs for <AAA Engine>, have direct contacts with Qualcomm, and the drivers still find ways to disappoint even with my low expectations.
Often when people run into problems with a GPU they blame "the drivers". How confident are you that the problems you ran into originated from the drivers, and not from other sources, such as the hardware itself? Just because an issue goes away with a driver update it doesn't mean that the problem originated in the driver -- most of the time what happens is that they found a hardware bug and implemented yet another software workaround.
I am not throwing the HW folks under the bus, either. The hardware is immensely complex and it's not that they can release a new revision every month.
One of the main responsibilities of GPU drivers is working around the bugs that are found after hardware is released. That, and getting all the blame.
I suppose from the outside I cant meaningfully distinguish from hardware or software bugs except in a few cases. Doesn't change the outcome for us either, it's not like we can rely on driver updates to be shipped on Android. Many extensions are broken like extended dynamic state to the point of being unusable. We've hit plenty of issues in the driver shader compiler too, even in Vulkan 1.0 features like relaxed precision.
We've hit a ton of bugs on the adreno 830, with even basic stuff like barriers being broken.
The problem isn't exclusive to Qualcomm fwiw, we've run into plenty of bugs in ARM's driver. Apple's too
Hardware can have issues, but firmware and drivers usually work around those issues. When firmware and drivers crash, you get "masterpieces" like the one above.
If the driver advertises support for something that's broken in hardware and not sufficiently worked around in the driver then that is still a driver bug. Keeping up the illusion that the hardware actually works as advertised is the whole point of drivers.
Doesn't the same factory produce enterprise (i.e. ECC) and consumer (non-ECC) DRAM?
If there is high demand for the former due to AI, they can increase production to generate higher profits. This cuts the production capacity of consumer DRAM, and lead to higher prices in that segment too. Simple supply & demand at work.
Conceptually, you can think of it as "RAID for memory".
A consumer DDR5 module has two 32-bit-wide buses, which are both for example implemented using 4 chips which each handle 8 bits operating in parallel - just like RAID 0.
An enterprise DDR5 module has a 40-bit-wide bus implemented using 5 chips. The memory controller uses those 8 additional bits to store the parity calculated over the 32 regular bits - so just like RAID 4 (or RAID 5, I haven't dug into the details too deeply). The whole magic happens inside the controller, the DRAM chip itself isn't even aware of it.
Given the way the industry works (some companies do DRAM chip production, it is sold as a commodity, and others buy a bunch of chips to turn them into RAM modules) the factory producing the chips does not even know if the chips they have just produced will be turned into ECC or non-ECC. The prices rise and fall as one because it is functionally a single market.
Each memory DIMM/stick is made up of multiple DRAM chip. ECC DIMMs have an extra chip for storing the error correcting parity data.
The bottleneck is with the chips and not the DIMMs. Chip fabs are expensive and time consuming, while making PCBs and placing components down onto them is much easier to get into.
> too careful in error handling, writes too much fallback code
Is it possible that your code goes a little cowboy when it comes to error handling? I don't think I've ever seen code that was too careful when it came to error handling -- but I wrote GPU drivers, so perhaps the expectations were different in that context.
I’ve definitely seen agents add null checks to a computed value in a function, but then not change the return type to be non-null. Later, it adds a null checks at each call site, each with a different error message and/or behavior, but all unreachable.
For bonus points, it implements a redundant version of the same API, and that version can return null, so now the dozen redundant checks are sorta unreachable.
When I'm writing web services I think I handle almost every error and I don't have this complaint there.
When I'm writing video games there's lots of code where missing assets or components simply mean the game is misconfigured and won't work and I would like it to loudly and immediately fail. I often like just crashing there. There are better options sometimes too, making a lot of noise but allowing continuation. But LLMs seem to be bad at using those too.
Actually to go back to web services, I do still hate the way I've had LLMs handle errors there too - too often they handle them silently or worse, provide some fallback behavior that masks the error. They just don't write code that looks like it was written by someone with 1) some assumptions about how the code is going to be used 2) some ideas about how likely their assumptions are to be wrong or 3) some opinions about how they'd like to learn their assumptions are wrong if so.
I have my own war stories from working at Qualcomm. Gather together, children.
Ahem. One upon a time I was the tech lead for one of the many software components in Qualcomm's GPU software stack. At one point there was customer interest in caching certain blobs of data that were relatively costly to compute, in order to reduce the startup times of a wide range of apps.
Since the caching needed to happen across different processes over time, we needed some sort of persistent storage with some metadata to track stuff like usage stats, limit storage requirements, etc. Simple stuff, right? I decided that we didn't need to reinvent the wheel, and thus suggested to the team's most recent hire to use SQLite.
Oh, Dear Lord. That was a mistake. SQLite worked great, no, no. That wasn't the issue. The problem was obtaining approval from Legal to use SQLite in our little project.
"Does SQLite have one of those viral licenses that require you to open-source your own code?" -- you may ask. No, it doesn't. It is the most lax OSS license that you could ask for. Super friendly to commercial closed-source projects.
No, the obstacle was that Legal wanted to audit SQLite line by line, down to the books and research that was mentioned in the comments, searching for anything from copyright infringement within SQLite itself, to patents that may be associated with any of its features. IIRC, it was going to take months and would require approval by my management chain. And any time we wanted to upgrade the version of SQLite we shipped with would require another extensive review.
I used to explain Qualcomm as a navy of lawyers and a dinghy of developers.
I spent SO MUCH TIME getting legal review to publish code.
One of my favorite battles was someone out there in the wild took the Microsoft boilerplate MIDL (MIT 2.0) and stripped the headers, licensing them as GPL. So our boilerplate MIDL files suddenly got ducked and we couldn't ship them any more.
Ah so the Oracle syndrome, where the engineering is a sidekick in the lawyer business?
In all seriousness, this is just appalling. This would make a good poison pill to prevent an opensource project from being used in such a corporation /s
Thanks for sharing! The sad part is, it's the qualcomm customers that pay for the end result.
Eh. I used to work for a large corporation that had multiple development sites worldwide. I remember telling someone at another site that I was considering using an OSS library. His jaw dropped, "You can use Open-Source? At our location using OSS is a fireable offence."
Countries are not a monolithic entity. The people in control of the flow of tourists are a tiny minority, and whatever incentives they have to open or close the borders do not reflect what the people who deal with tourists on a daily basis want.
reply