It was a wonderful operating system. It provided consumer desktop essentials (Plug & Play, DirectX 7, ACPI power management, Windows Driver Model (WDM), and support for consumer I/O interfaces like USB and Firewire) alongside a modernized UI, all running atop the NT kernel. I was extremely lucky to receive a free copy of Windows 2000 Pro as a student, because I rode that horse for years.
Then Microsoft added a green start button and dark blue backgrounds and packaged Win2k for home users as Windows XP.
I think you are taking an excessive interpretation of what was suggested.
Let's level-set on the issue: Of late, GH has suffered a continuous stream of noteworthy outages. It is hypothesized the underlying cause of the instability has been the dramatic rise in submissions from coding agents ("AI"). The open question is how (or whether) GH can get load at a manageable level, with the proposal being, 'don't immediately allocate build/compute resources against any and all submissions.'
I don't see why that is equivalent to rampant disenfranchisement in the open source community. I believe what people have in mind is closer to, "don't immediately trigger an expensive build process as soon as someone submits a pull request."
I think Clearmotion has a very interesting technology and product (ride stabilization), but let's paint a full picture here: the company was founded in 2009, took on $370 million in funding, and only recently landed large contracts (a $1 billion dollar deal in 2023 with Chinese auto manufacturer, Nio).
I'm sure they were in a constant struggle for survival and had to "move fast" to stay afloat, but their technology is more than a decade in the making.
Yes, that's the issue: the (thick) solid grey "major axis" lines on the background seemed to be a wire.
If I could make a recommendation, get rid of the grid lines entirely and only have 'dots' at regular spacing. Here's what Cadence Virtuoso looks like (the most popular circuit schematic tool for integrated circuit design):
I worked on deep sub-micron, full custom mixed-signal integrated circuits for more than a decade, and I can't pass the first level.
> Wire an NMOS transistor so that when In is 1, the output is pulled to ground (0). When In is 0, the output should be unconnected (Z).
Certainly:
(a) The nMOS has 3 connections: its drain is only connected to the output (no +Vdd supply), it's source is tied to ground, it's gate is tied to the signal input
(b) When the gate (input) is driven high, the nMOS transistor turns "on," connecting the output to the source (which is grounded). This acts as a "pull-down network"
(c) When the gate is driven low, the nMOS turns "off," leaving no connection to the output. This is equivalent to a "high-impedance" / "unconnected" / "Z" output
Fails 1/2 tests
(Edit) - I thought the light grey, thick line on the background grid was a wire from "input" to the transistor's gate. It is not. You need to explicitly add a wire from "input" to gate :\
They certainly have, but the general idea is to first use stealth jets to bomb defensive systems (including radar observability) to conquer the skies, and then you can fly around somewhat freely. While SAM technology has improved, so have America's observability and stealth bombing capabilities. It will be interesting to learn the context and sequence of events which led to an F-15 being shot down by enemy fire.
(In 1991, the United States relied on the F-117 Nighthawk to penetrate Baghdad and launch salvos against radar and SAM sites. Simultaneously, Tomahawk cruise missiles were fired against similar communication and defense sites. In this war with Iran, the F-35 and B-2 have been used for stealth missions).
During the entire gulf war (Iraq, 1990-91), only two F-15s were shot down via surface-to-air engagement. At the time, Baghdad was known to have the highest density of SAM protection out of any city in the world.
An F-15 being shot down in Iran after weeks of strategic bombing of their anti-air defense systems is not a good sign.
> The Claude C Compiler illustrates the other side: it optimizes for
> passing tests, not for correctness. It hard-codes values to satisfy
> the test suite. It will not generalize.
This is one of the pain points I am suffering at work: workers ask coding agents to generate some code, and then to generate test coverage for the code. The LLM happily churns out unit tests which are simply reinforcing the existing behaviour of the code. At no point does anyone stop and ask whether the generated code implements the desired functional behaviour for the system ("business logic").
The icing on the cake is that LLMs are producing so much code that humans are just rubber stamping all of it. Off to merge and build it goes.
I have no constructive recommendations; I feel the industry will keep their foot on the pedal until something catastrophic happens.
> All it really shows is that the “poor” are getting milked for everything they earn and own
How are you concluding that? The only way I can see that could be true is if the bottom 50% has shifted their meagre savings to spending in an effort to stay afloat.
I find this to be dubious because the bottom 50% was never saving much at all in the first place. For context, the median income across planet earth is $850 USD _per year._ There's not a lot of room at the bottom for savings.
99% of people writing in assembly don't have to drop down into manual cobbling of machine code. People who write in C rarely drop into assembly. Java developers typically treat the JVM as "the computer." In the OSI network stack, developers writing at level 7 (application layer) almost never drop to level 5 (session layer), and virtually no one even bothers to understand the magic at layers 1 & 2. These all represent successful, effective abstractions for developers.
In contrast, unless you believe 99% of "software development" is about to be replaced with "vibe coding", it's off the mark to describe LLMs as a new layer of abstraction.
> [Synology] comes with dedicated Time Machine support
Your umbrance is with Synology, not Apple.
Apple raised security default configurations in Tahoe. That led to a config breakage with NAS devices which rely on relaxed security configurations.
I agree Apple should publish a technical note / changelog of config changes such as this one, but Apple has never implied to users they'd carry a support burden for any/all third-party hardware vendors. To the contrary, they've notified users that you're meant to consult with your NAS vendor for configuration steps:
> Check the documentation of your NAS device for help setting it up for use with Time Machine
Article title is a bit dramatic. The summary seems to be: for the 5% of users who back-up to a network share (rather than direct-attached storage like a USB hard drive enclosure), Apple's default SMB configs on Tahoe are strict and won't work out of the box with many common NAS solutions.
Apple should document such changes, but, looking at the post title, you'd think they were silently corrupting data during restoration.
"Cream and egg yolk are expensive; industry tightens its belt."