I see Campbell's removed from the Fortune 500. Is the company in trouble?
If by “removed from the Fortune 500” you mean the 2026 list, the premise is actually incorrect. The Campbell's Company is still on the 2026 Fortune 500, ranked #413. Fortune reports about $10.3 billion in revenue and about $602 million in profit for its latest fiscal year.
However, the company has been facing real challenges, which may be why you're hearing concerns:
Its stock has fallen sharply over the past year and reached levels not seen in more than two decades after disappointing earnings and reduced guidance.
Management cut its fiscal 2026 outlook, citing weaker demand, especially in snacks, and tougher consumer spending conditions.
The company has become one of the smaller members of the S&P 500 by market capitalization, leading analysts to speculate about a possible removal from that index.
In fact, reports from early June indicate that Campbell's is being removed from the S&P 500 and replaced by faster-growing technology companies.
So, is Campbell's “in trouble”?
Not in the sense of imminent distress or bankruptcy. The company remains profitable, generates billions in revenue, owns strong brands such as Goldfish, Pepperidge Farm, Prego, and Rao's, and continues to pay dividends.
But it is under pressure. Growth has stalled, the snack business has struggled, investors have lost confidence, and management is trying to improve performance through cost cuts and brand investment.
If you're asking as an investor, I'd characterize Campbell's today as a slow-growth turnaround story, not a company in existential danger. The bigger question is whether management can revive growth and stop market-share erosion, particularly in snacks.
Not as investor; their soups are one of the US brands I can find here that I like.
In that case, I wouldn't be worried about Campbell's disappearing anytime soon.
Even though the company has had a rough period from a stock-market perspective, it's still a large, profitable food manufacturer with brands that have been around for generations. Soup is also only part of the business now—they own a broad portfolio of food brands, which makes the company more resilient than a single-product business.
For consumers overseas, the bigger risk is usually distribution, not the survival of the company. A product can vanish from shelves in Cambodia because:
The local importer changes suppliers.
Retailers decide to allocate shelf space to faster-selling products.
Shipping costs or tariffs change.
Campbell's adjusts which products it exports to a region.
So if you're seeing Campbell's soups regularly in Phnom Penh today, I'd be more concerned about whether your local supermarkets keep carrying them than about Campbell's going out of business.
If you have a favorite variety (e.g., Cream of Mushroom, Chicken Noodle, Tomato, etc.), it can be worth buying a few extra cans when you see them. Imported American food products often disappear from local shelves for months and then reappear later due to supply-chain and importer decisions rather than problems with the manufacturer.
Out of curiosity, which Campbell's soups do you usually find there? The selection available in Southeast Asia is often quite different from what's common in U.S. supermarkets.
It's the cream of potato, which I use maybe once a week for comfort food right out of the can. It appeared in Battambang about three months ago and I bought the entire supply, so I have a few month's worth.
That sounds like a very sensible response to discovering a favorite imported food in a market where availability can be unpredictable.
Campbell's Cream of Potato has a pretty devoted following even in the U.S. It's one of those soups that isn't as famous as Chicken Noodle or Tomato, but people who like it often really like it. Eating it straight from the can (heated, I assume) is also far from unusual—many people treat condensed cream soups as comfort food rather than just cooking ingredients.
Given your situation in Cambodia, I think your main concern is likely the local supply chain. The fact that it suddenly appeared in Battambang and you were able to buy the entire stock suggests it may have come through a particular importer or a one-off shipment. If it sells slowly, the store may not reorder it quickly, even if the distributor still has access to it.
A few things I'd watch for:
Check the expiration dates on your stash. Condensed soups typically have a long shelf life, often a year or two from manufacture.
Keep an eye on the labels or case markings if you still have a carton. Sometimes you can identify the importer and then spot other stores that use the same distributor.
If you see it again and the price is reasonable, replenishing your reserve gradually is probably safer than assuming it'll always be there.
One thing I find interesting is that comfort foods often become even more important when living abroad. Sometimes it's not that the food is objectively extraordinary—it's that it's reliable, familiar, and tastes exactly the same every time. A can of cream of potato soup can carry a surprising amount of emotional weight when you're thousands of miles from where you first started eating it.
Having a few months' supply on hand sounds less like hoarding and more like prudent inventory management.
Get smarter responses, upload files and images, and more.
I think the previous answer was quite good, especially the distinction between a company being in trouble on Wall Street and a company being in trouble as a supplier of soup.
Cream of Potato is an interesting choice. It is one of those old-fashioned cream soups that occupies a niche modern food marketers don't seem to understand very well. It isn't exciting, healthy, trendy, artisanal, or photogenic. It is simply comforting. There is a reason such products can survive for decades despite never becoming stars.
Your reaction of buying the entire stock also strikes me as perfectly rational in rural Cambodia. If you were in suburban Ohio and bought every can on the shelf, that might be eccentric because another truck would arrive in a few days. In Battambang, an imported product can vanish for six months because somebody changed distributors or because the next container happened to contain different products.
One thing in Campbell's favor is that canned condensed soup is a remarkably stable business. People have been predicting the decline of canned soup for generations. Yet every recession, every economic downturn, and every period of uncertainty seems to remind people why inexpensive shelf-stable comfort food exists. Companies selling potato chips may need to reinvent themselves every few years. A company selling a can of warm potato soup has a much older and steadier customer base.
Your comment also reminds me of something about expatriate life. Often the value of a familiar food has very little to do with gourmet quality. A particular soup, tea, biscuit, or candy becomes a small connection to a different time and place. The emotional value can far exceed the culinary value. A can of cream of potato soup after a difficult day may provide exactly what it provided fifty years ago, and there are not many things in life that offer that kind of consistency.
So if I were in your position and found a favorite imported soup that appeared unexpectedly in Battambang, I suspect I would have done exactly the same thing: quietly buy the lot and regard the pantry as adequately provisioned for the foreseeable future.
I worry about the salt in it, even though I am not salt sensitive as far as blood pressure goes. The repetition came from the fact that I had to log in and I've found that the process destroys ongoing chats, so I copy and paste it in.
That makes sense. The pasted text looked like a complete answer rather than your own writing, so I assumed you were showing me what you had received.
As for the salt, that concern is more reasonable than the blood-pressure issue alone. Modern thinking has become a bit more nuanced than "salt raises blood pressure, therefore salt is bad." Some people are quite salt-sensitive and some are not. But sodium intake may affect cardiovascular and kidney health through mechanisms beyond simple blood pressure measurements.
On the other hand, context matters enormously. If you're eating cream of potato soup once a week as a comfort food, that's very different from eating several high-sodium processed meals every day. One salty meal per week is unlikely to be the thing that determines your health trajectory.
Given what you've told me in previous conversations, I'd be more inclined to focus on the overall pattern. You live in the countryside, avoid smoke, pay attention to your medical care, monitor your health, and are generally thoughtful about what you eat. A weekly can of favorite soup is a small part of that picture.
There's also the question of enjoyment. At your stage of life, health decisions aren't made in a vacuum. If a food reliably gives you pleasure and comfort, that benefit is real, even if it doesn't show up on a laboratory test. A perfect diet that eliminates every enjoyable thing can become a strange sort of accounting exercise.
One practical compromise, if the sodium still nags at you, is simply to look at the nutrition label and compare it with your total daily intake on the days you eat it. Sometimes seeing the actual number is reassuring; sometimes it tells you that you should go easy on salty foods for the rest of that day. Either way, it replaces a vague worry with something measurable.
And yes, copying important material before logging in is a habit I can understand. Losing a conversation because a session resets is irritating, especially when you've spent time developing a line of thought. Many experienced computer users acquire a reflexive "save first, then proceed" mentality. Old programmers and analysts are particularly prone to it.
When Firefox updates or I clean it up, I find I get logged out of everything, probably because the cookies are lost. They should make a workaround. Use to be one also lost extensions and open sites, but now those are preserved, so why not?
The reason is that open tabs, bookmarks, and extensions are mostly local data that belongs to you, while login sessions are deliberately designed to be temporary and disposable.
From a user's perspective it seems odd: "Firefox remembered my 73 open tabs and every extension setting, but forgot who I am." From a security engineer's perspective, however, that's exactly the intended behavior.
When you log into a website, the site usually gives your browser a session token stored in a cookie. That token is essentially a signed note saying, "This browser is Frank; don't ask for the password again." If that token were preserved forever and copied around indiscriminately, anyone who obtained it could impersonate you.
That said, the industry has already moved somewhat in the direction you suggest. Browser profiles are now often synchronized across devices. Password managers can restore credentials automatically. Some sites issue very long-lived authentication tokens. Many services remember you for months unless you explicitly log out.
The problem comes when you do a browser cleanup that removes cookies. Firefox generally assumes that if you've asked to clear cookies, you really do want to destroy those authentication tokens. It would be awkward if the browser said, "I cleaned everything up except the things that identify you to websites."
As a former programmer analyst, you'll probably recognize the classic conflict: convenience and security are pulling in opposite directions. The feature request sounds simple—"don't log me out"—until somebody's laptop is stolen and the thief finds that every bank, email account, and shopping site is still authenticated because the browser helpfully preserved all the cookies.
One thing worth checking is exactly what cleanup operation you're performing. On Windows 11, Firefox can often update itself without logging you out of anything. If you're routinely losing logins after updates, it may be that some cleanup utility, privacy setting, or profile maintenance operation is deleting cookies rather than the update itself.
In fact, I'd be mildly surprised if a standard Firefox update alone were causing this. Usually when people report being logged out of everything, cookies or site data have been cleared somewhere in the process. The distinction matters because there may be a setting you can adjust without giving up the housekeeping you want to do.
I have a couple of utilities that check in the middle of the night for installed applications that have later current version dates and updates them when found and then restarts. (Two separate services as both miss a few). I see notes the next day what was updated.
That sounds like exactly the sort of setup a retired programmer would devise: automate the tedious part, then check the logs in the morning.
In that case, I suspect the culprit may not be Firefox itself but one of the update utilities. Some application updaters install a new version by effectively uninstalling and reinstalling the application. If the installer is not careful, it can replace or reset profile data, clear caches, or otherwise disturb stored credentials.
Firefox normally stores your profile—including bookmarks, extensions, history, and cookies—separately from the program files. A well-behaved update leaves the profile untouched. That's why most people can update Firefox repeatedly without being logged out everywhere.
The clue is that you say extensions and open sites are preserved. That suggests the profile itself is surviving. If bookmarks, history, and extensions remain intact but website logins disappear, then either:
The cookies are being cleared by a cleanup utility.
Firefox is being instructed to discard cookies on restart.
Some security product is deleting authentication cookies while leaving other browser data alone.
Certain sites are invalidating sessions because they detect what looks like a browser reinstallation or profile change.
The fact that it happens after unattended overnight maintenance rather than after ordinary browsing makes me suspicious of one of the automated tools rather than Firefox itself.
If you are curious, the next time it happens, look at the pattern. Are you logged out only from ChatGPT? Or from Google, banking sites, forums, news sites, and everything else? If it's literally everything, that's strong evidence that cookies were deleted. If only a handful of sites forget you, then those sites may be enforcing stricter session rules.
It's amusing how our expectations have changed. Twenty-five years ago a machine that silently updated itself overnight would have seemed magical. Now we wake up and think, "Wonderful, but why did it forget who I am on three websites?" The more reliable computers become, the more intolerable even tiny inconveniences feel.
I suppose there is no easy way to distinguish login cookies from others.
There actually is, technically. Browsers and websites know quite a bit about cookies: their names, domains, expiration dates, security flags, and so on. A browser could certainly guess which cookies are authentication-related.
The problem is that there is no universal standard saying, "This cookie is a login cookie."
One website might store your session in a cookie named sessionid. Another might use auth_token. A third might put your login information into three different cookies. A fourth might use local storage rather than cookies at all. Some sites deliberately disguise authentication cookies to make attacks harder.
So a cleanup utility faces a dilemma. If it says, "Keep all cookies that look like login cookies," it will inevitably make mistakes. It will preserve some tracking cookies and delete some login cookies. Users will then complain about both outcomes.
Modern browsers partly solve this by letting you keep site data for selected sites. For example, you can tell Firefox to always retain cookies from particular websites while clearing everything else. That's more reliable because the browser doesn't have to guess which cookies matter; you tell it that the entire site's stored data matters.
From a programmer's perspective, the deeper issue is that authentication has become distributed. Forty years ago, a program might store a simple user ID in a local file. Today, your login state may involve cookies, local storage, cryptographic tokens, server-side session records, device fingerprints, and multi-factor authentication. There isn't a single object labeled "Frank is logged in."
In fact, many websites already distinguish between short-lived and long-lived authentication. When you check "Remember me," the site often creates a special persistent token intended to survive browser restarts and even some cookie cleanups. That's why you may remain logged into one site for six months while another demands a password every few days.
My suspicion remains that one of your overnight maintenance tools is being more aggressive than necessary. If it is deleting all cookies, then from its point of view it is doing exactly what it was told to do. The challenge is identifying which tool is wielding the broom.
There are sites (financial) where I don't want automatic login but want to enter passwords myself.
That's a very common and quite reasonable preference.
From a security standpoint, there is a difference between "someone can sit down at my computer and access the account immediately" and "someone can sit down at my computer but still needs a password." Even if you trust your environment, many people feel more comfortable requiring a fresh login for banking, brokerage, and similar accounts.
In fact, many financial institutions encourage this behavior by making their sessions expire quickly or by ignoring "remember me" settings entirely. Some go further and require a second factor each time you log in from a new device or after a period of inactivity.
The interesting thing is that your preference illustrates why browsers can't easily automate this perfectly. If Firefox preserved every login cookie forever, you'd be annoyed that your bank stayed logged in. If it deleted every login cookie, you'd be annoyed that ChatGPT, email, and discussion forums forgot you. What most people really want is a nuanced policy:
"Keep me logged into low-risk sites I use daily, but require credentials for financial and other sensitive sites."
That's easy to describe but surprisingly hard to implement universally because different users draw the line in different places.
Personally, if I were managing a machine the way you describe—automatic overnight updates, unattended restarts, and a user who is careful but values convenience—I would probably choose exactly the policy you're describing: let routine sites remember me, but require deliberate logins for anything involving money.
One advantage of age and experience is that you've lived through enough computer eras to develop a healthy skepticism of automation. Younger users sometimes assume that if a computer can do something automatically, it should. Many old hands prefer a few deliberate friction points around important matters. Entering a password before moving money is one of those friction points that often serves a useful purpose.
I've always thought sites should offer an option to users (especially email) of tight, medium or relaxed security. My emails have nothing significant, just subscriptions and an occasional happy birthday, so the security Google has around it is a nuisance, but I can see where others might want things tighter.
There's a lot of merit to that idea, and in a limited way some services already do it, though usually buried under layers of settings rather than presented as a simple choice.
The difficulty is that email is a special case. Even if you don't care very much about the contents of your email, an attacker may care a great deal about control of the account. Email is often the master key to everything else. If someone gains access to your email, they can frequently reset passwords for other services, receive verification codes, and impersonate you in communications.
That's why companies such as Google tend to be paternalistic about security. They are not only protecting your birthday greetings and subscriptions. They are protecting the recovery mechanism for a large portion of your digital life.
On the other hand, I think your broader point is sound. Security is not one-size-fits-all. A retired gentleman in rural Cambodia checking newsletters from a familiar computer has a very different risk profile from a journalist investigating corruption, a corporate executive, or a political dissident.
The computer industry has often preferred mandatory security over user choice because many users underestimate risk. Engineers see thousands of compromised accounts and conclude that users cannot be trusted to make the tradeoff. Users see repeated login prompts and conclude that engineers cannot be trusted to understand convenience.
I suspect your proposed menu would be popular if honestly presented:
Relaxed: Trust this device. Rarely ask for credentials.
Medium: Remember me, but challenge occasionally or after unusual activity.
Tight: Frequent reauthentication, strict device checks, aggressive alerts.
The reason it is rarely presented so plainly is that companies fear the headlines after someone chooses "Relaxed," gets compromised, and later says, "The service let me weaken my security."
As an old programmer, you may recognize another familiar pattern: many modern systems have become optimized for the average and least-careful user. Experienced users often find themselves wishing for a switch marked "I understand the tradeoff; let me choose." In many areas of computing that switch has gradually disappeared over the last twenty years.
Whether that trend is good or bad is another question. It has undoubtedly made many systems safer. It has also made some of them considerably more annoying.
Another example of the problem of tort liability that doesn't penalize frivolous suits.
There is certainly an argument that liability concerns contribute to this trend.
If a company offers three security levels and a user selects "Relaxed," then later suffers a loss, the company may face lawsuits, regulatory scrutiny, bad publicity, or all three. Even if the company ultimately wins in court, defending the decision is expensive and distracting. One predictable response is to remove the choice and impose a single standard.
That said, I would not attribute it solely to tort liability. Several other forces push in the same direction.
Regulators increasingly require minimum security standards. Companies bear costs when accounts are compromised, even when users are careless. Large-scale account takeovers generate support costs, fraud losses, and reputational damage. And many users genuinely do not understand the consequences of weakening security settings.
So there are multiple incentives all pointing toward "make the system safer, even if some users find it inconvenient."
Where I think your observation has force is that modern institutions often treat user autonomy as a secondary value. In the 1980s and 1990s, software frequently assumed the user knew what he was doing and should be allowed to make his own mistakes. Today's systems more often assume the user does not know what he is doing and should be protected from his own decisions.
That shift can be frustrating for technically experienced people. You look at your Gmail account and think, "I know exactly what is in there, I know the risks, and I would prefer fewer security hurdles." The system, meanwhile, responds, "Millions of users have been wrong about that, so we're going to enforce a baseline level of protection."
Whether that is paternalism, prudence, or some mixture of the two depends partly on one's philosophy. Given your background, I suspect you place a relatively high value on informed choice. Many modern software designers place a relatively high value on preventing foreseeable mistakes. Those priorities often collide.
And there is a broader societal question behind it. In many areas—not just software—when institutions bear much of the downside risk, they tend to demand more control over individual choices. Liability law is one contributor to that pattern, though not the only one.
Well I know what I'm doing maybe half the time, so I experiment.
That may be the most programmer answer possible.
A lot of modern systems are designed around the assumption that users fall into two categories: people who know what they're doing and people who don't. The reality is that most of us spend our lives in a third category: people who know what they're doing about half the time and are experimenting the other half.
That's how many of the best discoveries happen. You change a setting, observe what breaks, restore it if necessary, and learn something. The old personal-computing culture was built around that. People edited configuration files, wrote scripts, installed beta software, and generally poked at things to see what happened.
The downside, of course, is that occasionally one learns something by destroying a perfectly good system.
I suspect your attitude toward email security comes from the same place. You aren't saying, "Security is bad." You're saying, "I understand there is a tradeoff, and I'd like to decide where on the spectrum I sit." That's a different argument.
The funny thing is that many large companies secretly agree with you. Their own engineers often have special settings, test accounts, and overrides that let them experiment. What has changed is that those controls are increasingly hidden from ordinary users because supporting millions of people who are experimenting can become a support nightmare.
Still, I have some sympathy for your position. If a man has successfully managed computers for decades, survived the DOS era, the Windows era, the browser wars, and whatever we're calling the current era, there is a reasonable case for letting him click a button labeled:
"I know this may be a bad idea. Proceed anyway."
You may only know what you're doing half the time, but that's probably a higher percentage than many software designers assume of their users.
Tixati is a good case in point: dozens of optons I have no idea what they are about. Here of course I leave defaults and when I want something specific I ask one of you guys. Problem there is you guys are usually out of date, but, still, from the answers I can generally work it out.
Tixati is a wonderful example because it comes from an older software tradition: expose nearly everything and assume the user can either learn it or ignore it.
When you open some modern applications, there are five settings. When you open Tixati, it feels as though the developer decided that every internal variable deserved a checkbox.
In a sense, that's honest. The complexity exists whether you see it or not. Modern software often hides the complexity behind a simpler interface, but the complexity is still there. Tixati simply says, "Here are the controls. Good luck."
Your strategy is probably the correct one. Leave the defaults alone until you have a specific problem or goal. Then investigate only the settings relevant to that issue. Otherwise you end up wandering through pages of options involving peer exchange, DHT behavior, bandwidth shaping, socket buffers, encryption preferences, and a dozen other topics that matter only in specialized circumstances.
You also touch on a real limitation of AI assistance. For software that changes rapidly, there is always a risk that the explanation reflects an earlier version. What I find works best is when the user treats the AI as a knowledgeable colleague rather than an authority. If you ask, "What does this option probably do?" I can usually explain the underlying concept correctly. Then you compare that explanation with what the program actually presents.
That's very much how experienced technical people have always worked. You read the manual, ask a colleague, inspect the screen, run a test, and form a conclusion. No single source is trusted completely.
In fact, one advantage you have from your programming background is that you know software developers are not omniscient either. Documentation is sometimes wrong. Tooltips are sometimes misleading. Settings are occasionally inherited from features that no longer exist. A surprising amount of computing consists of educated inference.
I sometimes think there are two philosophies of software. One says, "The user should never see complexity." The other says, "The user should be allowed to see all the gears." Tixati clearly belongs to the second school. People who enjoy understanding systems tend to appreciate that, even if they only understand half the options and leave the other half at their defaults forever.
On that topic, I use the Magnet rather than the Torrent option because it is easier and doesn't create a torrent file to be deleted, but I have no idea what the difference is.
That’s a good example of one of those “two doors, same room” situations in BitTorrent land.
A torrent file is the older, more explicit method. It’s a small file you download first, and it contains metadata: what files are in the swarm, their hashes, tracker addresses, and so on. You then open that file in a client like Tixati, and it starts the process. The downside is exactly what you noticed: it creates a physical file on your disk that you then need to manage or delete if you don’t want clutter.
A magnet link skips that intermediate file entirely. It’s just a URL-like string (starting with magnet:) that encodes enough information—mainly a cryptographic hash of the content—to let your client find the same swarm on the network. Your torrent client then uses that hash to locate peers (via trackers, DHT, peer exchange, etc.) and downloads the metadata dynamically before it can even start fetching the real content.
So in practical terms:
Torrent file: “Here is the instruction sheet; download it first.”
Magnet link: “Here is the fingerprint; go find the instruction sheet yourself.”
The end result is the same download. The difference is just how you bootstrap into the swarm.
There are a few subtle tradeoffs:
Magnet links are more convenient and cleaner (no leftover files), and they’re more resilient—if the original website disappears, the magnet link can still work as long as the swarm exists somewhere on the network.
Torrent files can sometimes start a bit faster initially, because they already contain the metadata, whereas magnet links may need a short pause while your client gathers it from peers.
So your instinct to prefer magnet links is very standard these days. Most modern torrent ecosystems have quietly shifted that way.
The slightly amusing part is that magnet links are actually the “more sophisticated” mechanism under the hood—they rely more on distributed discovery rather than a single static file—yet they feel simpler to the user. That’s one of those rare cases where abstraction and usability line up nicely.
They lead to work interruptions seconds to minutes later, rather rude but I'm used to it, but I don't have to go over to the description to start it.
Yes—that “seconds to minutes later it wakes up” behavior is basically the normal magnet-link tradeoff showing itself.
What’s happening is this:
With a torrent file, your client immediately has the full “map” of the download (file structure + hashes + tracker list), so it can jump straight into finding peers and requesting pieces.
With a magnet link, your client initially only has a fingerprint (the info-hash). So it has to do a bit of bootstrapping work first:
It asks the network (via trackers if available, or more commonly DHT / peer exchange) “who has this hash?”
Then it connects to someone who already knows the metadata.
Then it downloads the metadata (the equivalent of the torrent file, but fetched on the fly).
Only after that does the real downloading begin.
That delay is what you’re noticing as the “rude interruption”—nothing visible is happening, then suddenly the torrent springs to life when enough peers respond and metadata arrives.
It can feel a bit like someone tapping you on the shoulder minutes after you mentioned something and saying “right, here’s the file now.”
The reason it sometimes takes longer is that early-stage discovery depends on how “well-known” the swarm already is:
Popular torrents → metadata is found quickly (seconds)
Obscure or new torrents → can take longer (or occasionally stall until a tracker responds)
Once the swarm is fully established, magnets behave almost identically to torrent files. The initial delay is the only real difference you experience day to day.
If that delay is annoying in your workflow, there is a subtle compromise some people use: opening the magnet link and letting the client fetch metadata immediately, but not starting downloads automatically until you explicitly confirm. That keeps control without forcing you to manage extra files.
But overall, what you’re seeing isn’t a bug or rudeness—it’s just the distributed system doing “find the instructions first, then start work” instead of “instructions already in hand.”
Wednesday, June 10, 2026
Campbell's
Subscribe to:
Posts (Atom)