Word is that NetApp and Juniper are using FreeBSD.
What these have in common is that they rely heavily on FreeBSD's I/O performannce and capabilities which is said to be head and shoulders above Linux.
Playstation is based on FreeBSD, so I would guess that Sony has some serious FreeBSD people working there who created one of the most popular a video game console - that's pretty cool
I wouldn't be surprised if they "sold" (at a nominal price) the extra stock to a company outside the union for "resale" (burning in India or dumping into the ocean)
What we really need is 10x more expensive, durable clothing that you buy every 10 years. And the cultural shift to go along with it. Not Mao suits for everyone but some common effing sense. But I guess that's bad for business and boring for consumers, so...
I'm not particularly big into fashion (I think my newest clothes are 4-5 years old), but why is the thing you want "common [expletive] sense" and someone choosing to spend their money a different way, by extension, nonsensical?
What they’re getting at is not hairsplitting. Your argument presumes that the purpose of clothing is utilitarian in nature. That it exists merely to cover our bodies efficiently.
Clothing also has an anthropological function as fashion. That might not be something that you are personally interested in, but it is factually something that provides value to society.
You are certainly entitled to the opinion that fast fashion is not a good thing. But it’s just an opinion.
Fashion changing all the time (on the order of seasons rather than years) contributes to a lot of waste. Your claim that it "factually something that provides value to society“ is unsubstantiated. Just as unsubstantiated as "You are certainly entitled to the opinion that fast fashion is not a good thing".
All fast fashion does is waste money for consumers who buy into the craze, compared to buying quality that lasts. I have used the same two pair of jeans for over a decade at this point for example, and they are in close to mint condition (apart from the colour on the knees). Some T-shirts that I own have survived as long, many have not (it is very hard to tell the quality of the fibers up front unfortunately). In all cases, I use clothes until they are so worn through that they are past my repair skills.
So yes, some people are "invested" in fashion, but I'm saying that is akin to being "invested" in gambling or shopping for the sake of shopping. Addictions come in many forms.
The problem is not fashion, the problem is fast fashion, and the enormous amount of waste created. You really need to keep those separated in the discussion.
It's just boring for consumers. Business provides value to customers. Customers dictate what gets produced. And there are customers (e.g. me) who do keep things for a longer amount of time - there's a reason why generally men's clothing makes up around 20% of the total clothing shopping floor space in any given city.
Sure? It seems to me that the companies dictate what I consume. Many many times I wanted to buy exactly the same clothes item or shoes to replace an old one (because I know exactly how it'd fit and wear) only to discover it has been discontinued with no obvious "heir". Sometimes only 6 months later...
Whats the percentage of people chasing "fashion", especially after mid 30s?
I thought about getting a traditional navigator to avoid even relying on phone navigation.
Well, of course all the Garmins and Tomtoms available now have "built-in wifi for updates" and often BT for phone notifications too. Sure, I could just not configure either but what if I want a navigator _without any radios_ and with controlled updates via SD card.
Maybe a dedicated Android phone in the car with offline OpenStreetMaps installed and airplane mode on is more realistic. Or some old 2nd hand navi that's still updateable.
Also I can't imagine how being handed a bunch of autogenerated terraform and ansible code would help me. Maybe 10% of my time is spent actually writing the code, the rest is running it (ansible is slow), troubleshooting incidents, discussing how to solve them & how to implement new stuff, etc.
If someone works in a devops position where AI is more of a threat, I'd like to hear more about it.
I use Claude code with terraform all the time. It’s particularly good when your codebase is well modularized or at modularizing existing terraform.
It’s also quite good at getting to a solution by using validate/plan loops and figuring out syntax/state issues.
The biggest challenge is the lack of test sophistication in most terraform setups.
But llms generally are _amazing_ for my ops work. Feeding a codebase into one and then logs I’ve seen Claude code identify exact production issues with no other prompting. I use llms to help write incident reports, translate queries in the various time series db we use, etc.
I’d encourage you to try an llm for your tasks, for me for ops it’s been a huge boon.
First, thank you for the article, this is exactly what I need.
As for Home Assistant, I share your sentiment. I run my own stuff because I want to understand my infrastructure (vs. a black box from Philips) and to minimize the amount of code running around.
I'm sure HA is a better opaque box than the commercial ones for many people, but running it would still leave me with the same feeling of having outsourced critical knowledge - plus the compute costs.
The whole emoji phenomenon is a kind of infantilizing cultural rot -- it makes serious, static documentation and tooling resemble a children's book and hinders live communication by encouraging vague single-pictogram messages and the expression of raw emotions (genuine or not) instead of mature and balanced thoughts.
None of these things are mutually exclusive the way you're implying. This is a "cultural degeneracy" argument, which are always suspect imo. You are certainly entitled to dislike the aesthetics of shifts in communication, but you're basically just assuming that the changes are inherently negative and there's no reason to think they are.
"Single-pictogram messages and expression of raw emotion" are simply not mutually exclusive with mature, well-considered, intentional communication.
I guess I should feel relieved that I don't at least have my work discussions littered with these ones.
But they're not too different from the set of infantilizing pictograms that did make their way into the standard & that grown-ups are now expected to deal with.
Wouldn’t it have been interesting to be a fly on the wall during the annual convening of the ancient Egyptian’s hieroglyphics committee?
“This year’s proposals for new entries into the standard hieroglyphic dictionary include: slave being whipped, bearded slave being whipped, woman being humped by a donkey, and bearded donkey being ridden by a pregnant cat.”
Well, at least then you could think of the addons as local slang. It's still unnecessary, but limited to the social circle at your workplace.
I didn't have a huge beef with the proprietary emojis on old skool Skype and MSN, TBH - they were technically bound to those platforms, and the platforms mostly to private social spheres where they'd form part of the local slang. (And where Skype was used at work in the 00's, people actually refrained from them and acted in a businesslike manner).
Modern day emojis being part of unicode implies that they're somehow universally understood, and that it's fine to sprinkle them around in any kind of social context. Quite horrifying, really.
> Modern day emojis being part of unicode implies that they're somehow universally understood, and that it's fine to sprinkle them around in any kind of social context. Quite horrifying, really.
This just reads a bit like someone older ranting at the younger generation being glued to their smartphone all the time. Modern day emojis are part of our writing system. I use them all the time, from Slack to WhatsApp. They are universally understood, to a limit of course, but I see everybody else using them too and no "office drama" because Alice misunderstood the emoji Bob was using. They make it easier for me to express my emotions and they are as naturally as speaking. There's nothing extraordinarily horrifying really.
Fun fact: The Adobe enterprise slack workspace is not only open to everyone to add emojis, but (AFAIK) every slack-using company that Adobe has ever acquired has had their slack workspace subsumed into the Adobe one, which includes bringing in all of the acquiree's emojis. :-)
No. The user data, preferences etc under ~/Library/ belong to you - whether it's 3 kB of preference toggles or 3 decades of email.
It would be "unbelievable" if a multibillion company decided to be helpful and erase your data just because you deleted the binary that created them (actually, it wouldn't, but let's not digress into how those companies are stripping away our agency by mobile-ossifying everything).
The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.
Turns out your UNIX with a human face ate its children afterall. With relish.
Consider that sometimes people do actually want to clean up all artifacts of an installation, and don't want to go digging around in a bunch of machine-generated directories trying to guess what to delete.
I think I agree that the default behavior should be to leave all that data on the user's system. But I also think that apps should have some kind of associated file manifest, which you can use to automatically clean up after the app, or at minimum get a definitive list that you can go through manually or with a script.
It turns out that Apple installer packages do include a manifest (cutely called a BOM) of package contents, but users don't typically keep package installers around after completing installation successfully, and it says nothing about files that may be written by the app itself while in use.
I don't see how you could possibly claim that the user library "ruined" anything. Most apps need to save some kind of settings and/or transient data files. Where else would they go?
There are two scenarios I want the cleanup to happen: 1) app is buggy and I'm trying to fix it by reinstalling from scratch, 2) I need to free disk space. Both are pretty rare, and in the second case I am already using a specialized utility like DaisyDisk to see where my space has gone.
> transient data files
/tmp? That gets actually auto cleaned up!
> settings
Maybe. Do we want macOS to introduce the concept of uninstall to shave a few of those kilobytes? Hoping programmers do not screw up with rm -rf /? I already hate it when I have to use an installer so that's a no from me.
> 1) app is buggy and I'm trying to fix it by reinstalling from scratch
You don't specify and it's highly dependent but in most cases when an app is misbehaving it's an issue with preferences. You can reset most apps with `defaults` without blowing away all its data. There are some intricacies with how macOS handles preferences, so you should avoid manually editing related .plist.
> Note that if I am trying to fix an app that I want to keep using I sure as hell may want to keep the preferences.
Of course, `man defaults`. You can modify the preferences and potentially fix it, backup preferences, etc. Again I must stress that you use `defaults`, the .plist on disk isn't always accurate even if you terminate the app and reboot the machine.
> The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.
There isn't really a one size fits all perfect automatic solution. Not all apps are good macOS citizens.
Thanks for demonstrating your lack of credibility.
Uninstallers by and large only do the reverse of what an installer did by going through the install log and undoing what it did.
This means any additional files made after the the installation that weren't properly appended to the log, any additional information added to the Registry that weren't properly appended to the log, and any user files created after installation (eg: save files) will not be touched by the uninstaller.
Should everything be properly logged for clean uninstalling? Yes; Linux package managers are a decent example. But reality is not ideal, so we have to deal with practicality. This presumably is the case whether it's Windows, Mac, or Linux.
The user-specific parts of the registry are powered by files in the user‘s profile and ACLs do not normally allow other users to have access, so the same issue applies there too
lots of them leave crud in HKLM/System and HKLM/Software, as well as I think HKey_Curent_Config
I dont mind the per user settings crud, I do mind the system wide crud, because it can make reinstating the app to resolve an issue fraught, and I have to go manually find whatever opaque keys were set and remove them.
> The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.
The Windows registry is a simple key-value store, just like the macOS defaults system. Windows installers/uninstallers may create/remove some registry entries, but those are typically entries for file associations and the installed program list, and perhaps some global settings. But then the app is free to write its configuration data to any registry key it likes (usually ones named after the app), or to files in ~\AppData, or perhaps C:\ProgramData. It’s not much different to macOS in that regard. The uninstaller may offer to remove the stuff in AppData, or it might keep it as-is.
(~\AppData is a bit less messy than ~/Library, because there are only three folders in AppData where application folders could go, but Library has all these folders with various meanings.)
I think on macOS programs are able to store data "inside" themselves, because .app files are just folders. They usually shouldn't put stuff in Library.
That's wrong, of course they should put stuff in the ~/Library if necessary. That's why if you update an app it just replaces the whole .app directory, and also if you uninstall something and then install it again all your settings will still be there.
> Also, "uninstallable" means "cannot be installed"
Nope. In writing, it's technically ambiguous -- it could mean both "can't be installed" or "can't be uninstalled" but to me it means "can't be uninstalled". In spoken language, it depends how you stress the first syllable and both could be used, I guess.
That's why if you want to denote the installability of something, you should use the nonambiguous installable-noninstallable pair and leave the word "uninstallable" for the "can't be uninstalled" meaning. AFAICT, whether you should spell it as "non-installable" or "noninstallable" (note the hyphen) is up to you.
Again, in my personal experience, uninstallable definitely means 2 in [1]: "uninstall-able". Pretty sure I never saw that word used as "un-installable".
> When I delete an app on an iPhone, all its data is also deleted. Gone. Why can't it be the same for the Mac?
Because on iPhone the app is completely sandboxed. Think Docker, with virtualised OS paths, but on OS level. When Apple tried to introduce a very light version of sandboxing, the world was ablaze in pitchforks and torches.
When I delete an app on an iPhone, all its data is also deleted. Gone.
Nope. Delete your Google apps. Reinstall one. It'll still pick up the accounts you used prior. Well, it used to anyways. It's not an iCloud keychain thing (or it wasn't).
There is an exception on iOS as well. Apps can register write access to a custom location on iCloud that will persist after the app has been deleted. You can see all the leftovers in Files.app
The helpful part would be for the huge company to give users visibility and an easy choice, not your simple "delete everything" strawman
The data doesn't "belong to me", that entirely depends on the specific app/type of data (and this concept of a few kbs of very important stuff I've carefully changed in the app's settings menu and would even like to track in vcs vs all the other junk is also largely missing, though that's also on the app devs)
In Ubuntu i can do apt remove to just uninstall the binary or i can apt purge to remove config files as well. Is there an native macOS equivalent for this?
The package manager will never attempt to clear stuff under user's home directories, just like macOS will not clear stuff under ~/Library. The package manager doesn't and cannot know what content an application has created while in use. Only the application itself knows that.
Flatpak applications under Linux get their little sandboxes under ~/.var/app/$application-id where they can create whatever they want and the user can remove it from there when needed. Except for that, any other path that the app can access is decleared in the permissions; or the user is very well aware, because he picked the file via filechooser (portal).
Soma macOS applications can use similar scheme, under ~/Library/Containers/$application-id, but for the user more difficult to know which one is supposed to and which isn't.
At least provide a user friendly way to manage it. For instance, offer the option to either delete, backup, or leave in place when uninstalling. For things left in place, have a GUI to view and manage them.
How do you get hired if you do happen to have proper FreeBSD skills? It's notably absent from all the job listings.