I admit I know next to nothing about this stuff, but something doesn't add up. If everything has a Schwarzchild radius determined by its mass, then should we conclude that particles like electrons and protons also have a (very small) Schwarzchild radius? If the smaller it is, the sooner it explodes, then shouldn't atomic particles have all finished exploding a long time ago? When they explode, what do they eject, if not more subatomic particles like themselves? Alternatively, is the explanation that atomic particles are extended bodies whose sizes exceed their Schwarzchild radii instead being of point masses? If so, then what kind of stuff fills the interior of an electron? I don't have any answers but I have a feeling we're on shaky ground when we start trying to extrapolate general relativity concepts to atomic scales.

edit: typo

I strongly feel that the spammers thing is smoke and mirrors.

The deal at $54.20 was maybe OK for him a month ago (it was great for Twitter because nobody else was interested at that price). Since then, Twitter reported disappointing numbers for the past quarter, and the entire market took a nose dive, with tech hit especially hard.

TWTR stock price was in the mid-30s before Musk's offer. Without the offer, and with the disappointing numbers, and with the recent market development, one could reasonably assume that the stock would be below 30 today.

Musk should just pay the break fee of $1bn, and renegotiate for $42.69 or whatever meme number he fancies. Why pay $42bn total for something when you can get it for $30bn.

Does python not have built in documentation search? In R I use `??searchterm`.

Sorry to depart from the feel-good narrative, but this kind of student labor is token or symbolic at best.

The kinds of jobs that students can perform are not nearly the kind of jobs that a college with a physical plant to maintain, professors to pay, finances to administer, etc. can make a meaningful dent in. (By and large), students are not going to be doing electrical work, maintenance, financial accounting, administration, etc. -- the day to day necessary jobs that keep an institution running -- at all, or enough to be offsetting the costs of those professionals and paying for salaries of the faculty. And you wouldn't want students to be handling many of the jobs that rely on people to conscientiously do them for years, and have institutional memory in mind. They're there to be students, not workers. That's why most student jobs are of the type similar to dorm cleaners, kitchen staff, library, computer room, etc. -- short term temp work requiring no great specific skills.

The article itself acknowledges that much of the income comes from the endowment, grants, donations. If you wanted to start a school on the premise of student labor paying for it, without these existing sources, there would be no way. The cost of running a school is simply way too high in developed countries to do this.

Having students work is not a bad thing. But it isn't some utopian possibility to solve the problems of the cost of education at nearly any typical school. To make this possible you'd have to start something like an educational coop in a developing country. And I doubt that would be a significant contributor to higher education, until it got larger and more professional, at which point you would start to run into the exact same issues above.

I'm heartened by the interest in better packaging and it seems like it's having a moment. Last week Cruz Foam[0] (probably a direct competitor) had an announcement that it had some celebrity investors[1]. It's probably not a popular opinion but I think adding more regulations or incentives (tax breaks) to discourage the use of non-biodegradable packaging, especially in foods, is long overdue.

[0] - https://www.cruzfoam.com [1] - https://www.cruzfoam.com/post/meet-our-new-investors-advisor...

I've always said it's not the Tree of Life, but rather the DAG of Life.

The issue is that there is no incentive for banks to increase interest rates on accounts as they are already sitting on too much cash. Banks make money by lending money out, in times where banks are strapped for cash on hand, you will see interest rates increase. I don’t see this changing in the near future.

A library I designed a few years ago (https://github.com/Netflix/vectorflow) is also much faster than pytorch/tensorflow in these cases.

In "small" or "very sparse" setups, you're memory bound, not compute bound. TF and Pytorch are bad at that because they assume memory movements are worth it and do very little in-place operations.

Different tools for different jobs.

Yeah back in the 90's it was called "round-tripping"

https://www.ibm.com/docs/en/rhapsody/8.2?topic=developing-ro...

I did a lot of code generation work in those years, working on the two dominant Mac-based generators (AppMaker and Prototyper) but was never ambitious enough to try round-tripping because of the horrors of parsing C++.

The telling quote is:

"Dinosaurs: The Final Day with Sir David Attenborough will be broadcast on BBC One on 15 April at 18:30 BST. A version has been made for the US science series Nova on the PBS network to be broadcast later in the year."

say no more.

I wonder how many OpenSCAD wrappers now exist? I know of scad-clj [0], openpyscad [1], and solidpython [2].

I particularly like scad-clj, because of `lein auto generate`. It watches source files, and regenerates the OpenSCAD files automatically, which OpenSCAD then also picks up. Although I'm not well versed in Clojure, and find debugging Clojure tricky, the workflow is just so good.

[0] https://github.com/farrellm/scad-clj

[1] https://github.com/taxpon/openpyscad

[2] https://github.com/SolidCode/SolidPython

Isn’t Kolmogorov Complexity hard to measure, because it depends on the language chosen?

Looks like at least some of the authors are working for Google (if not everyone), with compiler backgrounds. I wonder if this is a strategical investment from Google to make cxx like approach more robust? Chrome team showed some interests on using Rust but not sure if there's any significant code written in Rust from then. Benefit from using Rust beside well isolated library might be quite limited without this kind of lifetime annotation while interop itself is additional cognitive overheads for programmers.

I grew up hearing a lot of buzz for concept maps (or mind maps as I heard). I never found them to be as powerful as advertised.

A concept map is slightly easier than writing in bulletpoints because it can ignore structure. But this makes it incredibly difficult for anyone, including myself, to read after it is written.

At best, I use a concept map as an intermediary stage for figuring out how to write in bulletpoints, write in paragraphs, or draw in diagrams. This intermediary stage never lasts overnight for me, and I discard the concept map immediately.

There's the famous Feynman method i.e. Study hard, Teach it to others, Identify the gaps in your own knowledge, and Simplify/Synthesize.

But people often also forget that there is another method associated with Feynman aka The Feynman Algorithm (which was outlined by his colleague Murray Gell-Mann, a noble prize winning physicist himself). This method goes as follows:

1. Write down the problem. 2. Think real hard. 3. Write the solution.

Not to discount or discredit anything (or anyone) here but we must understand that Feynman was no average person and that his advice on anything related to learning or problem-solving must be viewed through an optics that adequately adjusts for his intellect as well.

If you are interested in transmitting data over sound between airgapped devices, make sure to also checkout ggwave [0]. I've been working on this library on and off during the past year in my free time. I focused on making a FSK protocol that is robust in noisy environments at the cost of low bandwidth. Found some fun applications in various hobby projects.

[0] https://github.com/ggerganov/ggwave

I think it's worth repeating this:

While there are platforms with better and worse hardware sources of unpredictable bits, the problem with Linux /dev/random isn't so much a hardware issue, but rather a software one. The fundamental problem Linux tries to solve isn't that hard, as you can see from the fact that so many other popular platforms running on similar hardware have neatly solved it.

The problem with the LRNG is that it's been architecturally incoherent for a very long time (entropy estimation, urandom vs random, lack of clarity about seeding and initialization status, behavior doing bootup). As a result, an ecosystem of software has grown roots around the design (and bugs) of the current LRNG. Major changes to the behavior of the LRNG breaks "bug compatibility", and, because the LRNG is one of the core cryptographic facilities in the kernel, this is an instance where you really really don't want to break userland.

The basic fact of kernel random number generation is this: once you've properly seeded an RNG, your acute "entropy gathering" problem is over. Continuous access to high volumes of high-entropy bits are nice to have, but the kernel gains its ability to satisfy gigabytes of requests for random numbers from the same source that modern cryptography gains its ability to satisfy gigabytes of requests for ciphertext with a 128 bit key.

People looking to platform hardware (or who fixate on the intricacies of threading the LRNG isn't guest VMs) are mostly looking in the wrong place for problems to solve. The big issue today is that the LRNG is still pretty incoherent, but nobody really knows what would break if it was designed more carefully.