ejiblabahaba

There's basically no point. Desktop PSU is a solved problem, most designs are all about cost engineering and the tiny sliver of higher power and ultra high efficiency options are not struggling with their current form factor.

In the data center, where power (and cooling) are the only significant OpEx, GaN point-of-load conversion is everywhere. Common as a rack distributed 48V to 12V bus or direct to processor Vdd (2% duty cycle is feasible with GaN thanks to fast on/off times). There was a while where GaN was used as part of the power factor correction for AC to DC in the server power supply, back when passing 400VAC or 800VAC bus around made sense. I think these days it's mostly back to DC buses, and AC-to-DC is all happening farther back, in part because of widespread solar deployments and trying to avoid DC->AC->DC double conversion losses when possible. So maybe GaN gets use on active secondary rectifier in the bus -> 48V now too.

Well, kinda. The value is in meeting the spec, yes, but the "certifiable" part is very often a subset of the actual spec. Sort of like in software how someone will inevitably depend on every feature of a public API (including the defects), a lot of early military electronics depend on implementation details of their component processes, usually by accident. The cost for semiconductor companies is not meeting the spec, it's keeping a production line from the 1960s running exactly the same way for a single customer who buys a handful of parts every year.

The problem with Chinese semiconductors isn't performance or meeting specs, at least not these days. It's counterfeits, life expectancy of the source companies, and the obvious risk of basing your supply chain on a foreign political actor that can leverage this dependency against you.

I wouldn't be so quick to make guarantees. There's cheaper spec-equivalent devices, sure, but a frequent and recurring feature of military hardware prior to the 2000s is an unexpected dependence on non-spec device characteristics. I've seen seemingly inconsequential cost-saving process tweaks identified as the root cause for novel testing failures for more than one ancient US military project.

Setting aside that approximately no one is shooting down quadcopters with missiles, that quadcopters and missiles are entirely different categories of weapon with substantially different range/payload/response time targets, and that the availability logistics and acceptable failure rates of paramilitary gangs and impoverished former Soviet belligerents from whom we are likely drawing conclusions about drone warfare economics are maybe just a step or two below the average US military procurement contract requirements; and charitably interpreting your argument as a generalization that repurposed consumer-grade electronics offers a cost reduction over military-grade selections for equivalent performance: true in most modern cases. The US has plenty of cheap domestic options for seemingly pricy problem domains, just ask SpaceX. SOTA in aerospace and defense routinely uses commercial products to great effect. To the extent that shelling out for a $60 military-grade 1960s transistor instead of a $0.06 commercial equivalent is a problem for the US military, it is downstream of enormous legacy cold war capital investment in technology that was novel for its time but is comparatively brittle by modern standards. This is still a problem, to be clear, but a small one in the grand scheme of US military spending.

Suppose an asteroid strikes the Earth and all human life becomes extinct. What power, specifically, has been transferred, and to where?

I think the question was less about the efficacy of ABS, and more about the failure mode. Is it possible for the ABS system to "fail open" unintentionally, such that depressing the brake pedal has no effect whatsoever?

My employer blocks access to Google Docs as part of our confidential information protection policy. They're certainly not the only ones. I'd hesitate to call on-premises file management "specialized needs" - rather, it's (still) the default, particularly if you take a peek outside of the software bubble.

Historically this was a huge concern because not every manufacturer implemented their ESD protection properly; or, on occasion, the process technology meant that ESD protection would hinder the functionality of the device. This happened a lot in RF circuits, and still to this day many RF instruments are extremely sensitive to ESD events. Board assembly was also a lot less automated in the early days of integrated circuits, so more human handlers and more opportunities for ESD events were anticipated.

Modern IC ESD protection is very effective against a few moderate energy events distributed on different pins, and there's a few industry standards that help determine the required amount of caution for dealing with a particular IC (HBM or human-body model, and CDM or charged-device model, are common - targeted toward human assembly procedures and things like triboelectric or inductive charge buildup). In the right climate, a single high energy event is sometimes enough to degrade functionality or (rarely) completely destroy the device, so board assembly and semiconductor manufacturing facilities still require workers to use wrist straps, shoe grounders, mats, treated floors, climate control, etc. Some high voltage GaN work I did years ago required ionizing blowers (basically a spark gap with a fan) because GaN gates are easy to destroy with gate overstress, and there are risks involved with unintended high voltage contact with typical ESD protective solutions. In another embedded-focused lab, the only time I've ever seen someone put on a wrist strap was for handling customer hardware returns. It really depends what you're working with, and in what environment.

I've more frequently (once or twice a year) had devices which exhibit symptoms of something being wrong at the inputs or the outputs, but only on a specific pin or port. For outputs, some symptoms include the output slew rate is inadequate, or the output appears stuck sometimes, or the output has higher than expected voltage noise (though this is a non-exhaustive list). For inputs, the symptoms are more complex - sometimes there's a manifestation at the outputs for amplifiers or other linear circuits, but for feedback systems or digital systems they might behave as though an input is stuck, toggling slowly, etc. which is difficult to distinguish from other, more common errors. I've also directly been the cause of several ESD failures, but in these cases the test objective was to determine the failure thresholds for the system, so I'm not sure that counts.

I've had a customer hardware failure that was eventually traced back to electrical overstress damage on a single pin of an IC near the corner of a board, right where someone might put their thumb if they were holding the board in one hand. In the absence of a better explanation, I suggested this was an ESD failure due to handling error. I never heard about it again, which is weak evidence in favor of a one-off ESD event.

These parts are bonkers. The ringing on its own outputs with a few inches of trace or (heaven forbid) a connector is regularly sufficient to self-trigger the automatic direction reversal. These things genuinely deserve the "experts only" label - they are close to unusable in the situations where you'd be most inclined to reach for them.

Learned a few tricks that I'm sure are buried on fstring.help somewhere (^ for centering, # for 0x/0b/0o prefixes, !a for ascii). I missed the nested f-strings question, because I've been stuck with 3.11 rules, where nested f-strings are still allowed but require different quote characters (e.g. print(f"{f'{{}}'}") would work). I guess this got cleaned up (along with a bunch of other restrictions like backslashes and newlines) in 3.12.

F-strings are great, but trying to remember the minute differences between string interpolation, old-style formatting with %, and new-style formatting with .format(), is sort of a headache, and there's cases where it's unavoidable to switch between them with some regularity (custom __format__ methods, templating strings, logging, etc). It's great that there's ergonomic new ways of doing things, which makes it all the more frustrating to regularly have to revert to older, less polished solutions.

Because, unlike most professions, ATC is immediately, personally responsible for making decisions for which a slight mistake could instantly claim the lives of hundreds of people.

Which language is this? I'm sure some people can clue this together from the hints, but I'm not one of them.

For what it's worth, this post just helped me explain several years of failure to wake from sleep state, across several different MSI-based machines, when I've connected them to an HDMI port in my TV. I think this debug is interesting in its own right, and unlike 99% of the content on this website, it was directly and immediately useful to me. I doubt I'm the only one, too.

As someone with a hardware background, I'll throw in my $0.02. The schematic capture elements to connect up large blocks of HDL with a ton of I/O going everywhere are one of the few applications of visual programming that I like. Once you get past defining the block behaviors in HDL, instantiation can become tedious and error-prone in text, since the tools all kinda suck with very little hinting or argument checking, and the modules can and regularly do have dozens of I/O arguments. Instead, it's often very easy to map the module inputs to schematic-level wires, particularly in situations where large buses can be combined into single fat lines, I/O types can be visually distinguished, etc. IDE keyboard shortcuts also make these signals easy to follow and trace as they pass through hierarchical organization of blocks, all the way down to transistor-level implementations in many cases.

I've also always had an admiration for the Falstad circuit simulation tool[0], as the only SPICE-like simulator that visually depicts magnitude of voltages and currents during simulation (and not just on graphs). I reach for it once in a while when I need to do something a bit bigger than I can trivially fit in my head, but not so complex that I feel compelled to fight a more powerful but significantly shittier to work with IDE to extract an answer.

Schematics work really well for capturing information that's independent of time, like physical connections or common simple functions (summers, comparators, etc). Diagrams with time included sacrifice a dimension to show sequential progress, which is fine for things that have very little changing state attached or where query/response is highly predictable. Sometimes, animation helps restore the lost dimension for systems with time-evolution. But beyond trivial things that fit on an A4 sheet, I'd rather represent time-evolution of system state with timing diagrams. I don't think there's many analogous situations in typical programming applications that call for timing diagrams, but they are absolutely foundational for digital logic applications and low-level hardware drivers.

[0]: https://www.falstad.com/circuit/

A lot of these environments inherit a visual presentation style (ladder logic) that comes from the pre-computer era, and that works extremely well for electrical schematics when conveying asynchronous conditional behaviors to anyone, even people without much of a math background. There's a lot of more advanced functions these days that you write in plain C code in a hierarchical block, mostly for things like motor control.

For Uno specifically: I do like the attempt to build out a WASM target, it looks usable. Uno looks to be in a lot better state internally than even two years ago, which is promising - that's one thing I can't get out of either WPF or Avalonia.

Key things that need to improve: - Documentation appears to have gotten better in the last few years, but still many sparse or underdocumented corners. This is my biggest reservation today. - When I last used it (a few years ago), a lot of things weren't fully implemented - maybe this has changed? But it added a lot of friction.

If Microsoft said "Windows-only, good luck with cross platform," I'd accept it and move on. It's their prerogative to spend their resources enhancing their own platform.

Instead, I've been told a half-dozen times that there's a new cross-platfotm GUI option, and had I bought into any such endeavor, I would have been rugpulled by sudden deprecation or loss of focus. I think people who did buy into any cross-platfotm GUI frameworks from Microsoft in the last ten years are justifiably feeling like they've been hung out to dry, sometimes multiple times.

I don't complain about Elixir, Ruby, Go, or Rust GUI development because I don't try to use these languages for GUI development, because their core leadership and marketing doesn't promote this as one of the primary use cases. C#, and the .NET ecosystem at large, are THE premier Windows GUI development tools. When their marketing pivots to cross-platform GUI development, and they rugpull you a half-dozen times in a decade with half-finished and baffling experiments, it kinda smarts.

Most people developing desktop apps are probably okay with switching to web-based options, including potentially running their own standalone rendering executable on top of a web view or chromium instance. But there's a significant minority that are building desktop apps because they want better performance and native visual integration/theming, who don't benefit from browser process isolation and the hairy JS event loop situation, who don't want to serialize every user action in the GUI, who saw what XAML set out to accomplish (GUI style templates that convert to framework code that could equally be hand-written, modified, or extended) and ran marathons with it. Maybe this will get better with WASM improvements in the next few years, but it doesn't change that the approach to GUI design is fundamentally different, and in a lot of ways needlessly harder, when you have to pretend your GUI isn't all running on the same machine.

Presumably because, much like the half-dozen other flexible cross-platform frameworks Microsoft and friends have gotten one-third of the way to a viable product before abandoning to chase the next shiny thing, it's riddled with bugs, about ten years behind the documentation of a more usable framework from the 2010s, and has basically zero third party support from the likes of Infragistics and SyncFusion.

UWP left behind a shockingly large number of perfectly serviceable pieces of WPF, at a time when the emergent UI experience on Windows 8 was being written off by almost everyone, Windows Phone was DoA, and people were starting to realize they could just write web pages and run GUIs in the browser instead. It's been a long, bumpy, downhill ride ever since. The fact that Electron.NET and Blazor is a serious UI suggestion from Microsoft these days should tell you everything you need to know.

I'm sure with enough effort it's usable and maybe even nice in some ways. I did some proof-of-concept work with it two years ago and got maybe 50% of the way to where I wanted to be in 8 hours, but got stuck at styling issues for which there was limited documentation. In the end, I'm more confident these days in WPF + Avalonia if I really need cross-platform - even if there's comparable bugs and limited documentation, there's at least some momentum still behind the project. UWP, all three busted half-finished versions of WinUI, MAUI, Blazor + Webview2, Blazor + Electron.NET... even Avalonia, thanks to the weird decision to change styles to behave more like CSS... it all still struggles to be as usable as WPF.

This is frankly infeasible. Between the decades of trade secrets they would first need to discover, the tens- or maybe hundreds- of billions in capital needed to build their very first leading edge fab, the decade or two it would take for any such business to mature to the extent it would be functional, and the completely inconsequential volumes of devices they'd produce, they would probably be lighting half a trillion dollars on fire just to get a few years behind where the leading edge sits today, ten or more years from now. The only reason leading edge fabs are profitable today is because of decades of talent and engineering focused on producing general purpose computing devices for a wide variety of applications and customers, often with those very same customers driving innovation independently in critical focus areas (e.g. Micron with chip-on-chip HDI yield improvements, Xilinx with interdie communication fabric and multi chip substrate design). TPUs will never generate the required volumes, or attract the necessary customers, to achieve remotely profitable economies of scale, particularly when Google also has to set an attractive price against their competitors.

If Google has a compelling-enough business case, existing fabs will happily allocate space for their hardware. TPU is not remotely compelling enough.

He didn't lose his brain mass, it was compressed into a thin shell around his skull.[0] Moreover, his IQ was 75 - I'm not sure ending up in the bottom 5% of human intelligence as a consequence of chronic hydrocephaly is a "normal" life.

[0] https://www.untrammeledmind.com/2018/02/so-his-brains-just-s...

I don't agree with the premise.

Integrated circuit manufacturing scales well because the cost per transistor is lower with every process improvement, so as process improvements accumulate, more value (or perhaps more productivity) per wafer is created. This strictly applies to digital circuitry - most analog circuitry requires a certain geometry or process technology not available on a massively optimized modern digital process. While some analog technology improvements are made, it's at a much slower pace. Moreover, a lot of analog redesigns come about as a means to abandon older, less cost-effective semiconductor technology - so the argument that cheap older tech is a boon to any industry outside of limited volume and high cost R&D is suspicious.

Solar cost improvements are in large part a function of massive economies of scale coupled with cheap manufacturing costs and government subsidies from the primary country of origin (which country? Take a guess). I'm sure there's been improvements in a handful of solar material designs, but if you make a large enough volume of panels in a country with cheap labor and massive government subsidies, costs go down. It's not rocket science. To the extent that modern semiconductor technology has improved solar, maybe an argument can be made for improved digital inverter controllers and for silicon carbide FETs maturing enough to make high-voltage panels efficient and ubiquitous at grid-scale deployments. But it's mostly volume, cheap labor costs, and government subsidies.

I don't know about biotech. The following is speculation. I think a lot of biotech was feasible 25 years ago in terms of manufacturability of microfluidics or molecular identification circuitry; but the cost of mass manufacture, and particularly the compute requirements to quickly recover signal from a highly noisy process, wasn't economical or simple to build until digital signal processing and general purpose compute became cheap and fast enough to integrate alongside the biosensors, often as copackaged modules, or generic coprocessors (ARM, RISC-V, etc) that can be built on a ton of different processes and which export raw sensor data quickly enough to allow much heavier duty professors to do the bulk of the work.

I think actual fabrication tech improves slowly, because at its core it's chemistry and material science which also improves slowly (see: batteries). Digital circuitry is a mind-blowing exception, thanks to the incredible amount of usable abstractions that can be built from the manufacture of two specific transistor recipes. But digital circuitry is so powerful, it becomes possible to abstract away massive chunks of otherwise difficult problems in software, firmware, or dedicated transistor-level algorithm implementations, which reduces the amount of physical-world improvements needed to make useful innovations.

With Cloud, as long as you don't mind solving the same problem multiple times every few years when things you depend on go obsolete, indeed it is a nice experience. A lot of people do mind. I won't belabor the point; Steve Yegge said it better[0]. I think some progress has been made on this front, particularly with bigger customers; but even if Google promised decades of backward compatibility tomorrow, Google's reputation would remain its own worst enemy.

Search deterioration has a much longer history than ChatGPT, but nice try. Search is an arms race against a functionally infinite tidal wave of spam, much of which is overwhelming websites beyond Google's control that historically populated Google's top search results. Epistemology is hard, the threshold for financially profitable spam is low, and the cost of sophisticated spam is getting exponentially smaller. And the long-term market solution might be someone like OpenAI thoroughly leap-frogging Google's capabilities. This is a bigger risk than you're making it out to be.

As far as privacy... Google makes an attempt to follow applicable laws, and in many cases succeeds, but it still ends up constantly trolled by regulators for money or clout. Even setting aside fines-as-taxes and legislative opprobrium, I still don't think "our panopticon strips you of way less dignity than our competitor's" is something to brag about. If you believe the nature and incentive structure of the panopticon is diabolical, businesses that function as panopticons are fundamentally untrustworthy. It doesn't stop me from using Google products and services, but in a "least bad" sense - I'm happy to switch search, email, phone OS, whatever, provided someone can make a more compelling product. I think a lot of people feel similarly.

I could argue that Google's open source contributions are largely market suppression tactics to keep the web innovating in a direction that protect's Google's core revenue. This isn't comprehensively a bad thing, as technologies like Chromium and Android are useful. But "our OSS suppresses markets more effectively than our competitors" isn't something to brag about, and combined with those regulatory trolls above, I see this as a big risk factor.

All else aside, Google (and for that matter, most of Big Tech) fundamentally relies on massive volumes of hardware manufactured in Taiwan. This isn't even a black swan, it's a sword of Damocles over the entire industry.

[0] https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

The US literally stopped issuing new reactor permits in 1979 (down from on-average about 12 per year), and didn't begin issuing new ones until 2012. Out of 177 reactors issued construction permits up through 1979, at most 112 were ever online at once, in 1991, up from 69 in 1979 when the Three Mile Island failure happened - implying over half of already permitted construction was abandoned or never even started. The facilities under construction were subject to an exponentially increasing gauntlet of new safety assessments, failsafe systems, and in many cases reconstruction of things already built and approved just years prior; eventually, the expense of such facilities radically outstripped the expected ROI of nuclear facilities altogether. Most facilities overran on costs, and took decades longer than expected to see their first real returns, if they even stayed open long enough to see real returns.

If US nuclear plants haven't significantly endangered human lives since 1979, it's because the thresholds for accepted risk became so low as to render new enterprise impossible.

Regulating air traffic control (and thus air traffic) into impossibility isn't a realistic option. Unlike nuclear energy, which has functionally equivalent alternatives, there is no functional equivalent to the speed, reach, and cost of air travel. We likely already hit the practical floor on incidents in ATC a long time ago, thanks to (as you have observed) the variables involved being very stable for decades.

Hence the cause for alarm: what if, all of a sudden, those reliable variables are changing?

IronPython is indeed quite a pain to work with, and for a lot of reasons beyond the age. For instance, you don't get numpy or any dependencies that themselves depend on quirks of CPython. The alternative is PythonNET, which executes python in CPython context, but provides nearly the same interoperability* with CLR assemblies. There's many devils in the details of that asterisk, and I'm frankly not knowledgeable enough to explain them; but in my experience, things work well enough that I'm satisfied with the integration provided.

Are you sure you're not thinking of Mullvad?

Related: https://news.ycombinator.com/item?id=35638917

You're already seeing it. Xilinx led the industry in chip interconnect technology, SERDES, MCMs, die stacking... they've been making chiplet designs since 2011. They were the ones inventing all the interconnect and packaging technology AMD is using in Zen, Epyc, and now Radeon products.

This sketchy-looking link is a marketing slide for Xilinx chip-to-chip interconnect tech from 2019. It's illustrative of the kind of IP AMD was shopping for. https://146a55aca6f00848c565-a7635525d40ac1c70300198708936b4...

Shorting the inductor temporarily converts some of the energy in the stored electric field of the input capacitor to "stored" magnetic field in the inductor (not quite, since it's only present when current is flowing, but close enough). Roughly the same amount of energy is eventually converted back into stored electric field in the output capacitor, minus the losses from parasitic capacitances/resistances and radiated emissions.

To keep things simple, imagine a lossless boost converter. In terms of power-in and power-out, a lossless converter has the same input and output power. If the converter output is doing real work (resistive load), the output power is equal to the output voltage times the load current. Therefore, at a lower input voltage, the converter sees a much higher input current than the load current - it has to, because power-in equals power-out. If it intuitively feels like you're pulling more energy out of the input capacitor than you're pushing into the output capacitor because of the temporary shorting of the inductor, remember - it's not lost to real work, just cleverly exploited by the transformation to magnetic field to losslessly overcome the difference in potential energy between the input charge at low voltage and the output charge at high voltage.

  Energy in cap: E = 1/2 * C * V^2
  C = Q / V
  E = Q * V / 2
  Energy in inductor: E = 1/2 * L * I^2
  I = dQ/dt

I don't know how to write out the integral notation on HN, so you can fill in the blanks (sorry) - integrate the inductor current ramp up and ramp down portions, set equal to input charge pulled and output charge pushed, observe that energy is conserved with less charge at higher voltage on the output.

I'll agree that it's largely a semantic difference and that I overstated the significance of the MOSFET involvement as the pass element - you can design single-transistor PNP elements with only a few hundred millivolts dropout, and at one point TI referred to these as LDOs.[0] Indeed, even the Sziklai pair gets called "quasi-LDO". Individual engineers likely have different personal thresholds for what constitutes an LDO. But it's worth pointing out that in practice there are only a handful of plausible linear regulator pass elements, and the physics of the BJT-based pass elements sort them into a distinctly higher minimum dropout voltage than what is achievable with MOSFETs.

I still stand by the characterization of LM317 and LM7800 family as "not LDOs". Both devices are Darlingtons with at least two Vbe drops across the series pass element. On the continuum of LDO------Not_LDO, both LM317 and LM7800 are firmly on the Not_LDO side.

[0] https://www.ti.com/lit/an/snva020b/snva020b.pdf

I think the big driver for solar inverters was panel cost reductions. With motor drives it's straightforward even 25 years ago to see the benefits and applications of slapping a DSP and some digitizing sensors onto the system to do crazy control stuff. But PV cost was just way too high for this stuff to have tons of active research until recently. Once panels got commodized, the industry pretty quickly noticed how much virtually free compute is available, and moved to fill the gap. It's certainly been interesting watching commercial PV inverter design start with an extra decade of compute improvements and cost reductions as the industry effectively speedruns the design challenges - even with only a few active research projects before 2015, we've had designs in hand for a decade and no scalable way to deploy them.

The commoditization of computing power, and the continuous decades of improvement in digital hardware performance per watt, has reduced numerous classes of analog problems to an exercise in fast enough bit-twiddling. I think in motor drives the big jump to simple hardware and beefy controller was directly downstream of the creation of usable 32-bit motor controller DSPs, along with software toolchains that made it possible to compile optimized C and C++ libraries for these architectures. Up to early 00's there just wasn't enough real-time computing power available for most of the market to take advantage of it, and what little did exist wasn't directly targeted at motor drives. But it is worth pointing out that the S-curve of digital adoption probably got started as far back as the mid-90s; the only people who could really take advantage of it back then were at the cutting edge with very expensive low-volume projects. I'm sure it felt like an overnight event, but it took a decade for motor drive DSPs and software toolchains to get good enough that most people felt compelled to switch.

ETA: oh gosh I forgot FPGAs happened then too, that probably had a lot more to do with it... Ah well, fun trip down memory lane :)

It's been very interesting watching as the compute gets cheap enough that we can start embedding it into the analog chips. The telecom chips all have DSPs in the ADCs and DACs and digital PLLs in the line cards, the battery management ICs all have microcontrollers for charge management and safety, you can buy radar ASICs for automotive proximity detection, there's gate drivers for SiC FETs in automotive traction inverters that incorporate redundant microcontrollers to do monitoring and fault detection/recovery for ASIL D compliance. So I'd add: the same way that software drives the marginal cost of complex math to near-zero, advances in digital circuitry and ease of incorporation into other analog designs drives the marginal cost of complex application requirements down. It's not quite as stark as software, but it's amazing how much quicker a single complex chip design becomes when you can digitize a subclass of the problems and solve them in real-time at virtually no cost on analog ASICs with built-in CPUs and DSPs. Analog hardware advances are extremely challenging by comparison, and can take years of R&D across a wide array of reliability and performance assessments before they become realized in designs.

Maybe 300mA order of magnitude is more common than 3A, but it's not inconceivable. Lots of designs wake up, burst some RF data at a few hundred mA transceiver load for a few tens of microseconds, then go back to sleep for another few seconds. There are some long-interval scientific instruments that need high-speed ADCs or DACs on battery power in remote locations, which might get into higher current than a few hundred mA. Some deep space crafts can sleep at very low power and run their transmitters at comparable currents. It's very situational.

Sure, direction of current in the magnetics does capture the intended distinction better. Ripple currents are usually non-ideal behavior, and cases where it isn't (discontinuous conduction mode in the boost converter) are probably arguably but needlessly pedantic.