This isn't meant to persuade you, just sharing my own experience. I've found myself almost relying on Kagi's `Quick Answer`. Its fantastic having it off by default and being able to opt-in when I just want a quick summary of some brief search where the info cards don't give me what I want right away.
Agreed. I made a search for "big black sea bird with a name that starts with c" today, and the quick summary helped in a few seconds that Cormorant was the category I was trying to remember.
Glad I didn't have to click into results and dig through the faff, especially as there are plenty such birds.
This is a bad take. You're essentially making the claim that you shouldn't care about something unless it happens within your immediate vicinity or you are directly affected. Replace "viewed it through a screen" with "read it in a newspaper" or "heard about it from a friend" and the statement is more bad.
Revolutions have happened over less. The King of France lost his head because a small group of angry women marched on his palace, changing the course of history. Even if the net impact of this event is small, it is still _important_ and worthy of awareness.
Trump almost lost his head when they kept trying to assassinate him. His head almost got exploded on live TV and it was barely a news cycle. Dems joked about how they're mad the shooter missed, then went back to pretending they're saving democracy. That's so much worse than the guys walking around the capitol building and shuffling papers, yet people only remember the date of the great January 6th nothingburger because it's the one convenient to the establishment.
I clearly cannot speak to others. I can say that in my friend circles (very left) the _two_ trump assassination attempts were taken quite seriously and we were pulling up live feeds of it within 5 minutes of it being announced.
I generally don't subscribe to the "this event is more important than the news cycles let it be" thought. Its argument boils down to strawman or quickly circles to "news bubbles are a problem".
> That's so much worse than the guys walking around the capitol building and shuffling papers, yet people only remember the date of the great January 6th nothingburger because it's the one convenient to the establishment.
I don't think that's a fair characterization of the day. Security personnel were _murdered_ in the _capital building_. Six people died. President Trump himself labeled it as the "Save America Rally". The _stated_ goal was to defraud an election. I'm sorry, I don't subscribe to your view that it was an event blown out of proportion. It is very much just as noteworthy as every Revolution Precursor I have ever heard.
As an aside, I find the comparison of the Trump Assassination Attempt and the Jan 6 Uprising as if one is more important than the other is false. Both are very much reprehensible acts of political violence aimed at destabilizing the American institution. Bluntly, they both terrify me. That one seems "overblown" says more about your political beliefs than you think.
Are all failures traced down to the underlying design and engineering. Granted, they are famous because they are rare. I almost linked the Columbia disaster but that is sufficiently murky between engineer and management.
Btw, the cult of the professional engineer is apparently much stronger in Canada, to the point I've actually impressed women by calling myself a software engineer despite the lack of iron ring. I wonder if this makes up for them being paid peanuts?
This is me. My wife's old intel air was finally getting slow enough she was willing to replace it. Ordered a 2023 M3 Pro for her on Monday (that was even on sale!) knowing the refund window was ~2 weeks. Today, ordered a 2024 M4 Pro for the same price and better specs. (M3Pro, 512GB, 18GB ram -> M4Pro, 512GB, 24GB ram).
All that follows is from someone who mainlines linux (just mild ubuntu) and macos but wouldn't complain too much about a windows workstation.
> Hot (and perhaps tangental) take here,
Indeed.
> but I can't understand why companies that attempt to enforce these policies for security reasons, do not just mitigate their largest attack vector and move to macOS for their endpoints where possible.
Citation needed that Macos is more secure than windows.
> Far more reliable in terms of stability and security,
In my experience, macos/windows are about par for security and the "stability" also seems par. If anything, windows is _more_ stable since it is backwards compatible to a fault.
> and dramatically less patch management required for macOS clients.
Fair, but I think this is mostly a boon to IT teams who want more control from windows.
> I'd argue a more productive user experience also, instead of fighting the advertising, new AI integrations, Candy Crush and layout changes that Windows generously provides every 30 days
These concerns are not generally applicable in an enterprise environment. I feel them on my gaming machines, but corporate is generally locked down pretty tightly. Also, I mean, Macos is famously getting new AI integrations in 18.2 so this seems like a false comparison.
> Hardware is also pretty easy to resell
Admittedly this is a boon to Macos, but I think there is an argument that the cheaper windows machines may have a better full cost-of-ownership metric than macs.
> AppleCare covers replacements
Everywhere I have worked, the company pays for replacements out-of-pocket or has _very_ generous enterprise agreements.
> and the fleet can be pretty uniform with stock available anywhere if needed.
Fair. I'm not sure that it matters for enterprises that already have a locked down hardware procurement process but its pretty hard to argue against the 2023MBP16GB is more uniform than {windows soup}.
> Keep incompatible apps that are required in a Citrix Workspace or equivalent for isolation. This doesn't address social engineering or file leaks due to malicious employees obviously.
I'm not sure what you're saying here, but I'm hard pressed to see how this applies to any specific OS and not others.
I worked on my first (and my company's first) hardware product and the HTS regulations were absolutely eye opening. I lived my entire life without knowing about it until I had to actually deal with import/export of a product. It is mind numbing dealing with it. Correctly discovering, interpreting, understanding, categorizing, and conforming with the worldwide process is its own form of career specialization (and hell). No thank you, never again.
"A union of Software Engineers lets us collectively bargain for better working conditions, such as flexible working locations, reducing PTO request denials, and work-life balance conditions."
Thank you for pointing me towards the design document. Its well written and I missed it on my first pass through the repository. I genuinely found it answered a lot of my questions.
I can't help myself. The grandest of nitpicks is coming your way. I'm sorry.
> If you give me a computer timestamp without a timezone, I can and will assume it's in UTC.
Do you mean, give you an _offset_? `2024-04-29T14:03:06.0000-8:00` the `-8:00` is an offset. It only tells you what time this stamp occurred relative to standard time. It does not tell you anything about the region or zone itself. While I have consumed APIs that give me the timezone context as part of the response, none of them are part of the timestamp itself.
The only time you should assume a timestamp is UTC is if it has the `z` at the end (assuming 8601) or is otherwise marked as UTC. Without that, you have absolutely no information about where or when the time has occurred -- it is local time. And if your software assumes a local timestamp is UTC, then I argue it is not the sender of that timestamp's problem that your software is broken.
My desire to meet you at 4pm has no bearing on if the DST switchover has happened, or my government decides to change the timezone rules, or if {any other way the offset for a zone can change for future or past times}. My reminder to take my medicine at 7pm is not centered on UTC or my physical location on the planet. Its just at 7pm. Every day. If I go from New York to Paris then no, I do not want your software to tell me my medicine is actually supposed to be at Midnight. Its 7pm.
But, assuming you aren't doing any future scheduling, calendar appointments, bookings, ticket sales, transportation departure, human-centric logs, or any of the other ways Local Time is incredibly useful -- ignore away.
As I mentioned in another reply, "remind me every day at 7PM" isn't a timestamp. It's a formula for how to determine when the next timestamp is going to occur. Even those examples are too narrow, because it's really closer to "remind me the next time you notice that it's after 7PM wherever I happen to be, including if that's when I cross a time zone and jump instantly from 6:30PM to 7:30PM".
Consider my statement more in the context of logs of past events. The only time you can reasonably assume a given file is in a particular non-UTC TZ is when it came from a person sitting in your same city, from data they collected manually, and you're confident that person isn't a time geek who uses UTC for everything. Otherwise there's no other sane default when lacking TZ/offset data. (I know they're not the same, but they're similar in the sense that they can let you convert timestamps from one TZ to another).
> As I mentioned in another reply, "remind me every day at 7PM" isn't a timestamp. It's a formula for how to determine when the next timestamp is going to occur. Even those examples are too narrow, because it's really closer to "remind me the next time you notice that it's after 7PM wherever I happen to be, including if that's when I cross a time zone and jump instantly from 6:30PM to 7:30PM".
That's certainly fair in the context of a recurring event with some formula. I caution that a lot of people will still immediately reach for timestamps to calculate that formula, particularly for a next occurrence, and in the context if this conversation they would be given as an ISO8601 datetime based on Local Time. I would also caution that calendar events that have a distinct moment in time that they start are also prime for Local Time where a UTC-default mentality will cause errors.
> Consider my statement more in the context of logs of past events
From the stance of computer generated historical log data, I definitely agree that UTC everywhere is a sane default and safe to assume :)
(And, in your defense, I would definitely argue UTC-everywhere gets you 95% of the way there for 5% of the effort... I get why people make the tradeoff)
> (I know they're not the same, but they're similar in the sense that they can let you convert timestamps from one TZ to another).
More nitpicking on my part, again, I'm sorry, it lets you convert from one _offset_ to another or from an offset to UTC. Think Arizona being a special snowflake who (mostly!) doesn't observe DST. You can't assume all UTC-7 offsets are all Mountain Time.
It's always nice to see someone who actually understands time.
"Convert to UTC and then throw away the time zone" only works when you need to record a specific moment in time so it's crazy how often it's recommended as the universal solution. It really isn't that hard to store (datetime, zone) and now you're not throwing away information if you ever need to do date math.
Yeah, I've been trying to convince people forever to store time zones with timestamps when appropriate. If you record events from around the world and don't record what time zone they happened in you can't even answer basic questions like "what proportion happened before lunch time?"
People love simple rules and they will absolutely take things too far. Most developers learn "just use UTC!" and think that's the last thing they ever need to learn about time.
