SoylentNews is people
SoylentNews
TSMC's Arizona Plant Will Build Apple's 4nm Chips Starting In 2024:
The new $12 billion TSMC plant in Arizona will start to produce Apple's 4nm chips starting in 2024, with the iPhone maker being key to pushing the production forward.
But Apple and other companies wanted to be able to source 4nm parts from the United States, with TSMC relenting.
TSMC previously said it would make 20,000 wafers per month at the Arizona facility, although production may increase from those original plans, the people said. Apple will use about a third of the output as production gets underway.
Apple's most current chips are all produced on a 5nm process and the move to a new 4nm process could allow for improved performance, reduced power draw, and better thermal management. The chips will likely be used in iPhones, iPads, and Macs while Apple's future products could also make use of the technology.
Apple and other major tech companies rely on TSMC for their chipmaking needs, and the change means they'll be able to get more of their processors from the US. Apple Chief Executive Officer Tim Cook has previously told employees that his company plans to source chips from the Arizona plant.
(Score: 3, Informative) by janrinok on Saturday December 03 2022, @04:41PM (3 children)
We run mysql, and we were using ndb cluster - but no longer. Just mysql now.
Now before you go suggesting another db as being much better - are you able to point us to the old version of Perl software that would drive it too? We can't lose details such as that - they are archived all over the internet.
(Score: 2) by RS3 on Sunday December 04 2022, @02:38AM
Not an Oracle shill, at all, but FWIW, I've been running MySQL for more than 14 years in live Internet-facing servers and have had NO problems (and many years before that at home).
I inherited the servers, but of course I've completely rebuilt them from scratch, carrying over some stuff of course. I'm the only admin or any kind of IT person at the location.
Shivers- a couple are running WordPress (Apache, MySQL, php (severe shudders)), again, no problems.
Not too crazy with WordPress plugins- mainstream, mostly from WordPress site.
Had run Joomla, Drupal, and some other specialized MySQL-based stuff. It all worked perfectly, but those things fell through due to sales / business people stuff.
Also love and use phpMyAdmin- fantastic tool to admin MySQL. I do NOT leave it exposed- I make a simple link to it when I run it, in a non-obvious location (IPaddress/~some_directory).
I don't understand all the weeping and gnashing of teeth over php. I've never had a problem with or because of it. I don't think I'm that lucky, in 14+ years, just some simple admin stuff and things seem pretty stable, secure, just works.
There's another great utility I occasionally run is mysqltuner. It's perl. It just does an analysis, gives a report, and makes some suggestions. You take or leave them. One good thing: it will (do its best to) tell you if your configuration will sop up all RAM in a worst-case scenario, so that's been very helpful- tuning hints, cut down on RAM being wasted by large default buffers that your configuration doesn't even use.
I'm not sure of the differences, if any, between MySQL and MariaDB, but it's good to know it's available if/when Oracle does something bad with MySQL. I'll probably make the switch in an upcoming rebuild.
(Score: 0) by Anonymous Coward on Sunday December 04 2022, @11:45AM (1 child)
In SN's case SN is probably stuck with MySQL for legacy reasons.
So is MySQL NDB the cause or indirect cause of the data loss? MySQL fanboys and MySQL proponents would often mention MySQL clustering as one of MySQL's advantages.
(Score: 2) by janrinok on Sunday December 04 2022, @12:16PM
It appears that it may have been a combination of factors but as for which one set the whole thing in motion I could not say.
I am not going to comment further until NCommander writes a short piece, which he has said he intends to do. As you said, the fanboys will clutch at anything, as will MySQL's detractors.