> Outlook is the lone exception where that team decided to have Outlook for the web, Windows Outlook, and Mac Outlook be identical, so those are getting their rewrites with removal of Win32-specific features where applicable.
I wish they didn't. Outlook on macOS is abysmal nowadays and I still find myself resorting to the legacy view just to change some settings that both iterations can read but only one exposes.
I significantly prefer using Thunderbird or the web views for Gmail and Zoho Mail over any version of Outlook. Is the integration across O365 apps nice? Sure, but the platforms themselves are miserable to use.
In a similar vein, I was cautiously optimistic about Teams V2 for unifying the client. But then they completely dropped the Linux client for their PWA which does not have feature parity with the "native" platforms and has a significantly worse UX.
I think that Outlook as an experience has become significantly worse as o254 has advanced... I understand some of the reasons, such as managing millions of inboxes vs a few dozen on a private server. That said, it's kind of a mess.
I used Thunderbird for years, mostly to keep my NNTP feeds going, at some point, my mailboxes corrupted between versions (the NNTP site I was using didn't work right anymore) and I just kind of gave up at that point. It was in the dark time, before the more recent resurgence of dev activity, but NNTP didn't seem to be even a tangential focus.
I'd love to see a relatively easy open-source server for mail+contacts+calender that allowed the level of visibility, management and sharing that Outlook+Exchange/o365 offers. Right now, I have some of that, but not nearly the same.
Edit: Also, really sick of getting meeting change notifications in Teams for a meeting that is months away... just leave any meeting notifications beyond today/tomorrow in outlook, I don't need them in my workgroup app.
Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines.
I find that for persistent configuration like this, it helps to use the long option format and include the man page contents for those options. I don’t have these options memorised so it’s good to have a reference handy to remind me.
I think my problem is that it's just close enough to being fire-and-forget that I forget how to do the recovery when it misfires. It usually seems to crop up when I'm on vacation or something and I don't have my tools.
1) Subscribe to the GitHub repo for tag/release updates.
2) When I get a notification of a new version, I run a shell function (meup-uv and meup-ruff) which grabs the latest tag via a GET request and runs an install. I don't remember the semantics off the top of my head, but it's something like:
Of course this implies I'm willing to wait the ~5-10 minutes for these apps to compile, along with the storage costs of the registry and source caches. Build times for ruff aren't terrible, but uv is a straight up "kick off and take a coffee break" experience on my system (it gets 6-8 threads out of my 12 total depending on my mood).
Tools like Flatpak, AppImage, Snap, Toolbox, and Distrobox can go a long way on relieving the end-user of the burden of trying to get things playing nice in those situations. Not always a silver bullet, but a useful tool to keep in the back pocket.
If it's FOSS, at least you have the option of trying to repackage it for your distribution. You're SOL if it's a proprietary application distributed in binary format.
, though.
Something I don't yet understand about flatpak et al: isn't using that for every app in the core OS experience going to chew through storage because shared libraries can't be shared across images? Or does the containerization solve that problem?
Modern storage is at least hundreds of time bigger than when shared libraries were common to save space. Every single executable having its own copy of GNU C Library isn't a big deal.
But they have to be mapped into RAM, right? And if the OS can't unify those distinct images because they're in different paks, isn't my RAM now being eaten up by clone static data that I could instead be using for actual work?
I can't speak for the others, but Flatpak is a layered solution, so files are deduped and shared across the layers (runtimes, applications) that need them.
Ah, good point. That feels win-win then; package maintainers get a huge efficiency win by just synchronizing on their base packages but they're not locked to them so they can make things work without littering up the user's global library space with oddball versions of dependencies.
I'm still hopeful that RHEL will find a way to integrate dnf system-upgrade in the future, but it's not a trivial undertaking. As long as the transaction can resolve cleanly, it's technically possible to do. But it doesn't mean you'll have a properly configured system when it boots up. Tools like leapp and its derivatives (ELevate) do a bit more under the hood work to ensure a complete upgrade. Fedora itself only ever supports and tests up to a two version bump for system upgrades, e.g. 40 -> 42, 41 -> 43, etc. RHEL major releases are jumping (at minimum) six Fedora releases.
Former Hatter here (Solution Architect Q2 '21 -> Q4 '22). Other than the discussions that took place around moving the storage/business products and teams under IBM (and the recently announcement transfer of middleware), I wouldn't have expected engineering to do that much interfacing with IBM. At most, division leadership maybe (this is just personal speculation). Finance and Sales on the other hand... quite a bit more.
We had a really fun time where the classic s-word was thrown around... "s y n e r g y". Some of the folks I got to meet across the aisle had a pretty strong pre-2010 mindset. Even around opinions of the acquisition, thinking it was just another case of SOP for the business and we'd be fully integrated Soon™.
They key thing people need to remember about the Red Hat acquisition is that it was purely for expertise and personnel. Red Hat has no (or very little) IP. It's not like IBM was snatching them up to take advantage of patents or whatnot. It's in their best interest to do as little as possible to poke the bear that is RH engineering because if there was ever a large scale exodus, IBM would be holding the worlds largest $34B sack of excrement we've seen. All of the value in the acquisition is the engineering talent and customer relationships Red Hat has, not the products themselves. The power of open source development!
It's heartening to hear that your experience in engineering has been positive (or neutral?) so far. Sales saw some massive churn because that's an area IBM did have a heavier impact in. There were some fairly ridiculous expectations set for year-over-year, completely dismissing previous results and obvious upcoming trends. Lost a lot of good reps over that...
Red Hatter since 2016, first in Consulting, now in Sales.
Oh the “synergy” rocket chat channel we had back then…
Things have been changing, for sure. So has the industry. So have our customers. By and large, Red Hatters on the ground have fought hard to preserve the culture. I have many friends across Red Hat, many that transitioned to IBM (Storage, some Middleware). Folks still love being a part of Red Hat.
On the topic of ridiculous expectations…there’s some. But Red Hatters generally figure out how to do ridiculous things like run the internet on open source software.
FWIW, the change at Red Hat has always been hard to separate between the forces of IBM and the reality of changing leadership. In a lot of ways those are intertwined because some of the new leadership came from IBM. Whatever change there was happened relatively gradually over many years.
Paul Cormier was a very different type of CEO than Jim Whitehurst for sure. But that's not an IBM thing, he was with Red Hat for 20 years previously.
I agree with you FWIW. The company also basically doubled in size from 2019 to 2023. It's very hard to grow like that and experience zero changes. And COVID happened shortly after so that also throws a wrench into the comparisons.
The point is, it's hard to point to any particular decisions or changes I disliked and say "IBM did that"
I do miss having Jim Whitehurst around. Jim spent 90 minutes on the Wednesday afternoon of my New Hire Orientation week with my cohort helping to make sure all of us could login to email and chat, answering questions, telling a couple short stories. He literally helped build the Red Hat culture starting at New Hire. Kind of magical when the company is an 11K person global business and doing 5B in revenue.
Cormier and Hicks have their strengths. Hicks in particular seems to care about cultural shifts and also seems adept at identifying key times and places to invest in engineering efforts.
The folks we have imported from IBM are hiring folks that are attempting to make Red Hat more aggressive, efficient, innovative. Some bets are paying off. More are to be decided soon. These kinds of bets and changes haven’t been for everyone.
>The company also basically doubled in size from 2019 to 2023. It's very hard to grow like that and experience zero changes.
Longtime Red Hatter here. Most of any challenges I see at Red Hat around culture I attribute to this rapid growth. In some ways it's surprising how well so many relatively new hires seem to internalize the company's traditional values.
Yeah, when I left I think there were something like 7x the number of people than when I joined. You can't run those two companies the same way no matter who is in charge.
> They key thing people need to remember about the Red Hat acquisition is that it was purely for expertise and personnel. Red Hat has no (or very little) IP. It's not like IBM was snatching them up to take advantage of patents or whatnot. It's in their best interest to do as little as possible to poke the bear that is RH engineering because if there was ever a large scale exodus, IBM would be holding the worlds largest $34B sack of excrement we've seen.
We thought the same thing at VMware until Hock moved WITH THE QUICKNESS to jack up prices and RIF a ton of engineering staff.
That said, I'm in tech sales at the Hat now, and IBM is definitely around, but it's still a cool company that tries hard to treat their people right.
They also care A LOT about being an open-source company. Most of my onboarding was dedicated to this, and sales treats it seriously.
It sounds like you may have some friction-studded history with Go. Any chance you can share your experience and perspective with using the language in your workloads?
It's mostly dead locked networking code. Hard to investigate, hard to search the culprit. And of course code bases without linter for err propagation and handling. And this-null for "methods".
I wish they didn't. Outlook on macOS is abysmal nowadays and I still find myself resorting to the legacy view just to change some settings that both iterations can read but only one exposes.
I significantly prefer using Thunderbird or the web views for Gmail and Zoho Mail over any version of Outlook. Is the integration across O365 apps nice? Sure, but the platforms themselves are miserable to use.
In a similar vein, I was cautiously optimistic about Teams V2 for unifying the client. But then they completely dropped the Linux client for their PWA which does not have feature parity with the "native" platforms and has a significantly worse UX.