This is why lab exercises are important. I remember first building some actual TTL circuits on bread board, I learned very quickly that this whole digital stuff is a lot uglier and messier than on paper or in the simulator.
With sharp rise times, synced up to a common clock, even after soldering in a whole bunch of capacitors, you can still stick a probe pretty much anywhere and see switching spikes all over the place, from power rails to completely unrelated signals that are supposed to be stable. Using actual TTL, there was another funny lesson what this weird "fanout" value in the datasheet meant.
A similar lesson I learned that way (and a very memorable one :-)) was about flyback diodes.
Ah, but that may well be because of your scope probe's leads! The sharper the edge the more likely that will happen. That's what those shitty little springs are for that come with your scope probe: you disconnect the ground wire and put that spring on the naked scope probe pin around the ground collar. Then where you want to measure you use the pin to go to the signal and the little spring to reach the nearest ground. Presto: clean signal (or at least, much cleaner). Also, make sure to tune your probe (that's what the little plastic screwdriver with metal tip is for, there is a small trimmer in the probe you can reach through a hole and that is critical at high frequencies) and avoid probes with switchable 1/10 like the plague, over time the switches go lame and then you'll be tracking all kinds of weird gremlins.
This is just reminding me of the time I played with an oscilloscope, touched the probe against my finger and found my body was antenna picking up mains frequency.
(I imagine analogue RF board-level simulation is a lot more expensive than digital-logic board-level simulation. Might have been impractical way back when, such that we only used to have the digital-logic kind. But we certainly have both kinds today.)
Oh, this is just the usual Microsoft Stockholm syndrome. I've been witnessing this for over 20 years now and have been told that it has been a thing for much longer than that.
"No, we can't switch to OpenOffice you weird Open Source hippie! I can't e-mail documents to other people anymore, nobody can open them. Besides, the UI is all different, I won't be able to find anything!"
Then Office 2007 happened, tossing out the waffle menu for the ribbon and people started receiving e-mails with strange docx/xlsx files that nobody could open. IIRC that was still an issue 3 years later.
But no, when Microsoft does it, it is different: "This is progress! Are you against progress, you weird Luddite?"
I remember by the time Windows 8 was released ("Kachelofen edition" - "hurr, your desktop is a tablet!"), I was discussing with a Unix graybeard friend in the cafeteria how long it will take until the complainers accept that "this is the way now". I think it was him who suggested that if Microsoft sent a sales rep around to shit on peoples lawns, it would take at most a year until they start defending it as the inevitable cost of technological progress.
No matter how slow and bloated the GitHub web UI gets, or how many nonsense anti-features Microsoft stuffs into it. People will accept it and find funny excuses (network effect will be the main one).
> I think it was him who suggested that if Microsoft sent a sales rep around to shit on peoples lawns, it would take at most a year until they start defending it as the inevitable cost of technological progress.
They would inevitably say that Linux was not viable because you had to buy your own fertilizer.
Yes, the underlying S3 texture compression algorithm was patented in the US in the late 90s. The last, relevant patent expired in 2018[1]
Direct3D called its variants DXTn, later rename to BCn. From what I recall, Microsoft had some sort of patent licensing deal that implicitly allowed Direct3D implementers to support their formats.
OpenGL had an extension called GL_EXT_texture_compression_S3TC[2].
Under "IP Status" the extension specification explicitly warns that even if you are e.g. shipping graphics cards with Direct3D drivers, supporting S3TC, you may not legally be able to just turn that feature on in your OpenGL driver.
> For repairing a broken thing? After provably trying in vain to get the landlord to fix it?
Down the hallway from my office used to be the management of a small hotel chain. We often had lunch together and I got to hear a bunch of interesting anecdotes over the years.
Way back when they started up and didn't yet have enough cash to actually own the buildings they operated in, they rented. One of the buildings turned out to have numerous issues (holes in the roof, gaps near exterior walls, etc...). To the point that they eventually didn't pass a fire inspection. They repeatedly asked the owner to have it fixed. Pressed for time, they themselves eventually payed someone, out of their own pocket, so it would at least be up to code for the fire inspection.
From what I was told, the owner threw a tantrum over them modifying the building, terminated the contract and sued them. Successfully.
If you are a tenant in a rental apartment, you'd probably have more leniency on the legal side (compared to a company renting a business property). But still, I'd be very careful making any assumptions about the legal situation rather than risking some sort of Kafkaesque legal mess.
Over here at least, it is very common in apartment complexes that the apartment owner is a different person/entity than the building owner and only the later has the rights to mess with stuff installed in the walls (e.g. plumbing) and especially stuff elsewhere in the building (e.g. an external intercom system). If you ask the landlord to fix it, the best they could do is forward that request to the building owner. If you pulled a stunt like the OP did, there's a good chance that the building owner will sue your landlord.
In the US states that I know well, a residential tenant may perform necessary repairs to bring the space up to health and safety codes, and may deduct the cost from their rent. They have an obligation to notify the property manager, in advance in the case of non-emergency repairs, or after the fact otherwise. There are additional details to consider as well.
I don't know if this would apply to a commercial tenant.
But it would definitely not apply to non-violating conditions like the OP's case.
> the owner threw a tantrum over them modifying the building, terminated the contract and sued them. Successfully.
Was the unauthorized modification permanent or undoable? If the latter, I think some people should really get their judge card (or landlord card) revoked.
Did the judge at least suggest what alternative action the tenant should have taken to comply with the law and code?
Most likely the (legally) correct thing to do in the US is to first report the landlord to the relevant agency, possibly named something like Licensing and Inspections or Fair Housing or somesuch. Each local jurisdiction will have it's own agencies for this, so do research. Failure to respond to that would next involve a landlord-tenant lawyer.
Whether or not it's worth all the trouble and time is a different matter. For most people, I'd say reporting to relevant authorities to make the landlord's life harder without needing much continuing effort is probably worth doing, but the lawsuit side is likely to be a huge time and money sink and it's almost always easier to just move. Let the city sue them for continuing to accrue complaints of unsafe living conditions.
In the same way, a landlord cannot evict you themself if you just fail to pay rent, but there are multiple legal mechanisms to eventually get the sheriff to do it for them. Basically, if landlord-tenant negotiation fails, I think the only legal recourse is to involve governmental third parties unless you technically open yourself up to legal reprisal.
> It's interesting how they found the unused code.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
I must admit just from reading the description, it doesn't sound that the correct inference is that it's never been used.
"In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem." to me reads that if the total memory usage never exceeded that threshold then the bug wouldn't trigger. So, wouldn't this bug only affect people who changed that threshold down below the current usage? Because otherwise, usage wouldn't go above the threshold anyway?
And just because the kernel is logging a deprecation notice, there's no guarantee that anyone would ever see that, depending how often it was logged.
But that said, I'd never even heard of this feature, and wouldn't be at all surprised if many routers hadn't just silently dropped these packets anyway because they didn't recognise the protocol version.
Yes, but it's not natural to say "It's not <non sequitur thing no one was talking about>. It's <amazing globally impactful thing that should make you pay attention>." That's how LLMs write though.
With sharp rise times, synced up to a common clock, even after soldering in a whole bunch of capacitors, you can still stick a probe pretty much anywhere and see switching spikes all over the place, from power rails to completely unrelated signals that are supposed to be stable. Using actual TTL, there was another funny lesson what this weird "fanout" value in the datasheet meant.
A similar lesson I learned that way (and a very memorable one :-)) was about flyback diodes.
reply