Yes. The CPU and GPU demand has nothing to do with it. The reason is the car industry.
For some reason in early 2020 all the car industry execs were convinced that people would buy dramatically fewer cars in 2020, due to pandemic crashing demand. Because they have a religious aversion to holding any stock they decided to shift the risk over to their suppliers, fucking said suppliers over, as the car industry normally does when they expect demand shifts. The thing that made this particular time special as opposed to business as usual is that the car execs all got it wrong, because people bought way more cars due to pandemic rather than less, due to moving out of cities and avoiding public transit. So they fucked over their suppliers a second time by demanding all those orders back.
Now, suppose you're a supplier of some sort of motor driver or power conversion chip (PMIC) in early 2020. You run 200 wafers per month through a fab running some early 2000s process. Half your yearly revenue is a customized part for a particular auto vendor. That vendor calls you up and tells you that they will not be paying you for any parts this year, and you can figure out what to do with them. You can't afford to run your production at half the revenue, so you're screwed. You call up your fab and ask if you can get out of that contract and pay a penalty for doing so, and you reduce your fab order to 100 wafers per month, so you can at least serve your other customers. The fab is annoyed but they put out an announcement that a slot is free, and another vendor making a PMIC for computer motherboards buys it, because they can use the extra capacity and expect increased demand for computers. So far so normal. One vendor screwed, but they'll manage, one fab slightly annoyed that they had to reduce throughput a tiny bit while they find a new buyer.
Then a few months later the car manufacturer calls you again and asks for their orders back, and more on top. You tell them to fuck off, because you can no longer manufacture it this year. They tell you they will pay literally anything because their production lines can't run without it because (for religious reasons) they have zero inventory buffers. So what do you do? You call up your fab and they say they can't help you, that slot is already gone. So you ask them to change which mask they use for the wafers you already have reserved, and instead of making your usual non-automotive products, you only make the customized chip for the automotive market. And then, because they screwed you over so badly, and you already lost lots of money and had to lay off staff due to the carmaker, you charge them 6x to 8x the price. All your other customers are now screwed, but you still come out barely ahead. Now, of course the customer not only asked for their old orders back, but more. So you call up all the other customers of the fab you use and ask them if they're willing to trade their fab slots for money. Some do, causing a shortage of whatever they make as well. Repeat this same story for literally every chipmaker that makes anything used by a car. This was the situation in January 2021. Then, several major fabs were destroyed (several in Texas, when the big freeze killed the air pumps keeping the cleanrooms sterile, and the water pipes in the walls of the buildings burst and contaminated other facilities, and one in Japan due to a fire) making the already bad problem worse. So there are several mechanisms that make part availability poor here:
1. The part you want is used in cars. Car manufacturers have locked in the following year or so of production, and "any amount extra you can make in that time" for a multiple of the normal price. Either you can't get the parts at all or you'll be paying a massive premium.
2. The part you want is not used in cars, but is made by someone who makes other parts on the same process that are used in cars. Your part has been deprioritized and will not be manufactured for months. Meanwhile stock runs out and those who hold any stock massively raise prices.
3. The part you want is not used in cars, and the manufacturer doesn't supply the car industry, but uses a process used by someone who does. Car IC suppliers have bought out their fab slots, so the part will not be manufactured for months.
4. The part you want is not used in cars, and doesn't share a process with parts that are. However, it's on the BOM of a popular product that uses such parts, and the manufacturer has seen what the market looks like and is stocking up for months ahead. Distributor inventory is therefore zero and new stock gets snapped up as soon as it shows up because a single missing part means you can't produce your product.
So here we are. Shameless plug - email me if you are screwed by this and need help getting your product re-engineered to the new reality. There's a handful of manufacturers, usually obscure companies in mainland China that only really sell to the internal market, that are much less affected. Some have drop-in replacement parts for things that are out of stock, others have functionally similar parts that can be used with minor design adaptation. I've been doing that kind of redesign work for customers this whole year. Don't email me if you work in/for the car industry. You guys poisoned the well for all of us so deal with it yourselves.
We use it for a mission-critical backend in TypeScript. After 20 years (was previously primarily a Java programmer for the first part of my career) I feel I have finally hit environment "nirvana" with having our front-end in React/TypeScript, backend in Node/TypeScript with API in Apollo GraphQL, DB is Postgres.
Having the same language across our entire stack has huge, enormous, gargantuan benefits that shouldn't be underestimated, especially for a small team. Being able to easily move between backend and frontend code bases has had a gigantic positive impact on team productivity. Couple that with auto-generating client and server-side typescript files from our GraphQL API schema definition has made our dev process pretty awesome.
Another point is that he is now free to go out and get another job if he wants to, while still getting the ad money from Photopea every year. That's the whole point of building up a passive income stream - once you uncouple the income from actually working, you are then free to do whatever you want with your time - including selling it for a salary like most people so.
I'm a Go developer and I notice a lot of other Go developers instantly suggest things like GORM to noobs writing applications. Whereas I always suggest against it.
I'm a big advocate of understand your data model at the database level. Need to join on too many tables is too easy to do with an ORM.
My go-to strategy for SQL is simple. Abstract your SQL as far away from your application as possible. Not just by using interfaces in your application, but by using stored procedures in your database.
In my mind SQL is just another service your application depends on. And you want that interface to be as simple as possible for your application. If you need to tweak SQL performance it should not need any input from your application. I could completely migrate to a new table relationship structure without the application realising if that was what was needed. You could even go as far as to unit test just your SQL code if you wanted, something you can't do too easily when it's in your application.
Yes, if you need to return new data then you need to update your stored proc and code. But that's so worth it in my opinion for that extra layer of abstraction.
My opinion is slightly skewed from a decently sized business perspective, but I do still follow this pattern in personal projects. When migrating applications to different tech stacks (like Java to Go, or C# to Go) this abstraction has meant the world to us.
Parasite load seems to affect negatively cognitive abilities.
Decreased Parasite Load and Improved Cognitive Outcomes Caused by Deworming and Consumption of Multi-Micronutrient Fortified Biscuits in Rural Vietnamese Schoolchildren
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3144834/
That is insufficent, try going through TCP/IP Illustrated Vol 1 at least and really learning TCP/IP and use tcpdump to rip apart packets. You should learn in detail the tcp state diagram and how to read netstat output. Know what the TCP 3-way handshake is and PTMU discovery and 4-way connection teardown and be able to apply that knowledge to debugging.
Learn how to program in C at least well enough to write simple clients and servers, write a trivial threaded application using something like pthreads (just a couple ideas). Then start reading Advanced Programming in the Unix Environment. Really learn how to use Strace -- you should know what the difference is between a system call and a library call and be familiar with many of the common system calls you see in the output of that. You should understand the sockets API and file IO APIs. Should be able to understand socket and file descriptors and understand the output of lsof and be able to use it to debug problems.
Pick up the latest version of the Daemon book and learn how a Unix system is architected and what the different kernel subsystems are. Start poking around in the linux kernel sources. Use your C knowledge to make some toy modifications to the kernel (a /proc entry that echos back 'hello world' when you cat it for example). Read Unix Systems for Modern Architecture by Schimmel as a start if you want to go further here.
Take the same approach to the higher level aspects of systems. Your package manger is important so if you are on a RedHat system you should be able to take a trivial piece of C code that you wrote and properly package it so that you can build it, package it, and install it.
If you've built by hand or seen C packages built by hand you should have encountered 'configure; make; make install'. You should write a toy C program with a portability issue (find a Linux/FreeBSD portability issue and write a toy C program with that problem in it), and write an autoconf script so that you can run your code on either O/S.
Pick up either CFEngine, Puppet or Chef and learn how to use it (you can also add Salt and/or Ansible, but please don't consider yourself an expert if you don't understand the limitations of those two). Study Mark Burgesses Promise Theory.
Learn at least one high level scripting language that is in common use: Ruby, Python or Perl. You should also learn bash (and ideally learn old school /bin/sh and its differences with bash as well), but you cannot stop at just shell scripts.
Ideally you really learn how to program and write 10,000+ line object oriented programs, and write code that is tested. Learn what inheritance and composition are and why some software developers argue you should favor composition over inheritance. Learn the Law of Demeter and other principles.
Install and use something other than Linux to broaden your horizons a bit. FreeBSD at least. Solaris or one of the Solaris derived distros would be even better. Having a Mac as a laptop is also useful but I'm not sure it replaces playing with different server O/Sen.
Then, you definitely do also want Limoncelli's book and Nemeth's Unix and Linux System Administration Handbook and be able to configure a wide range of different systems apps (sshd, ntpd, SMTP mailers, apache, nginx, etc). If all you can do is install and configure apps, though, then you're no better than a scriptkiddie running scripts they download off the internet if you can't write them yourself. You won't understand what you're actually doing, and won't have a prayer of debugging some of the harder problems you can run into in architecting and debugging issue that come up in running those apps in a large and successful environment.
I have been starting the process of learning hand woodworking by watching the likes of Paul Sellers. It is amazing how much knowledge there is available on YouTube about craftsmanship. Combining YouTube with niche web forums multiplies the learning power. I'm already able to dimension boards with nothing but a hand plane, a combination square, a depth gauge, and winding sticks. I'm just at the start of my journey but I'm so thankful YouTube and all these creators are out there to introduce me to this new hobby!
I keep meaning to write a blog post with some details on this, but as with many things, I usually end up coding instead.
Sublime Text 2 is almost entirely C++ (with a smattering of Objective C for Cocoa and Python for plugins). Coding is generally fairly straight forward: code on one platform (mostly Linux at the moment, but I switch around frequently), and then make sure it still compiles elsewhere.
Sublime Text 2 itself uses a custom UI toolkit. There are a lot of apps where this may not make sense, but it's not such an unreasonable choice for Sublime Text, where I always knew that a lot of the UI controls were going to have to be custom no matter the toolkit (e.g., the text control and tab controls). The UI toolkit sits on top of a cross platform abstraction layer, which is more a union of platform functionality rather than lowest common denominator.
Came here to post this. No, seriously, exactly this. That was my favorite quote out of the entire comments!
FTP with curlftpfs and SVN/CVS isn't "trivial" to 99.9% of the population!
It's the same reason that sites like SlashDot were filled with all sorts of reasons why the iPad would never work. Why would you use that?!? You could do the same thing with ______.
I primarily use Flask for my research project. It was quick to pick up and honestly, I like a more barebones style - one of the reasons I use Sublime Text over IDEs. Plus Miguel Grinberg's tutorial is fantastic at getting you on your feet (though I'm still sour over changes compared to his original tutorial, more because its made it difficult to onboard new developers).
A similar root cause issue is developing life threatening blood clots from sitting too long. Both suspension trauma and blood clots in the legs come from a clever optimization of our circulatory system. The heart can't actually pump blood out of the legs. It counts on muscle activity to make the flow happen.
If you sit for many hours, like on a cross country or cross ocean flight, or because you are a dev or gamer with tremendous concentration and focus, the blood quite literally just sits in your legs and eventually starts to coagulate. It doesn't matter how much exercise you get the rest of your day, those 6 or 8 hours of sitting can quite literally kill you through the creation of a blood clot that then flows through your system and blocks blood flow to the heart or brain (all learned personally when I developed such a clot from routinely sitting long hours in a coffee shop with my laptop and 100% focus).
If you're like me and can focus easily for many hours straight, get a Fitbit, turn on activity tracking, and when it tells you you haven't walked around recently get up and walk around. It's much less impactful to your concentration than an emergency ER visit followed by a lifetime of prescription blood thinners to reduce the now much higher risk of a second clot.
> ... When undergraduate students at Peking University, which was at the center of the incident, were shown copies of the iconic photograph [of Tank Man] 16 years afterwards, they were "genuinely mystified." One of the students said that the image was "artwork." It is noted in the documentary Frontline: The Tank Man that he whispered to the student next to him "89," which led the interviewer to surmise that the student may have concealed his knowledge of the event.
Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware exists.
So, why is SPARC left off in all these analyses? It's right there ready to pick up and deploy. More open, easy to acquire, and trustworthy (far as licensing) than than a POWER chip although slower for sure.
I recommend reading the following books/presentations, I have read all of them several times and it has given me a very lucrative, wonderful deep understanding of TCP/IP (including UDP), programming network connected applications, creating complex network diagrams, and being able to perfectly talk with all individuals in networking from the non-technical to telco engineers, work as an embedded engineer, network engineer and more.
TCP/IP Illustrated Volume 1: The Protocols
TCP/IP Illustrated Volume 2: The Implementation
Network Flow Analysis
Computer Networking: A Top-Down Approach
Introduction to Sockets Programming in C using TCP/IP
Beej's Guide to Network Programming
Programming and Automating Cisco Networks
CCNA Routing and Switching Official Cert Guide
CCNA Datacenter Official Cert Guide
CCNP ROUTE, SWITCH, and TSHOOT Lab Manuals
CCIE and CCDE Evolving Technologies Study Guide
I would highly recommend getting a cheap certification rack from Amazon once you get better book knowledge (CCNA/CCNP Collab, Wireless and Routing and Switching) to increase your knowledge 20x. When I did not have my own hardware there were just so many questions and things I wanted to do that were very complex or not possible to do with training simulators, books, etc.
With the high quality managed switches you can see how your apps can affect the network, integrate your work with network connected devices, automate network devices and many more things that wouldn't give you as deep as an understanding when using an unmanaged network (e.g. create your own software that runs on routers, switches, VOIP phones and linux servers).
I think that at this point, C++ has basically to be treated the same as the English language. Sure, you could write sentences that span three pages, employ Shakespearean vocabulary or words that hardly anyone has known since the abolition of Classics from university admissions tests, or encode another layer of meaning in the bit pattern of when you do and when you don't use Oxford commas. What makes something good English communication is not whether you used those features correctly, employed the most in vogue ones or found the "most elegant abstraction" ("there's this one word attested in a handful of 14th century sources that captures exactly what I want to say, so I'll use it without explanation"), but whether you have struck the right tradeoff of minimising the combined effort put in by you and your audience and conveying your message faithfully.
Of course, for English, this is exactly the sort of problem that is addressed by style guides (and teachers/peers reacting to you, and natural selection). I think what we need is more and better opinionated C++ style guides that don't just talk about what line to place your { on, but have the confidence to say things on the level of "std::move may add a marginal amount of efficiency, but greatly detracts from the legibility of code. Avoid using it altogether."
Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.
The only thing about Linux I never really like is the package system.
Like if you want to install a new software, you usually don’t get .exe or .dmg. If you are lucky, the developer or some fans took the time to package it. Then you can do ‘apt-get’ ‘yum’ or ‘pacman’. However, packages got stalled and sometimes don’t match the original author intent. You can also build from sources, but it takes time and you have to know a bit of CLI. It never felt true freedom to me. But more like whatever the community feels make sense for whatever distribution weird dictactorship. Just a feeling and I still love and support Linux.
The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier.
Why are there no other "competitors" in this space? Why do most other languages go with the alternative route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Butterick made his own programming language called Pollen [1] to publish this site. [2] Pollen is implemented in the Racket programming language. [3] He has another online book called Beautiful Racket [4] about language-oriented programming in Racket.
For some reason in early 2020 all the car industry execs were convinced that people would buy dramatically fewer cars in 2020, due to pandemic crashing demand. Because they have a religious aversion to holding any stock they decided to shift the risk over to their suppliers, fucking said suppliers over, as the car industry normally does when they expect demand shifts. The thing that made this particular time special as opposed to business as usual is that the car execs all got it wrong, because people bought way more cars due to pandemic rather than less, due to moving out of cities and avoiding public transit. So they fucked over their suppliers a second time by demanding all those orders back.
Now, suppose you're a supplier of some sort of motor driver or power conversion chip (PMIC) in early 2020. You run 200 wafers per month through a fab running some early 2000s process. Half your yearly revenue is a customized part for a particular auto vendor. That vendor calls you up and tells you that they will not be paying you for any parts this year, and you can figure out what to do with them. You can't afford to run your production at half the revenue, so you're screwed. You call up your fab and ask if you can get out of that contract and pay a penalty for doing so, and you reduce your fab order to 100 wafers per month, so you can at least serve your other customers. The fab is annoyed but they put out an announcement that a slot is free, and another vendor making a PMIC for computer motherboards buys it, because they can use the extra capacity and expect increased demand for computers. So far so normal. One vendor screwed, but they'll manage, one fab slightly annoyed that they had to reduce throughput a tiny bit while they find a new buyer.
Then a few months later the car manufacturer calls you again and asks for their orders back, and more on top. You tell them to fuck off, because you can no longer manufacture it this year. They tell you they will pay literally anything because their production lines can't run without it because (for religious reasons) they have zero inventory buffers. So what do you do? You call up your fab and they say they can't help you, that slot is already gone. So you ask them to change which mask they use for the wafers you already have reserved, and instead of making your usual non-automotive products, you only make the customized chip for the automotive market. And then, because they screwed you over so badly, and you already lost lots of money and had to lay off staff due to the carmaker, you charge them 6x to 8x the price. All your other customers are now screwed, but you still come out barely ahead. Now, of course the customer not only asked for their old orders back, but more. So you call up all the other customers of the fab you use and ask them if they're willing to trade their fab slots for money. Some do, causing a shortage of whatever they make as well. Repeat this same story for literally every chipmaker that makes anything used by a car. This was the situation in January 2021. Then, several major fabs were destroyed (several in Texas, when the big freeze killed the air pumps keeping the cleanrooms sterile, and the water pipes in the walls of the buildings burst and contaminated other facilities, and one in Japan due to a fire) making the already bad problem worse. So there are several mechanisms that make part availability poor here:
1. The part you want is used in cars. Car manufacturers have locked in the following year or so of production, and "any amount extra you can make in that time" for a multiple of the normal price. Either you can't get the parts at all or you'll be paying a massive premium.
2. The part you want is not used in cars, but is made by someone who makes other parts on the same process that are used in cars. Your part has been deprioritized and will not be manufactured for months. Meanwhile stock runs out and those who hold any stock massively raise prices.
3. The part you want is not used in cars, and the manufacturer doesn't supply the car industry, but uses a process used by someone who does. Car IC suppliers have bought out their fab slots, so the part will not be manufactured for months.
4. The part you want is not used in cars, and doesn't share a process with parts that are. However, it's on the BOM of a popular product that uses such parts, and the manufacturer has seen what the market looks like and is stocking up for months ahead. Distributor inventory is therefore zero and new stock gets snapped up as soon as it shows up because a single missing part means you can't produce your product.
So here we are. Shameless plug - email me if you are screwed by this and need help getting your product re-engineered to the new reality. There's a handful of manufacturers, usually obscure companies in mainland China that only really sell to the internal market, that are much less affected. Some have drop-in replacement parts for things that are out of stock, others have functionally similar parts that can be used with minor design adaptation. I've been doing that kind of redesign work for customers this whole year. Don't email me if you work in/for the car industry. You guys poisoned the well for all of us so deal with it yourselves.