Intel has been using a fair bit of TSMC in their CPU manufacturing recently, yes. Most recently they’ve been assembling “tiles” of silicon from many process nodes into a single CPU package and IIRC they have been using TSMC for the GPU tiles.
At first glance that seems to be true, but when you look at the arguments at the time, who made them and how much of it was walked back, it just looks like the usual legislative panic, same as 911. It doesn't make the original intentions wrong, anymore than what happens when you release open source software and it takes on a life of its own under new maintainers. The failure to understand the long term reprocusion of basically ignoring the actual language of the original document puts one in a place where literally nothing matters except what you can ram through congress and get supreme court approval over during a time of panic or before the other side takes over again.
Thats not a constitutional democracy, thats just anarchy and rule by whoever can buy the most seats.
Withdrawing permits for in construction offshore wind projects, and forcing utilities to keep operating coal plants they want to shut down is picking winners and losers.
Probably the worst thing MS did was kill GitHub’s nascent CI project and replace it with Azure DevOps. Though to be fair the fundamental flaws with that approach didn’t really become apparent for a few years. And GitHub’s feature development pace was far too slow compared to its competitors at the time. Of course GitHub used to be a lot more reliable…
Now they’re cramming in half baked AI stuff everywhere but that’s hardly a MS specific sin.
MS GitHub has been worse about DMCA and sanctioned country related takedowns than I remember pre acquisition GitHub being.
as useful as it was before this administration when big tech was sucking up to whomever was running the country (e.g. “macho man” Zuck was getting ready to tattoo DEI on his forehead couple of years ago) or just now it’ll be magically useful?
Destroying things and outsourcing to already-built prisons is easy. Building things is not.
All they have is a demolition site. There's no final design. Trump keeps changing his vision of his mausoleum. They don't have an architect since the previous one quit.
They have less than a week to submit construction plans[1], and they're clearly missing that deadline. It is of course not the end, but it's a sign of things to come, about half a year in.
Trump is personally running the project instead of delegating it and as we all know he's ruled by whims and disorganized plus rapidly mentally deteriorating at 79 years of age. He's talking about getting into heaven and desperately slapping his name on random physical things because he's obsessed with leaving a grandiose "legacy", any kind of mark on history. He will, but it'll rather be as a seditionist and corrupt ravager of civil institutions and the rule of law -- a pitiful despoiler.
There's no section about the ball room in Project 2025, and no one else but Trump cares about this pet project.
Are you sure this is how he'll be remembered? Half the US thought him preferable to AOC and Hillary Clinton. It's hard to conclude in any other way than that the perception of his legacy will be equally divided.
Most of his actions are, to the majority of the population, merely transient actions. A few letters on an arts center are trivial to remove, a cancelled wind turbine farm easy to forget. The CECOT stuff deeply impacts only a small part of the population, so it'll at most be a few lines in a history book.
But demolishing a third of the White House? That'll be clearly visible in every single aerial shot of the building during every single political event for years. It is, quite literally, a scar on the political face of the country.
It's like turning the Pentagon into a Square, or blowing Washington's face off Mount Rushmore, or selling Alaska back to Russia: you're not going to forget when you are constantly being reminded of it.
actions might be transient but, like or not (I certainly do not) will be the President that is remembered and talked about more than just about all of previous ones combined
The problem is, if everyone knows it going to curry favour and you're the odd man out - are you in Violation of your fiduciary duty to your shareholders?
The gamble these executives are making is that prosecutors in a different administration will not prosecute them for bribery.
If you watch House of Cards (based loosely on real life), you can see the degree of separation between corporations/lobbyists and Congressmen. These guys participating in building a ballroom are crossing that line. Juries will not have to connect so many dots compared to before in order to put someone in jail.
My prediction is one of the Chinese FPGA makers will embrace open source, hire a handful of talented open source contributors, and within a handful of years end up with tooling that is way easier to use for hobbyists, students, and small businesses. They use this as an inroad and slowly move upmarket. Basically the Espressif strategy.
Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice especially it seems like a no brainer but they don’t understand the appeal of open source still.
For me, that means higher capacity and advanced blocks such as SERDES, high-speed DRAM interfaces etc.
The bottleneck in using these kind of FPGAs has rarely been the tools, it’s the amount of time it takes to write and verify correct RTL. That’s not an FPGA specific problem, it applies to ASIC just the same.
I don’t see how GoWin and other alternative brands would be better placed to solve that problem.
> My prediction is one of the Chinese FPGA makers will embrace open source
Sadly, this doesn't seem to be panning out because the Chinese domestic market has perfectly functional Xilinx and Altera clones for a fraction of the price. Consequently, they don't care about anything else.
It irritates me to no end that Gowin won't open their bitstream format because they'd displace a bunch of the low end almost immediately.
> It irritates me to no end that Gowin won't open their bitstream format because they'd displace a bunch of the low end almost immediately.
All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.
Support is stuck at the old levels--none of the GW5 series are implemented. This is just like how the Lattice support is similarly stuck at the ice40/ECP5 level which is almost a decade old.
Gowin seemingly doesn't even sell the chips to individuals. Either set up an LLC so you can request samples from a destributor, or desolder one from a sipeed dev kit.
I could order MOQ (minimum order quantity) of anywhere from 100-500 depending upon range. I didn't need to be an LLC, but it sure helps to actually know the lingo and understand how to deal with distributors and FAEs (field application engineers).
One thing you absolutely have to remember is that when it comes to distributors and FAEs is that as an individual you are wasting their time. Talking to anyone other than you is more profitable. Nevertheless, most won't ignore you (sales is their job, after all) but you very definitely have to make their lives as easy as possible and understand that you get their time after they have serviced everybody more profitable.
Tariffs made everything miserable because the FAEs and salespeople were up to their earballs dealing with the daily price swings of customers with actual volumes.
Gowin and Efinix's tools are extremely spartan compared to Vivado or Quartus: they're pretty much straight HDL to bitstream compilers. There's also a FOSS implementation flow available for the Gowin chips (but I haven't used it.)
HDL isn't getting any easier, though, and that's where most of the complexity is.
Also technically the code names are only for unreleased products so on ark it’ll say “products formerly Ice Lake” but the intel will continue to calm them Ice Lake.
> On that note: GCC doesn't provide a nice library to give access to its internals (unlike LLVM). So we have to use libgccjit which, unlike the "jit" ("just in time", meaning compiling sub-parts of the code on the fly, only when needed for performance reasons and often used in script languages like Javascript) part in its name implies, can be used as "aot" ("ahead of time", meaning you compile everything at once, allowing you to spend more time on optimization).
Is libgccjit not “a nice library to give access to its internals?”
To use an illustrative (but inevitably flawed) metaphor: Using libgccjit for this is a bit like networking two computers via the MIDI protocol.
The MIDI protocol is pretty good for what it is designed for, and you can make it work for actual real networking, but the connections will be clunky, unergonomic, and will be missing useful features that you really want in a networking protocol.
Googling “slip over midi” gives a lot of fashion blogging about mini dresses and slips that one wears under them, so I’m not quite sure what you mean.
But if you mean “midi over slip”, then that is the inverse case from what I am suggesting. Midi over slip (and slip could be any tcpip substrate, such as ethernet) has midi messages as the payload, carried via tcpip.
I’m talking about using midi messages to carry tcpip payloads. You can absolutely do it, but it isn’t really what the protocol is designed for.
No, I meant it exactly like that SLIP over MIDI. I know there are plenty of MIDI over TCP/IP and UDP implementations but that's not what I had in mind.
And what google turns up when you enter those exact three words in a row is really none of my business.
I used SLIP all the time back in the day, and I use MIDI all the time in my home music setup. The wikipedia articles don't tell me anything I don't already know.
I suppose someone somewhere has done it (and I have always said that you can), but my best internet searches with a wide variety of terms don't show any old tutorials or products that explain how. Nor can I find anything else that uses MIDI to send tcpip packets over the MIDI connection. Not even a mention.
My Google-fu may be totally weak, but whatever.
I freshly, happily and totally concede that people have in the past used MIDI to send SLIP packets, and it is well understood how. Great. You are totally correct.
But all of this just proves the original point. It either precedes anything on the internet today, or is so obscure that no search engine can find it. Either way, if no one uses it or even bothers to explain how, I think it is pretty fair to conclude that it is rather unergonomic, and hacky, and doesn't provide all the features one really wants in a network connection.
I could be wrong, but my surface level understanding is that it's more of a library version of the external API of GCC than one that gives access to the internals.
You push branch A, then switch to branch B and start working on that. CI failed on branch A, so you stash branch B and switch back to branch A to fix it.
thanks, that makes sense. I don't see how a worktree is more convenient in that case.
Maybe from the kind of work I do? either CI is failing because of something really simple, or something really complicated that means getting a product setup and producing debug messages. If it's a critical fix on branch A, then I'm not working on branch B. I'm testing branch A locally while CI does its thing
Worktrees are useful particularly because they look like entirely separate projects to your IDEs or other project tooling. They are more useful on larger projects with lots of daily commits. If you just use branches then whenever you switch, in the worst case, your IDE has to blow away caches and reconstruct the project layout or build the project fresh. On large projects this takes significant time. But switching your IDE to a different project, there are now two project and build caches to switch between.
reply