The old HP calculators, and their emulators, have a computer algebra system, for symbolic maths, that supported this. The user interfaces leave much to be desired, but some also have reverse Polish notation!
Oh, I was just listing the constraints. I'm not directly aware of a color space where value 0 is not no light. It would however mean that even if linear, doubling a value relative to 0 wouldn't necessarily double the amount of light.
> I suspect 3.14.4 could have been tweaked slightly to address the issue without a revert
I'm sure all the people that have been working on this for years would be interested in your small tweak, that they didn't think of, and would happily accept the PR!
a) do work to reduce issues as they come up
b) appease the vocal complaints
A takes work, guts, and risk. Option b was chosen with the GC work basically saddled with so much process it’s never going to change. Python has a very storied history of being very committee driven design so the committee did the committee thing.
Anyone who’s worked in incident response will tell you why you’re wrong.
Tweaking the GC while the system was functionally broken is the worst time to do it. Correct incident response is revert first, figure out how to fix it later.
The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect
Do you live on a planet where the Python language maintainers are deploying Python into your servers or managing them? Do you live on a planet where a new version of Python being released gets instantly and automatically deployed into your systems without testing and validation?
You are responsible for that, not them. And if Python 3.13 is fine for you and you report a performance regression for 3.14, you can still stay on 3.13. And as you say, it was introduced in a new release. What happens when the other side goes and says “3.14.5 regressed on the GC pause times and my p95 web server latencies went up. Please revert”? At least one side can make the case “performance was changed on a major release of Python boundary” while the other is changing the performance on a minor release boundary. It’s an arbitrary decision that speaks to the politics of the organization and less about a well reasoned technical plan.
Your argument is, frankly, idiotic. If a version of Windows, or any deployed software, has a performance regression, do you consider it “not a live product” because you didn’t personally install it yet?
I really don’t have words. When people bemoan the state of software engineering, your comment here is exactly what they’re talking about.
3.14.5 has a serious performance regression - GC pause times have increased significantly since the entire 3.14 series. This is the problem - you’re arbitrarily putting max RSS of certain workloads over the p95 latency of others. It’s arbitrary and why the worst kind of software engineering that inhibits software progress for the sake of nothing changing.
As for Windows, I think you need a better example. OSes frequently change their performance profile on certain workloads and use more memory. Terrible example.
Also please cool it with the personal insults. They’re not productive and shows you’re trying to win the argument through force and emotion instead of reason.
Snarky comment aside, Python is definitely *not* a "live system". If you had worked with such system before you'd know the world of difference between a version release of "stable" software versus a live platform that cannot fail.
You mean software that has to be deployed locally? Like the example I gave?
> you'd know the world of difference
It's actually worse. The longer you take to get a fixed version out there, the more people will install the buggy version. As distribution is more difficult than just merging a Github PR, that buggy version will live longer on live systems. And before you say "but it's on the developer/DevOps/sysadmin to test," I point you to the countless CVEs where this didn't happen.
Knowing this is the situation, it's unconscionable to leave a faulty build on live for longer than necessary, when you can rollback the change with limited risk.
I do find the BDFL approach much better for language design. You might disagree with the direction of the language, but there is usually a "philosophy" or "taste" driven by one person that tends to be consistent over time.
In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.
> In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.
If you're referring to the steering council, that group was created in response to Guido stepping down.
He stepped down partly in response to the changing nature of online discussions around changes to the language. He just didn't want to be at the center of every polarizing discussion anymore. I think he also recognized that the transition needed to happen at some point, and that was as good a time as any.
People also use usable mice instead of touchpads, and they put the "ctrl" key where Apple thinks a useless "fn" should be. All kinds of things happen outside Apple world.
To me, it's more about what I'm used to. I have a perfectly fine several years-old monitor, so why should I throw it away?
Then let me blow your mind:) One of my daily drivers is an ex-Chromebook at 1366x768. Granted, it's also physically smallish so the DPI isn't quite as low as a macbook would be with those pixels, but still. And that's a touch cramped but it's fine.
The problem is, as soon as you are not on a Mac but Linux or Windows, you are in for an awful, truly awful lot of pain. HiDPI support is a mess because even in the rare case applications are made with HiDPI in mind they are not tested on HiDPI machines.
Other way around, most Mac software is not tested how it behaves on inferior external monitors.
What kind of windows programs are these? HiDPI is more than a decade old. A desktop application, no matter what OS it is, should always be tested with different scaling factors.
I’m not your child, and that’s false, it’s literally one key to change in the settings. That allows you to select the exact scaling factor, not macos’s “more text”/“less text”.
Have you ever tried to write HiDPI-aware Win32 code? I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
Mac OS X 10.4 tried the same thing (Quartz2D scaling) and it was so damn difficult that they threw it out and went for simple 1x/2x/3x auto-scaling. Even 3x was a challenge because of pixel alignment.
Well, you were talking about testing, development of DPI-aware apps is another thing. It requires the developers to be, well, DPI-aware, but I don't think there are particular obstacles to that in winapi itself.
>Have you ever tried to write HiDPI-aware Win32 code?
I haven't. I don't think there's any reason to, I'm more of a wxwidgets fan. I don't think even Microsoft makes applications in raw WinAPI.
>I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
The default behaviour of a DPI-unaware app in Windows is to scale everything by the scale factor. Which - yes, looks completely awful and blurry, but that's not what you describe.
Yeap. Managers perceive complexity by how personally confused they are. I'm late in my career, and I'm realizing I wasted so many man years trying to make code clean, user friendly, and maintainable, when that code was never read by another person again and forgotten 15 minutes after it was released, then used for years. This is why I think AI is coming for our jobs much sooner than many people think: clean code, separation of concerns, maintainability, etc, all the things we spend the most time on, have never actually been valued. "Good enough" is fine, and keeps management happy. And, if something does pop up, AI can patch it, even if with spaghetti, just like fucking that ass at work.
I suspect it's more that the text data doesn't exist. They're trained on text that was recorded. How often has it been publicly recorded when a nuke was not used, with any context around that lack of use?
From the text perspective, it's something that has to be inferred indirectly. If you went through all relevant training data and appended ", we decided not to use a nuke", I suspect the results would be improved.
It's more straightforward than that. The game is set up as a direct head to head with purely in military win conditions such a way that avoiding conflict has no payoffs, conventional conflict incurs costs and first strike is a checkmate win. The closest any of the prompts gets to suggesting nuclear might be the wrong option is "The nuclear taboo exists for good reason, but when the alternative is national annihilation and regime destruction, all options must be considered" which might be interpreted more as incitement...
If a simulation is a shallow head to head conflict between individual actors[1], doesn't set up any payoffs for not escalating[2] or even not nuking, but prompts specify explicit win conditions which are achieved only by hurting the opponent and strongly hint at the importance of nuclear escalation, AIs have little reason not to generate strategies which involve nuclear escalation
[1]I bet if you designed the scenario so ChatGPT had to simulate the war cabinet debates between different personality types and how they sold their decisions to the public, or an entire UN full of nations that might respond, it would have quite different (but probably amusingly erratic in their own way) results.
[2]cf neorealist IR theorists reading Axelrod's papers on computer programs written to win iterated prisoner's dilemma tournaments, which added up all the points accrued from not defecting to conclude winning strategy was definitely TIT-FOR-TAT and not defect first. I'm sure LLMs can win games structured in that way by adopting that strategy too...
The beauty IMO of LLMs as a computational surface, is the ease of generating the data to feed it. Everyone understands how to create natural language records already.
Sure, but where do you draw the line? Many PCs ship with some custom hardware but are not locked down. The MacBook Neo is probably not locked down but uses the same SoC as the iPhone 16 Pro which is locked down.
IMO it's pretty arbitrary. I wouldn't expect to run software on an appliance, even if the underlying hardware is commodity. And an appliance is something that performs a specific task (fridge, car, etc.). There are gray area cases though when an appliance does more than its basic function (smart fridge, car infotainment).
macOS, as shipped, is only Unix-like. Even when configured to pass UNIX certification, it doesn't qualify without the temporary waivers:
if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin, set the setuid bit on all of these binaries, add /usr/local/bin to your PATH before /usr/bin and /usr/sbin, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers. [1]
Maybe your installation of macOS is technically Unix, but mine sure as hell ain't. Desktop "Unix" in 2026 is little more than lipstick on a pig anyhow.
> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...
This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.
It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
Oh, that makes more sense. I'm still not sure why you couldn't give the binaries setuid in their default locations, given that compliance testing also requires SIP to be disabled - but, in any case, at least they aren't setuid by default.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
Disabling SIP still leaves the root filesystem as read-only and signature-checked (this is referred to as SSV, 'signed system volume'). There is a separate command to disable SSV, but it breaks the ability to install OS updates and is rarely used. /usr/local is one of the paths that's redirected to the read-write data volume.
I get most of this, but spotlight doesn’t need to be disabled altogether. That is a requirement for the verification, not the actually running as unix.
The nature of temporary waivers makes this untrue per the post you cited - The Open Group only grants them for 12 months, and the post is over a year old.
IMO, the only significant call-out is APFS case insensitivity by default, which makes the default volume a non-conforming filesystem. However, UNIX certification does not forbid you from mounting non-conforming filesystems (such as FAT32). Instead, this means the majority of software which makes certain assumptions about being used with UNIX conforming filesystems in addition to running on a UNIX conforming operating system are at risk of breaking.
Let's just say I have my doubts the author would have written a similar post if the final HP-UX release had "lied" about their certification by shipping with root login disabled by default and ulimit -c defaulting to zero.
reply