I have Windows and Mac PCs/laptops. I've used Windows since Windows 3.0, for 30+ years now. In the early 90s I invested in Windows NT 3.5 as a college student and learned how to use that over Windows 3.1 or OS/2. I attended the Windows 95 celebration in person. I almost went into becoming a Microsoft MCSE because it would have doubled my pay but went the programming route instead because I loved it more.
I'm still on Windows 10. Fuck you Microsoft for making Windows 11 worse than Windows 10. The simple fact I can't stop them from updating my Windows 10 machine and it reboots my machine makes me so angry that's one of the main reasons why I will never upgrade. Microsoft Recall is a non-starter for me, even though they made it "better".
If they force me to upgrade, I'll move entirely to Mac and install Linux on my current Windows desktop.
The biggest security threat any country has is if an adversary sends 1-10 million drones at once, each with a small grenade on it, and overwhelms a city. They could literally target individual politicians or weak spots on infrastructure like buildings or bombs and almost nothing could stop it except possibly an EMP.
I'm not sure what anyone can do about that but that to me is my biggest fear about the future of all this technology.
1-10 million drones. At $400 a pop that’s $400,000,000-$4,000,000,000. A lot to throw at a single attack when you don’t actually know what defenses are in place. Maybe there is an EMP. Are you willing to spend a billion dollars to find out, while also murdering hundreds of thousands of civilians?
And these are either autonomous drones (more expensive?), or fpv with the fiber optic line out the back - either way you have to get them in range without being detected somehow.
In short, i think this is an unrealistic scenario - fun to imagine as a horror-sci-fi idea but unlikely to be deployed. Just one opinion.
This isn't a game of Command and Conquer with fog of war turned on. Of course they would have intel on exactly what they are going to attack. One cruise missile is about $4 million.
China already has created a UAV that is designed to launch at least 100 drones. If they can make that 1000 drones and then fly out 1000 of these motherships at one time, that's already 1 million.
And yes the drones would be autonomous, there's no reason for any person to be controlling them in the age of AI.
So then my $400/each price tag is wrong - it’ll be much higher. If nothing else, the high price of gpus and ram might be saving us from an attack like this lol.
But also, 1000 carrier drones is a lot easier to shoot down than 1mil drones.
An attack like this might not be today, but in 10-20 years? If a country can develop this technology where multiple cities or military bases are completely overwhelmed by a swarm of drones, and all the politicians and generals are taken out by AI-controlled drones, why wouldn't they invest in it? As far as I can tell, unless some sort of localized EMP is developed, I don't know how an attack like this can be stopped. Maybe some sort of RF beam but I'm sure the devices can be shielded from that.
It's much more effective than a cruise missile because you can just blow up weak points on bridges, buildings, take out entire military bases, etc. Even 1000 of these drones would be extremely effective but 1 million would be devastating.
> all the politicians and generals are taken out by AI-controlled drones, why wouldn't they invest in it?
Because that’s an abhorrent thing to do. Because then you have to occupy people who don’t want to be occupied. Because the nation you just destroyed has allies who have the same weapons. Because that nation has the same weapons. Because killing “all the politicians and all the generals” will become impossible immediately after the first time this is used - assuming it’s not already impossible today.
Jets aren’t single-use. A better comparison would be something like a tomahawk missile, which costs ~$2mil each (not counting r&d costs, launcher costs, getting them there costs, etc).
The US spent $11.3b in the first six days of israel’s war with iran. So not an unprecedented amount of money, just a lot to put into a single attack that could fail, and that mostly kills humans, and that requires a shit ton of logistics to make happen.
Right now one of the limits is just controlling that many let along sourcing it. Putting that many actively controlled drones in one area at once and you'll swamp the bandwidth.
The drones in Ukraine largely use miles-long spools of fiber optic cable, so while I agree that sourcing is a problem, bandwidth likely isn't. If you want to be creative there's probably a bunch of hybrid wireless/wired/semi-autonomous configurations that would allow for minimizing bandwidth requirements in practice, but it would still fall apart as soon as a reasonably powerful jammer is turned on.
Feels like a massed attack using fiber optics would have lots of problems with drones getting tangled in the cables of those in front of/above them or cutting the cable. The trouble with making them autonomous in a city is that means more sensors and compute on board which raises the cost. It's a hard problem.
They would just be autonomous. Setting a GPS (or alternate system) coordinate is pretty simple enough. Individual targets could just be AI controlled at this point, or 10 years in the future.
Author must not have worked in enterprise software before.
That's a classic trick where the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. And if it doesn't get confirmed then they can close it as User Error or Not Reproducible.
Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.
From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").
I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr.
Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.
I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.
puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hat
My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see".
Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team.
They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever.
Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence.
If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."
It'd kind of sad, how the market went. I suppose there are pluses too.
But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items.
Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet.
On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail.
I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes.
Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
It really depends, support is usually the first thing companies adjust when they want to improve their margins.
Even when you're paying millions to AWS you have to get through their first line of support and they will ask silly questions until you can convince them to escalate.
Not really, you get "really dedicated support" at most, but not a "really good" one, otherwise all those decades-old bugs common in many software producs would've been fixed since they affect people at all tiers
Back then, computers didn't had competition from the analog world, so vendors had to provide excellent service such that users would be convinced into switching over to the digital way if doing things. Now comouters have a monopoly on how we work and live, so vendors care as little as possible.
This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug.
And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work.
Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.
That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company.
When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.
It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion. Triage, filtering, and winnowing are necessary here.
I got a lot of those too, it meant I inevitably did a little bit of free tech support for my customers. In the end I felt it was worth it as they raved about the quality of support and it was a real differentiator - not to mention built a lot of brand loyalty (and internal staff loyalty too once I grew enough to build out a team - they derived real satisfaction from actually solving problems instead of playing ping-pong).
I agree regarding the need to triage at scale, unfortunately most large companies I've encountered fail to do this well and seem ill-equipped to accept high quality bug reports of edge case defects generated by expert users (save for the odd exception that arrives by social media from someone who happens to have enough followers to get their attention outside the regular support pipeline).
In my experience this doesn't usually boil down to a systems issue (the ticketing systems etc. exist that should theoretically allow for eventual escalation to the right engineer/developer) but a corporate culture thing (the company just doesn't prioritize customer feedback especially at the level where staff who actually deal with customers interface with the teams that write/maintain the software). Often it's genuinely valued at the C-level (the Bezos story of calling Amazon"s tech support line during an exec meeting is a fun example) but diluted somewhere between them and the rank-and-file.
(Ps. I'm not arguing with you and appreciate you took the time to craft a thoughtful reply)
It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.
My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs.
If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning.
You could say: "but have pride in your work!"
But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.
What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.
Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it?
My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make
There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.
You’ve just described AGILE development, a way for product owners to backlog code rot while empowering developers to feel like they have a say in things.
Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.
I totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs.
Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.
There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned.
You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.
Quite often reproduction information will only reproduce the bug in the customers environment, hence there is a lot of incomplete state on what is actually causing the problem.
It's pretty terrible in enterprise because there is so much 3rd party crap touching things it shouldn't that love to cause fun problems.
There's obviously some nuance here, but the fact is that much modern software is riddled with bugs, and this is sub-optimal for everyone (both software users and software builders). Most of the bugs which frustrate and irritate software users are not due to uncontrollable events such as cosmic rays flipping a bit. Most of them are plain old code defects.
But, you do have a valid point. Allow me to rephrase it this way: The answer is not for software companies to spend unbounded amounts of engineer time chasing every reported bug.
But there are ways that we, as an industry, can do better, and it's not by pouring all our time into chasing hard-to-diagnose bugs. Here are a few ways that I personally see:
1. Some very powerful technologies for finding many bugs with little engineering effort already exist, but are not widely used. As an example, coverage-guided fuzzing is amazingly good at finding all kinds of obscure bugs. The idea of coverage-guided fuzzing was known from the 1990's, but it took AFL (in ~2013) to take it mainstream. Even now, much of the industry is not benefiting from the awesome power of coverage-guided fuzzing. And there are other, equally powerful techniques which have been known for a long time, but are even less accessible to most software developers.
So: spread the word about such techniques, and for programming language/platform developers, work on making them more easily applicable. This could help many software companies to catch a great number of bugs before they ever go to production.
2. Similarly, there are extant historical computing systems which had very powerful debugging facilities, much better than what is currently available to most developers. The ideas on how to make our platforms more debuggable are already out there; it's now a matter of popularizing those ideas and making them readily accessible and applicable.
3. Since it's widely known that many bugs (real bugs, not "cosmic rays") are extremely hard to reproduce, an admirable target for us to aim for as developers is to implement debug logging in a way which allows us to root-cause most obscure bugs just by examining the logs (i.e. no need to search for a reproducer). Some real-world systems have achieved that goal, with very good results.
4. While there is currently much buzz about using LLM-based coding agents to write code, I think an almost better use case for coding agents is in triaging bug reports, diagnosing the bugs, finding reproducers, etc.
I've recently had a couple of shocking experiences where, just given a written description of an intermittent, hard-to-diagnose bug, a coding agent was able to search an entire codebase, identify the exact cause, and write a reproducer test case. (And this after multiple experienced human programmers had looked at the issue but failed to identify the cause.)
In summary, I think there are ways to "cut the Gordian knot" of bug reports.
What if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes?
That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goose chase.
Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.
> Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.
Right. The problem isn’t closing the ticket, it’s pretending more work is happening than actually is.
“Needs verification” is fine if someone has actually tried to reproduce it. Otherwise it’s just a nicer way of saying “we’re not going to look at this.”
Most of the time, there isn't any reason to believe it could be fixed, i.e. there were not any non-trivial changes around that area. What you're describing happens less frequently, and in such cases, the devs should discuss that with the reporter.
In this specific example, it looks like Apple gave no indications that such changes had happened, and no indications they had even spent a nonzero amount of effort following the reproduction instructions with either the old code or the new code.
"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly acknowledge that, your bug will be closed automatically in 30 days. Thank you very much"
> For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it
This reminds me of a fairly old but famous story about ignoring bugs from Linux users. I couldn't find the HN post but here's slashdot
| Though only 5.8% of his game's buyers were playing on Linux, they generated over 38% of the bug reports. Not because the Linux platform was buggier, either. Only 3 of the roughly 400 bug reports submitted by Linux users were platform specific
The short is that they initially ignored it, triaging, but it was a mistake. Especially since the culture of Linux users is to submit more detailed bug reports. That their submissions help general users.
Don't just a bug report by its cover, judge it by its merits. We're all biased to dismiss them and find an excuse to ignore them. But that just leads to bad software.
Funny you mention Microsoft because I used to see bug reports for Windows. I can tell you there was a ton of low quality "SOMEONE HACKED MY COMPUTER" or similar feedback (and sometimes just unintelligible ranting) that was completely inactionable or unreproducible. I otherwise do agree with your premise that large monopolistic businesses can sit on large swaths of feedback without worrying about competition - and that this is a problem.
However, for most software projects and businesses, the lack of repeated feedback is a signal that the issue isn't important.
As a user I would hope that the software author/publisher is prioritizing important problems. Closing one ticket is not indicative of organizational rot, as you say.
Yeah competition works. I don't like nexus that much but they accept every ticket I've opened and fix it the next release. Two things I think affect that. One, my ticket has the name of a fortune 100 next to it. Two, artifactory will eat them alive if they don't keep customers happy.
> this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities.
You can triage without closing tickets. So it is nefarious. It is metric hacking
If you're having trouble reproducing, tag "needs verification" or something else. But closing a ticket isn't triaging, it is sweeping problems under the rug
It's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.
I’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work.
Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.
Careful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.
The cost/benefit framing makes sense for an individual ticket, but it breaks down at the portfolio level. The developers filing detailed, reproducible bug reports are your highest-quality signal — they've done half the diagnostic work already. The verification dance disproportionately discourages exactly those people, because they're busy and they know their time has value.
The developers who keep jumping through hoops are often less technically sophisticated users who click "yes I reproduced it" without actually testing. So you end up with a feedback channel optimized for closing tickets, not for surfacing real problems. High-signal reporters get filtered out, low-signal confirmations pile up.
The Chromium team gets this right by assigning someone to reproduce reports before asking the filer to do anything. More expensive upfront, but the signal quality is far better and the developers who actually know what they're talking about don't give up after the first round of pushback.
I can sort of back that for desktop apps but telemetry is so trivial for webapps needing a reproducer is almost an embarrassing admission the operator has no clue what they're doing.
Error tracking and tracing make it fairly straight forward to retroactively troubleshoot unreproducible issues.
The telemetry is almost always not voluntary and neither is the relation ship with the companies in the first place unless you mean that technically you could become a hermit living in the woods.
Or even non-software tickets at large corporations. I reported a water dispenser filling too slowly at my office because it took me a few tries just to fill my 1L water bottle. They said it was fixed and closed it.
It was not fixed. So I took a video of myself refilling my water bottle, attached it to the ticket, and re-opened it. They actually fixed it after that. The video was 2m12s long (and I spent god knows how long making the video file small enough to attach to the ticket lol)
this is actually a good example of how a more detailed issue will have a higher chance to be addressed. I don't know what information that's your previous report is lacking, but the video certainly give more information that the maintainer can pinpoint the cause and act on it. The ability to pinpoint the cause from the report is a godsent for maintainers, it drastically reduce the time to investigate the cause, thus able to act immediately.
Some of the information in this can may be:
* how "slow" exactly the process is related with normal behavior. If it's just said "slow" on previous report, it's easy to be dismissed
* the dispenser's behavior, such as if the water flow is consistently low volume or clogged intermittently, or if the dispenser is struggling to fetch from water source, etc
I'd say it was both. I gave a pretty detailed explanation before, far more detailed than my post here, including a timeline of when it filled in one shot, then two shots, and then three or four (can't remember). I doubt they actually checked before the video. But I was very motivated to fix the issue so I gave them proof lol
More importantly it shows how the reporter actually used the system to trigger the undesired behavior. Just because something is obvious to you doesn't mean it will be obvious to whoever is looking at the bug report.
As an open source maintainer, I feel that statement is really unfair. Yes, we do sometimes close bug reports without evidence they are fixed. But:
- We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.
- Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed. That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.
It's not about expectation of work (well, there's some entitled people sure.)
It's about throwing away the effort the reporter put into filing the issue. Stale bots disincentivise good quality issues, makes them less discoverable, and creates the burden of having to collate discussion across N previously raised issues about the same thing.
Bug reports and FRs are also a form of work. They might have a selfish motive, but they're still raised with the intention of enriching the software in some way.
IMO closing issues via stale bot is fine, the problem is locking issues so that no further conversation is allowed on the issue. Multiple times, I've encountered multi-year old issues (which is usually not fixed due to the fix not being simple or compatible with the current architecture). There's usually a good amount of conversation between users offering workarounds (and those workarounds updated for newer versions) - till stale bot locks the issue.
This 1000%. Whoever came up with the idea of closing and locking issues because no one has posted on them for awhile is at best not all that bright and at worst downright sinister.
Closing an issue due to staleness is one thing, locking it is another.
> That means that when we close the issue, we believe it has a high chance of being fixed
I agree with this iff it's being done manually after reading the issue. stalebot is indiscriminate and as far as "owing" the user, that's fair, but I'd assume that the person reporting the bug is also doing you a favor by helping you make things more stable and contributing to your repo/tool's community.
I partially agree, but even with stalebots nobody is measuring the maintainers' productivity. So when they made the choice to use stalebots, they did that because they believe that's best for the project. It's different from corporate.
Nobody is measuring their productivity, but people definitely look at how many open issues they have and potentially how long those issues have existed. They’re likely incentivized to close issues for appearances.
With a popular open source project, you'll quickly get to a number of bug reports that you have no chance of ever solving. You will have to focus on the worst ones and ones affecting most users.
At the same time, you want to communicate to users that this is the case so they don't have wrong expectation. But also, psychologically it is demotivating to have a 1000+ open bugs queue with no capacity to re-triage and only two maintainers able to out a few fours in every month or every week.
In open source, "won't fix" means either "not in scope — feel free to fork" or "no capacity ever expected — feel free to provide a fix".
The optimization problem is how do you get the most out of very limited time from very few people, and having 1000+ open bugs that nobody can keep in their head or look for duplicates in is mentally draining and stops the devs from fixing even the top 3 bugs users do face.
The problem is that your users also have limited time and if it's clear you're not even looking at issues where someone has put in lots of effort to help you then you're only going to get lazy issues and it will actually take more effort from you to do all that work yourself if you want to reach the same software quality.
I think you are missing the point: a user putting in a lot of effort into a bug report is usually trying to help themselves get the bug fixed.
As a maintainer, you will obviously look at that bug with more appreciation: but if you estimate it will take you 3 months of active development to fix it that you will have to spread over a full year of your weekends (which you can't afford), what would you do?
And what would a reasonable user rather see? Yes, this is an issue, but very hard to fix, and I don't have the time, or just letting the bug linger?
> We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.
Users also don't owe you anything either. Auto-closing reports without even looking at them is like asking for donations only to throw 90% of what you get straight into the trash. Not cool. If you don't want bug reports, state that up front or at least leave bugs open for other users to see and talk about. Otherwise, users are free to warn others to stay away from you and your projects.
And that's before getting into more complex issues like what responsibility you have if you take on maintenance of existing software and end up breaking something what was working perfectly for some users.
> Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed.
There are plenty incentives, e.g. pride.
> That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.
That's fine, but bots that auto-close issues unless the reporter dances for them is the opposite of that.
I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.
> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.
I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.
I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare.
I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.
If you are a veteran of software in a big company, we all know there will be weekly or bi-weekly meetings that some PM will set up. All the PM will do is go over the JIRA tickets and be like "is this still happening". Default answer is "no", as in "I didn't even try to reproduce it, do you think I have time to even do it?". Default answer by spineless QA person is also "didn't try it again yet". Then, the PM closes the ticket. It is much easier for QA person to say "Yes I verified it" if you are remote and developer cannot see the lies on your bad poker face.
Ooh this gives me an interesting passive-aggressive idea to counter pointless "is this still relevant" questions. "No, I haven't hit this in the last 2 days." "No, I haven't hit this since I gave up trying to do it with your tool." And so forth.
The less passive-aggressive version is to use this obviously-unhelpful answer of the obviously-unhelpful question, to actually have a conversation to get the PM to recognize that the default state of a ticket is in fact "no change." Ultimately that may turn into a stale bot if the PM realizes the policy they actually want is some sort of timeout, but at least it's not a time consuming meeting!
(Note, a cathartic thought experiment, but not really good manners to actually do!)
I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.
> the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything.
We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system.
That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.
Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.
I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.
I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.
Hi, bigcorp employee getting showered with tickets here.
I don't have enough time in the day to deal with the tickets where the reporter actually tries, let alone the tickets where they don't.
If I tell you to update your shit, it's because it's wildly out of date, to the point that your configuration is impossible for me to reproduce without fucking up my setup to the point that I can't repro 8 other tickets.
Back when I worked at Apple I would just try it in whatever I had installed. If it didn't reproduce I'd write "Cannot reproduce in 10.x.x" and close it. Maybe a third were like that, duplicates of some other issue that was resolved long ago.
Anyone that attached a repro file to their issue got attention because it was easy enough to test. Sometimes crash traces got attention, I'd open the code and check out what it was. If it was like a top 15 crash trace then I'd spend a lot longer on it.
If the ticket was long and involved like "make an iMovie and tween it in just such and such a way" then probably I'd fiddle around for 10-15 minutes before downgrading its priority and hope a repro file would come about.
There were a bunch of bug reports for a deprecated codec that I closed and one guy angrily replied that I couldn't just close issues I didn't want to fix!
Guess what buddy, nobody's ever going to fix it.
The oldest bug like that I ever fixed was a QuickDraw bug that was originally written when I was 8 years old but it was just an easy bounds check one liner.
But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.
> But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.
Except this same shit keeps happening with multiple teams.
Judging from your mention of QuickDraw, which was removed entirely from macOS in 2012, perhaps your Apple experience is now out of date.
> That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculou
It's pretty clear from experience that the organization policy is to not provide feedback on bug submissions. Getting a 'check it if still reproduces or we'll close it in two weeks' message after 3 years is actually a fast turnaround.
Best I've gotten was on an issue I routed to a friend who worked at Apple who promised it would get looked at, but that I wouldn't hear back.
Microsoft wouldn't fix my issues either, but at least they got back to me in a timely fashion. Usually telling me it was a known issue that they weren't going to fix.
You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company.
Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps.
But sometimes that duplicate marking is wrong or some subtly different issue so they ask you if it still reproduces in whatever version contains the fix before closing it.
That makes sense. But when you take 3-5 years to respond to my bug report, I'm going to take at least 3 months to respond to your response. And I'm probably not filing more bugs, because chances are I won't be at my current employer by the time you reply.
When you consitently burn bug reporters, sooner or later there's nobody to file bugs.
Because that's probably how long it took for someone to prioritize it.
Even if it's not fixed by the dupe ticket, the volume of bug reports makes it almost certain another ticket for the same issue will come up. And if it doesn't then it probably wasn't that relevant to anyone.
Not my tickets specifically. I don't think they're out to get me individually. On the contrary, this is a common practice, which affects many developers. I just happen to be relatively loud, as far as blogging is concerned.
Yes I understand that. ~50000 engineers aren't conspiring to close all tickets that way. It's a stupid line of thinking.
More than likely your steps to reproduce are too laborious to receive attention relative to the value fixing the bug would provide. That's why they're asking you to verify it still happens. Seems pretty simple right?
There's also a strong chance your ticket was linked as a duplicate of some other issue that was fixed in the beta and they want you to verify that's the case but they won't expose their internal issue to you for a variety of reasons.
> ~50000 engineers aren't conspiring to close all tickets that way.
I didn't say that either. It's happened to me only sporadically, but multiple times.
I agree with you that teams within Apple manage their own tickets. Perhaps some individual teams are declaring bug bankruptcy at some point, so only their bugs would go out for verification. I don't really know. I wish I did. What I do know is that multiple teams have done this at different points.
There's indisputably a company-wide DevBugs canned response for this. It's the same exact language every time. You can even Google it.
I think that's entirely dependent on the workload the company is placing on their support staff. If Apple decides the techs should be handling 10 tickets at once, then the techs have a choice:
1. Tell everyone to update their shit, and close tickets if they don't.
2. Waste several hours per day uninstalling and reinstalling 10 versions of the same program.
One of these will allow you to close lots of tickets immediately, and handle the remaining ones as efficiently as possible. Yay! Good job, peon! You get a raise!
The other approach will result in a deep backlog, slow turnaround times, and lower apparent output from management's perspective. Boo! Bad job, peon! You're fired!
Please tell us where you work so we can avoid all of your company’s software. Unless it’s Microsoft, because we’ve already seen the results of that attitude there.
I don't see how it's an unreasonable request. If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically. You will be prioritized last, because my effectiveness is measured by how many tickets I close.
They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.
> If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically.
You completely missed the point of the blog post. Apple was in the process of developing macOS 26.4 beta 4, and they wanted me to install the beta just to "verify" the bug.
Apple could test my bug with 26.4 beta 4 a heck of a lot easier than I could. Nobody was asking Apple to install some ancient version.
> my effectiveness is measured by how many tickets I close.
That was one of the points of the blog post: this is a perverse incentive from management.
Note what you did not say: "my effectiveness is measured by how many bugs I fix." So engineers are incentivized to close tickets even if the bugs they report are unfixed. This is how a company ends up with crappy, buggy software.
The parent comment is talking about the broader practice of people telling you to update and then repro again. That's a completely legitimate thing to ask, given both the perverse corporate incentives and the basic reality that version toggling makes a tech far less efficient at solving all tickets, not just yours.
I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical.
A bug is a bug, no matter the developers' opinion or the complexity of the bug.
However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.
Sure. But I'm biased because I was a "customer" of a former (large) company's products while also working at that company. So the bugs I would file were the type that a customer would file, but since I was inside, I saw how they were handled. The tactics that my fellow R&D developers would do to claim something wasn't a bug or reproducible were nearly endless.
I mean if the customer stops complaining, either the bug was fixed, or the bug was not too important to begin with, or they are not a customer anymore and nobody else cares about that niche bug. In all of the above closing the ticket sounds reasonable.
What is not reasonable is that they close issues with thousands of “I have this issue too” with active complains and full repros
I've been using Mac for 15+ years now. I thought I would hate Glass so I avoided installing it across my ipad, phone, etc. But it was forced on my on my work laptop. Overall I don't notice the difference. There's nothing that outrages me, but I do find the changes useless.
> who would ever want to scroll only AI generated videos over a combined feed?
I guess you haven't watched hours of AI cat videos cheating on their husbands with bulls, or Lemons having babies with strawberries and fighting over custody of the child. It's absurd, it's stupid and I know it's a waste of time but I have to admit that it amuses me. I'm quite sure there are millions like me that just want some downtime to relax at the end of the night and end up watching slop like this.
Look how many people couldn't care about Epstein and the fact he was a convicted sex offender. Bill Gates didn't care and he was literally the richest person in the world at one point.
The rich VCs and billionaires and aspirational billionaires only care about doing what they want to do and don't care what the peons like us think or care about.
Canadians have no rights that the government can't override, unlike the US where the Constitution grants God-given rights over and above the government. Pierre Trudeau built in a safeguard so that the Canadian government or provinces can override whatever rights they want as they deem fit. They also have the War Measures Act or the Emergencies Act which they've also used to override any rights that Canadians have.
But none of that matters if Canadians just allow politicians to impose laws that strip them of their rights to avoid mass surveillance. Who needs a Charter of Rights if Canadians don't care enough about their rights to protest the government when they try to strip away their rights?
While it's true that Section 33 of the Charter can override other sections, it cannot override _all_ of them; and the Emergencies Act is roughly equivalent in effect to the USA's ability to deploy the National Guard. It allows the Federal Government to deploy our military to handle emergencies when it is apparent that Provincial and local services are unable to handle them.
No. The Emergencies act/War Measures act allows the government to override whatever rights they want. And it's been used twice in history to do exactly that.
What it's supposed to be for is in direct contrast to what it was used for, which is to suspect rights. And that's exactly what was determined later on by the courts that they did infringe on the rights of Canadians.
It really doesn't allow _any_ rights to be overridden. It's rather clear in its scope,[0] and while it's true that our justice system has taken the Government to task when it has exceeded the scope[1] it's not as though this is a regular occurrence or that those harmed by the excess are without legal recourse.
How was Trudeau held accountable besides a small slap on the wrist? And regardless the Notwithstanding clause is more than enough to extinguish anything in the CoR.
This gets at the concept of accountability for those at the top of government. This is an issue in all governments, not just in Canada. A good parallel would be the United States. The list of actions the current administration has taken which have been determined illegal is astounding, yet no one is held accountable in a way that would deter future breaches of the law.
It's not just the Notwithstanding clause. There's a general judicial tradition in Canada of utterly ignoring or dismissing or excusing blatant, objective violations of the constitution itself. Some examples:
1. in Cambie Surgeries Corporation v British Columbia (https://en.wikipedia.org/wiki/Cambie_Surgeries_Corporation_v...), where a private clinic challenged the province's ban on any private care whatsoever for procedures that are provided by the public system on the grounds that if the province bans procedures but then also rations access to those procedures to the point that they're inaccessible for many patients, it constitutes a violation of our charter right to life and equal protection.
It seems they were able to successfully argue that this does constitute a violation of our rights, but the decision says it's okay because it's done with the intent to preserve the equitable access to healthcare for the general public.
2. Employees in union shops are forced to join the union. This is arguably a violation of our right to freedom of association, but the supreme court says that it's okay if it does because "the objective of this violation is to promote industrial peace through the encouragement of free collective bargaining". https://en.wikipedia.org/wiki/Rand_formula#Freedom_of_associ...
3. https://en.wikipedia.org/wiki/R_v_Comeau, a famous case where a guy bought beer in Quebec and drove it to New Brunswick (for personal consumption) and was fined. His case argued that that's a violation of section 121 of the Canadian Constitution 1867 which states as black and white as can be:
121 All Articles of the Growth, Produce, or Manufacture of any one of the Provinces shall, from and after the Union, be admitted free into each of the other Provinces.
But the Supreme court ruled that it's not enough for provinces to ban goods from entering their province for it to count as a violation, it must be a ban which has no other purpose but to impede interprovincial trade. But that means that this section is completely useless because a justification for protectionism can always be found or made up on an ad-hoc basis.
Basically, Canadians have no rights whatsoever. Our entire legal system doesn't sit on anything fundamental it's all just vibes and arbitrary whims of the justices of the day. Our charter and constitution are so full of explicit holes like the notwithstanding clause, that they're rendered almost meaningless even on their own terms, and then any other violations will be excused on the flimsiest grounds.
#2 - Not sure why you think this is a violation. You join a workplace with a union and gain all the benefits from collective bargaining, so yeah, you should pay for union dues.
You say that I gain all the benefits from collective bargaining but I had no other choice. Maybe I don't even like the contract very much and would have bargained for other things than what the union negotiated for. The union claims to negotiate on my behalf but if they really respected me they would give me the ability to opt out.
Your hypothetical isn't even always the case. When unions form, usually there are employees there that don't want to subject themselves to the union, but are forced to, so they didn't "join a workplace with a union" at all.
(1) we have reasonable limits on all our rights, thanks to Section 1; this is rooted in our history of Toryism and ensures that the rights of the individual are balanced against the well-being of society. This is contrasted against how the USA puts the rights of the individual before the well-being of society, no matter what the consequences are and have been.
(2) Again, we balance the well-being of society against individual rights. In this case, defending collective bargaining is a reasonable action when considering that there is _plenty_ of other opportunities for work. Don't like unions, don't join one and find work elsewhere.
(3) Per the court ruling, Canada does not have a guarantee of internal _unlimited_ free trade; it only prohibits tariffs on internal trade. Whether or not that is a good thing is hotly debated, and a matter of current policy.
> Our entire legal system doesn't sit on anything fundamental it's all just vibes and arbitrary whims of the justices of the day.
It's Common Law, not Civil; and so it's based on layers of legislation and court proceedings.
In practice, we have plenty of strong protections for our rights, but those protections break down when our behaviour becomes harmful to broader society. Whether or not you think that's a good thing probably indicates where you are on the line between classical liberalism and toryism.
>unlike the US where the Constitution grants God-given rights over and above the government.
Why don't you ask the folks in towns riddled with ICE agents how well those god-given rights are being respected. Your main point stands about infringement of freedoms and privacy, but your interpretation, or hallucination that anywhere is actually abiding by their founding principals is wildly naive.
The government will always override it's citizens rights and freedoms if it has it's power challenged. 2nd amendment collapsed in California when Black Panthers decided arming themselves was a great way to push back on kkkops. 1st and 14th amendment rights get trampled and attacked at just about any protest in history.
You can talk about ideals until your blue in the face but governments have always done whatever they want and almost never face repercussion. Anything that challenges the government keeping us in place as servants of capital is met with violence and incarceration. Any social progress comes at the cost of innocent blood being spilled to make the situation distasteful enough that the government minimally acquiesces as it keeps marching down the same path it always has.
Except that's not really true, is it? It may be the flavour-text of US tradition that the government is protecting your rights rather than bestowing them, but the outcome is the same. Nor is the US government particularly fastidious about protecting them: one need only ask the average person of colour whether they feel equally protected under the law.
It is your Declaration of Independence that recognises inalienable rights endowed by one's creator, not the Constitution, and is thus legally unenforceable. We know this because none of the rights enshrined in the Constitution are actually inalienable. For example: the First Amendment says that Congress can make no law prohibiting the right to peacefully assemble... but then how does federal incarceration work? The US has one of the largest mass-surveillance apparatuses in the world despite the Fourth Amendment. The President has also attempted to end birthright citizenship via decree, something which your Supreme Court is currently entertaining instead of immediately overturning as patently unconstitutional.
There's a common refrain that rights do not exist without remedies. Whether rights are given by one's deity or by one's government is immaterial: if you cannot remedy a violation of a right, that right does not exist. While I can certainly agree that certain systems do not entrench rights as much as they should (here in the UK, all our rights persist at the whims of a simple majority), words on a page matter less than access to remedies.
Any president can go insane and go against the country’s principles. Nobody is perfectly safe from that. The issue with the constitution and declaration is intellectual: it takes centuries to completely override them. And when the president does go insane, you have the whole intellectual apparatus working against him. It is something, not just a nonexistent “remedy.”
To completely override them? Sure, but that's an odd criterion since one of the US's biggest issues is the unequal protection of rights. I have never seen a society so rhetorically obsessed with individual rights and freedoms, and yet so submissive to authoritarianism that failure to "just comply" is enough to justify summary execution in the streets (eg: Alex Pretti and Renée Good).
Again, this post is about Canada attempting to pass a bill to facilitate mass surveillance, which "freediddy" (yikes name btw) responded to by expounding upon the loftiness of American constitutional rights, as if America is not one of the most extreme mass surveillance states. It's as if Canada's attempt to pass the bill is more offensive than the mass surveillance itself, ie, it's just virtue theatre.
The difference between the US and every other country in the world is that in other countries, citizens believe they are given rights by their government, whereas Americans believe their rights are God-given and protect them from their government. The distinction is very different and powerful.
I grant you that it is different, but you kind of left totally unaddressed the fact that it is not very powerful at the moment. The US is in far more danger than Canada.
How is it not very powerful? Just because you don't agree with whatever decisions are made doesn't mean that it's not working exactly as designed. The tariffs which are a lynchpin of foreign policy was deemed unconstitutional, which is something you wouldn't expect under a country controlled by the government. The system is working.
> Americans believe their rights are God-given and protect them from their government
As I understand it, the unconstitutionality of tariffs is due to it being considered a tax so cannot be enforced by the executive branch. But there's no right being infringed if the other branches of government would have made them into law, nor is there anything that would stop the executive branch from implementing more restrictive trade barriers.
I actually agree with you that it is working exactly as designed. It is starting wars, separating families, sending citizens to foreign prisons to be tortured, and establishing concentration camps on American soil. The system is working :-(
Speaking as a Canadian: the general belief up here is that something like freedom of speech is not God-given, but is rather something we have built for ourselves using the mechanisms of civilization. I'm aware this is a long-term debate, philosophically, in America; but most folks I've talked to up here believe that rights are something we carve out of the world through our justice and policing systems, not something pre-existing that we're just recognizing.
Consider what freedom of speech means, in practice: to me, it means "you can say whatever you want, and you will retain all of your other rights, including the right to have police protection from those who would attack you for your words".
It doesn't mean "freedom from consequences" in some magical sense where people won't react to what you say or try to punch you in the face. It does mean you can engage the system to punish them for assault, though, and that you haven't given up those legal protections with your words.
I don't think it really means that you can't be fired / deplatformed over it, either. It's a relationship between you and the government, who agrees that they won't withdraw their other supports from you for your words. It also has exceptions: we've got hate speech laws here, though what most folks don't know is that you have to be posing a pretty credible threat, inciting groups to violence, etc (so you're actually still allowed to say a wide range of things that will anger others).
Now, we can imagine a stronger free speech protection - a second layer on top of the first - that says "you can say whatever you want, and your employer is forbidden from firing you over it" - but that kind of thing hasn't been created yet. I'd support it, personally, but I can see why it's a contentious concept.
The belief of 'where' your rights come from has very little impact on reality - and in reality, it's the government (those that control the police, military) that grant you any rights whatsoever. The distinction between where your rights come from doesn't matter much when the people in power are willing to trample them either way.
You're wrong. The Constitution is there to limit the government, not the other way around. And Americans are very willing to stand up to defend their rights. Regardless of which way you lean politically everything we have seen in the last year in terms of political activism are people using their God-given rights as Americans.
The constitution isn't some divine sacrament that they'll respect any more than the laws being rewritten in other countries. They'll step over it all the same when the time comes.
I don't really think you understand how profound (and incredibly rare) it is to have enshrined into law that every citizen has the right to criticize and protest their government.
It may not always lead to major change, but you have no idea how many people are currently sitting in prison around the world for doing exactly this.
i think the perplexity is more important than tokens per second. tokens per second is relatively useless in my opinion. there is nothing worse than getting bad results returned to you very quickly and confidently.
ive been working with quite a few open weight models for the last year and especially for things like images, models from 6 months would return garbage data quickly, but these days qwen 3.5 is incredible, even the 9b model.
I'm still on Windows 10. Fuck you Microsoft for making Windows 11 worse than Windows 10. The simple fact I can't stop them from updating my Windows 10 machine and it reboots my machine makes me so angry that's one of the main reasons why I will never upgrade. Microsoft Recall is a non-starter for me, even though they made it "better".
If they force me to upgrade, I'll move entirely to Mac and install Linux on my current Windows desktop.
reply