This is ridiculous. New developers will learn a completely different skill path from what we learned, and they will get where we are faster than we did.
“People asking if Al is going to take their jobs is like an Apache in 1840 asking if white settlers are going to take his buffalo” (Noah Smith on Twitter, I mean X)
In the rosiest view, the rich give their children private tutors (and always have), and now the poor can give their children private tutors too, in the form of AIs. More realistically, what the poor get is something which looks superficially like a private tutor, yet instead of accelerating and deepening learning, it is one that allows the child to skip understanding entirely. Which, from a cynical point of view, suits the rich just fine...
Imagine a tutor that stays with you as long as you need for every concept of math, instead of the class moving on without you and that compounding over years.
Rather than 1 teacher for 30 students, 1 teacher can scale to 30 students to better address Bloom's 2 sigma problem, which discovered students in a 1:2 ratio with a tutor full time ended up in the 98% of students reliably.
LLMs are capable of delivering this outright, or providing serious inroads to it for those capable and willing to do the work beyond going through the motions.
> Imagine a tutor that stays with you as long as you need for every concept of math, instead of the class moving on without you and that compounding over years.
I remember when I was at the uni, the topics I learned the best were the ones I put effort to study by myself at home. Having a tutor with me all the time will actually make me do the bare minimum as there always were other things to do and I would love to skip the hard parts and move forward.
This is absolutely not an objective review. The person who wrote this is a very particular type of person who Alpha School appeals strongly towards. I'm not saying anything in particular is wrong with the review, but calling it unbiased is incorrect.
Calling the Alpha school "AI" or even "AI to aid learning" is a massive stretch. I've read that article and nothing in there says AI to me. Data collection and on-demand computer-based instruction, sure.
I don't disagree with your premise, but I don't think that article backs it up at all.
Ioannu is saying the paper's idea for training a dense network doesn't work in non-toy networks (the paper's method for selecting promising weights early doesn't improve the network)
BUT the term "lottery ticket" refers to the true observation that a small subset of weights drive functionality (see all pruning papers). It's great terminology because they truly are coincidences based on random numbers.
All that's been disproven is that paper's specific method to create a dense network based on this observation
False. It really was just intended to coalesce packets.
I’ll be nice and not attack the feature. But making that the default is one of the biggest mistakes in the history of networking (second only to TCP’s boneheaded congestion control that was designed imagining 56kbit links)
TCP uses the worst congestion control algorithm for general networks except for all of the others that have been tried. The biggest change I can think of is adjusting the window based on RTT instead of packet loss to avoid bufferbloat (Vegas).
Unless you have some kind of special circumstance you can leverage it's hard to beat TCP. You would not be the first to try.
For serving web pages, TCP is only used by legacy servers.
The fundamental congestion control issue is that after you drop to half, the window is increased by /one packet/, which for all sorts of artificial reasons is about 1500 bytes. Which means the performance gets worse and worse the greater the bandwidth-delay product (which have increased by tens of orders of magnitude). Not to mention head-of-line blocking etc.
The reason for QUIC's silent success was the brilliant move of sidestepping the political quagmire around TCP congestion control, so they could solve the problems in peace
TCP Reno fixed that problem. QUIC is more about sending more parts of the page in parallel. It does do its own flow control, but that's not where it gets the majority of the improvement.
TCP Reno Vegas etc all addressed congestion control with various ideas, but were all doomed by the academic downward spiral pissing contest.
QUIC is real and works great, and they sidestepped all of that and just built it and tuned it and has basically won. As for QUIC "sending more parts of the page in parallel" yes thats what I referred to re head of line blocking in TCP.
There is nothing magic about the congestion control in QUIC. It shares a lot with TCP BBR.
Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs. And most stacks are in userspace. So it is horrifically expensive in terms of watts/byte or cycles/byte sent for a CDN workload (something like 8x as a expensive the last time I looked), and its primarily used and advocated for by people who have metrics for latency, but not server side costs.
> Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs.
That's not quite true. You can offload QUIC connection steering just fine, as long as your NICs can do hardware encryption. It's actually _easier_ because you can never get a QUIC datagram split across multiple physical packets (barring the IP-level fragmentation).
The only real difference from TCP is the encryption for ACKs.
From a CDN perspective, whats missing is there is no kernel stack on FreeBSD / Linux, and no support for sendfile/sendpage and no support for segmentation offload entirely in hardware. So you can't just send an entire file (or a large range) and forget about it, like you can with TCP.
Some NICs, like Broadcom's newer ones, support crypto offloads, but this is not enough to be competitive with TCP / TLS. Especially since support for those offloads are not in any mainline kernel in Linux or BSD.
Normalizing for language and culture seem like the hardest parts of any global survey. How are the translations done of that one question and are there any cultural implications?
reply