Amadiro

That's a quite different thing, OpenAI has billions of USD/year cash flow, and when you have that there's many many potential way to achieve profitability on different time horizons. It's not a situation of chance but a situation of choice.

Anyway, how much that matters for an investor is hard to form a clear answer to - investors are after all not directly looking for profitability as such, but for valuation growth. The two are linked but not the same -- any investor in OpenAI today probably also places themselves into a game of chance, betting on OpenAI making more breakthroughs and increasing the cash flow even more -- not just becoming profitable at the same rate of cash flow. So there's still some of the same risk baked into this investment.

But with a new startup like LeCun's is going to be, it's 100% on the risk side and 0% on the optionality side. The path to profitability for a startup would be something like 1) a breakthrough is made 2) that breakthrough is utilized in a way that generates cash flow 3) the company becomes profitable (and at this point hopefully the valuation is good.)

There's a lot of things that can go wrong at every step here (aside from the obvious), including e.g. making a breakthrough that doesn't represent a defensible mote for your startup, failing to build the structure of the business necessary to generate cashflow, ... OpenAI et al already have a lot of that behind them, and while that doesn't mean that they don't face upcoming risks and challenges, the huge amount of cashflow they have available helps them overcome these issues far more easily than a startup, which will stop solving problems if you stop feeding money into it.

It's also because around 20 years ago there was a "reset" when we switched from x86 to x86_64. When AMD introduced x86_64, it made a bunch of the previously optional extension (SSE up to a certain version etc) a mandatory part of x86_64. Gentoo systems could already be optimized before on x86 using those instructions, but now (2004ish) every system using x86_64 was automatically always taking full advantage of all of these instructions*.

Since then we've slowly started accumulating optional extensions again; newer SSE versions, AVX, encryption and virtualization extensions, probably some more newfangled AI stuff I'm not on top of. So very slowly it might have started again to make sense for an approach like Gentoo to exist**.

* usual caveats apply; if the compiler can figure out that using the instruction is useful etc.

** but the same caveats as back then apply. A lot of software can't really take advantage of these new instructions, because newer instructions have been getting increasingly more use-case-specific; and applications that can greatly benefit from them will already have alternative code-pathes to take advantage of them anyway. Also a lot of the stuff happening in hardware acceleration has moved to GPUs, which have a feature discovery process independent of CPU instruction set anyway.

In my experiments claude4 opus generated by far the best code (for my taste and purposes) but it's also a pretty expensive model. I think I used up $40 in one evening of frantic vibe-coding.

It's even worse than that, because the way they extract the causal link is just a regex, so

"vaccines > autism"

because

"Even though the article was fraudulent and was retracted, 1 in 4 parents still believe vaccines can cause autism."

I think this could be solved much better by using even a modestly powerful LLM to do the causal extraction... The website claims "an estimated extraction precision of 83% " but I doubt this is an even remotely sensible estimate.

Also when you visit most japanese websites you can see this phenomenon.

I've read an explanation once that this is because culturally, japanese people perceive a wealth of information and choice as being re-assuring and trustworthy, while most westerners feel more re-assured by seeing less content and choice presented in a more minimalist kind of way.

In my view, there is a major flaw in his argument is his distinction into pure engineering and science:

> We can make a rough distinction between pure engineering and science. There is no sharp boundary, but it’s a useful first approximation. Pure engineering seeks to produce a product that may be of some use. Science seeks understanding. If the topic is human intelligence, or cognitive capacities of other organisms, science seeks understanding of these biological systems.

If you take this approach, of course it follows that we should laugh at Tom Jones.

But a more differentiated approach is to recognize that science also falls into (at least) two categories; the science that we do because it expands our capability into something that we were previously incapable of, and the one that does not. (we typically do a lot more of the former than the latter, for obvious practical reasons)

Of course it is interesting from a historical perspective to understand the seafaring exploits of Polynesians, but as soon as there was a better way of navigating (i.e. by stars or by GPS) the investigation of this matter was relegated to the second type of science, more of a historical kind of investigation. Fundamentally we investigate things in science that are interesting because we believe the understanding we can gain from it can move us forwards somehow.

Could it be interesting to understand how Hamilton was thinking when he came up with imaginary numbers? Sure. Are a lot of mathematicians today concerning themselves with studying this? No, because the frontier has been moved far beyond.*

When you take this view, it´s clear that his statement

> These considerations bring up a minor problem with the current LLM enthusiasm: its total absurdity, as in the hypothetical cases where we recognize it at once. But there are much more serious problems than absurdity.

is not warranted. Consider the following, in his own analogy:

> These considerations bring up a minor problem with the current GPS enthusiasm: its total absurdity, as in the hypothetical cases where we recognize it at ones. But there are much more serious problems than absurdity. One is that GPS systems are designed in such a way that they cannot tell us anything about navigation, planning routes or other aspects of orientation, a matter of principle, irremediable.

* I´m making a simplifying assumption here that we can´t learn anything useful for modern navigation anymore from studying Polynesians or ants; this might well be untrue, but that is also the case for learning something about language from LLMs, which according to Chomsky is apparently impossible and not even up for debate.

Is there any strong reason to use GeoParquet instead of straight up parquet if all I'm interested in is storing and operating on lat/lons?

I'm curious if it compresses them better or something like that. I see lots of people online saying it compresses well (but mostly compared to .shp or similar) but normal parquet (.gz.parquet or .snappy.parquet) already does that really well. So it's not clear to me if I should spend time investigating it...

I mostly process normal parquet with spark and sometimes clickhouse right now.

Sure but all pre-made, battle-tested tree datastructures you'd use in production in all languages already come with some form of iterator that you can just for-loop over, so the original articles point is still moot.

I think figuring out the fastest version of a shader at runtime is very non-trivial, I'm not aware of any game or engine that can do this.

I think it'd be possible in principle, because most APIs (D3D, GL, Vulkan etc) expose performance counters (which may or may not be reliable depending on the vendor), and you could in principle construct a representative test scene that you replay a couple times to measure different optimizations. But a lot of games are quite dynamic, having dynamically generated scenes and also dynamically generated shaders, so the number of combinations you might have to test seems like an obstacle. Also you might have to ask the user to spend time waiting on the benchmark to finish.

You could probably just do this ahead of time with a bunch of different GPU generations from each vendor if you have the hardware, and then hard-code the most important decision. So not saying it'd be impossible, but yeah I'm not aware of any existing infrastructure for this.

No need to scrape anything when you can just subpoena. That is the business palantir is in.

It looks more like Desktop GL might move to mobile devices soon. nvidia seems to be pushing really hard in that direction. But it'll remain to be seen where things go.

Eh, a lot of the recent articles on hackernews about GL have been fairly low-quality and were badly researched (like the guy who complained about timer queries blocking, because he blatantly didn't understand how CPU/GPU communication works) No need to buy into the FUD.

- if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall.

- if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving.

- extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D.

- in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as:

- things you do wrong

- things you should do differently to increase performance

- general debug information

- information on memory usage and where your buffers are stored

No, that would make no sense whatsoever. You seem to be somewhat misinformed about GL...

* OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already.

* Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD.

* AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it.

Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.

I use chromium with a 5760*1080 resolution, and I frequently have > 150 tabs open across 3 browser windows, and I really have no complaints. I also occasionally peruse or develop WebGL/ASM.js/emscripten applications, so I suppose I fit into your description as someone who is "pushing the web browser hard".

All functionality I need to access quickly is accessible through shortcuts, so I don't typically need to access the "hamburger-menu" very often. The only thing I really use it for is to open the settings tab.

It's a matter of perspective -- to someone who has taken a university class on lambda calculus/on logic that had a chapter on lambda calculus (e.g. as part of a M.Sc. in mathematical logic or CS), anything in RWH would probably seem extremely basic and superficial. It doesn't even introduce most of the basic things a first chapter in a book on lambda calculus would probably introduce you to.