> We don't really know where the capability ceiling of the current approach is
We do know, that the ceiling is below AGI. And it's not a matter of opinion - LLMs can not achieve AGI due to their design. Anyone telling you otherwise is lying to you.
And it doesn't matter how many or how severe bugs they can find, because it's not about what they produce, but how they produce it.
> We do know, that the ceiling is below AGI. And it's not a matter of opinion - LLMs can not achieve AGI due to their design.
[citation definitely needed]
> And it doesn't matter how many or how severe bugs they can find, because it's not about what they produce, but how they produce it.
AGI is defined by the practical outcomes, not by the way the outcomes are achieved. You have no way to know that scaled-up Transformers predicting the next token will never result in human-level intelligence, since we currently have no idea where the ceiling of that approach is.
If you're not even familiar with how LLMs work, perhaps you should restrain yourself from confidently talking about this topic until you educate yourself. You're only spreading misinformation.
> AGI is defined by the practical outcomes, not by the way the outcomes are achieved
That for sure would be a very convenient definition, especially for all those AI labs trying to convince investors that they achieved AGI. Unfortunately everyone knows, that knowing the right answer isn't the same as knowing where that answer came from.
> If you're not even familiar with how LLMs work, perhaps you should restrain yourself from confidently talking about this topic until you educate yourself. You're only spreading misinformation.
I am very familiar with how LLMs work, and I am telling you that there is no consensus that they cannot achieve AGI in the machine learning community. Some people think so (such as Yann LeCun), others disagree. We just don't know yet.
> That for sure would be a very convenient definition, especially for all those AI labs trying to convince investors that they achieved AGI. Unfortunately everyone knows, that knowing the right answer isn't the same as knowing where that answer came from.
... and so what? Your response was that they're not a company - Mozilla Corporation IS a private, for-profit company and one of their responsibilities is managing Firefox. Similar structure is used by OpenAI, so I guess OpenAI is also not a company?
So the top-most entity is the Mozilla Foundation, they control and dictate what the subsidiary, also called Mozilla, can and cannot do. The OpenAI foundation cannot dictate what OpenAI Corp can and cannot do.
1. Mozilla isn't working in a capital intensive domain like Transformer Tech unlike OpenAI so there is no need to bend over demands this much.
2. Mozilla Corp is fully owned by Mozilla Foundation. OpenAI Corp was created by the OpenAI non profit to take external investment. The OpenAI non profit chose to give chunks of the OpenAI Corp to investors because it needed money. By selling stakes, they gave control of the company away. That's the difference.
3. OpenAI Corp answers to their stakeholders of which OpenAI foundation is only one and a minor stakeholder. Mozilla Corp answers to Mozilla Foundation only. That's the difference.
4. Presentation. The mozilla websites for the foundation and the subsidiary both use the org domain which is used by non profits, unlike openain's com use. Not a rule but a choice in presentation.
"Through special voting and governance rights held solely by the OpenAI Foundation, the OpenAI Foundation appoints all members of the board of directors of OpenAI Group and can replace directors at any time."
--
> Mozilla Corp is fully owned by Mozilla Foundation
~85% of Mozilla Corp's revenue comes from "search partnerships, subscriptions and advertising revenue" a.k.a. from Google - not from Mozilla's own products.
Mozilla Corp is in practice owned by Google.
--
> Mozilla Corp answers to Mozilla Foundation only
In 2020 Mozilla laid off 250 employees[0] and then gave its CEO a $2.5 million USD pay increase[1]. Next year the CEO got another pay increase of $1.3 million USD[2].
They sure sound like a very nice Foundation to answer to - not very bothered by laying people off to give the CEO a pay increase or by losing market share for 10 years straight. Again, how are they different from other companies?
> Marketing realism wins over technical excellence every single time
It is so annoying to see this idiotic mantra being repeated every single time a thread like this pops up. It's simply not true. There is no conspiracy, people aren't being manipulated by Big Tech to like Chromium-based browsers more. Those browsers are simply better and that's it. That's really all there is to it.
It's so annoying whenever you say chrome wins because it's preinstalled someone makes a stupid comment about how it's not a big tech conspiracy. Did I say it was a big tech conspiracy?
I mean sure, but there's a bit of a difference between "sells data to no one really knows who" and "sells data to no one really knows who AND PALANTIR" which the original commenter seem to be flagging as a problem.
From what I know personally, Firefox truly is responsible with user data. Though -- to steel man your point -- all the data Firefox sells is through their subsidiary Anonym, which goes through great lengths to anonymize all user data that can't be tied to any individual.
Example: selling market preferences of a town rather than the individual people in it.
Well Thiel investing in Brave once at the beginning doesn't necessarily mean that Palantir is getting any data now (even though it's presented as if it was a fact in other comments here). It's probable, but really it's just speculation, just like anyone can speculate about who's getting data from Firefox.
But at least with Brave, the initial funding information was made public, so there's already more information available to users in comparison with Mozilla. Mozilla just said: "there are a number of places where we collect and share some data with our partners" - that could mean literally anyone.
I mean, if the only things you can name are Liquid Glass, App Store and not-so-intelligent AI then it seems like Apple users are actually doing quite well?
It's impossible for every idea to be a hit. Liquid Glass was a miss and they backtracked on some changes and fixed some issues that people were vocal about.
I can name lots of things I can't stand about MacOS and iOS and Apple hardware, but that wasn't the point of the comment. Some of the things I can't stand about Apple are things that people used to Apple's stuff don't mind. Cool for you. But I'm still not moving to The Villages, ever.
> things that people used to Apple's stuff don't mind
... but that's what you said about Windows:
> Windows found itself in a downturn the last few years
> I live in Windows Town, it's not perfect, no city is
> [...] avoid the "neighborhoods" that suck
Really the original comment just reads like you wanted to rant about Apple users and MacOS and that's it. You didn't really give any strong arguments for why Windows is better than MacOS - and "it's not perfect" is not an argument when in the same post you say the exact same about your preferred OS.
Linux as an operating system is easily better than macOS. Third party software is lacking though. There’s really nothing that compares to Bear, Things, DEVONthink, Transmit, etc. What I also missed in Linux was the prevalence of what Apple calls “x-callback URLs” [0]. They are incredibly useful and great for glueing different pieces of software together.
With some of Apple’s recent decisions, I do wonder if we’ll see this change in the future. Little Snitch put out a proof of concept for Linux. While it exposes itself as a fairly rough webpage, someone is thinking about it. Linux culture would need to accept paid software, though.
According to Wikipedia[1] the history of string formatting goes back to 1950s. Also, basically every major programming language these days implements it in some form.
The Liquid Glass effect `<canvas />` used for 1(!) tiny, barely visible button degrades the performance of the entire website.
Also, why is text selection disabled?
Also, please don't hijack the scroll to make it "smooth", I know it's not smooth on Macs by default, that's why lots of people use e.g. `Mos`, so now it's double smoothed.
Degrade the performance can only refer to the library load time which is 130 KB, a trade off I'm happy with to bring the feel of the product inline with modern Mac aesthetics.
Text selection disabled is a bug, thanks for letting me know.
A lot of mac users have a trackpad which is way too snappy by default for a product like this.
This has got to be one of the most stupid comments I've read this week. This is a page with random lazy-loaded images splattered all around, the load and render time difference if this used React would be not more than 10 milliseconds.
On the other hand, since the typical (!) React site has no fallbacks whatsoever for noscript, even though a specific HTML tag exists for this very purpose, the React site stays a white page, one can wait an arbitrarily long time and it still won't work or change, and the browser tab gets closed.
I'll avoid getting into the whole discussion about people on slow connections, accessibility, etc., as I get the impression you really don't care about them, and just point out the obvious fact that everyone has JavaScript disabled whilst your JavaScript is downloading.
You'll avoid it, because you don't have any valid arguments.
Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be cached as easily, so every page will re-transfer the exact same HTML for shared things like navigation bars, footers, etc.!
Accessibility isn't any issue either, this is a ridiculous argument to even try to make, accessibility tools use HTML and are fully aware of the existence of JavaScript - React doesn't magically bypass HTML to display something on the page.
> everyone has JavaScript disabled whilst your JavaScript is downloading
Everyone has HTML disabled whilst your HTML is downloading.
Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy, instead of standard HTML form elements, and in the process makeing a complete mess of the DOM, so accessibility is also out there.
The number of things this paradigm breaks, only to then have to fix them again, but this time by implementing them in JS partially correctly is just too high, for the average web dev to manage on the short time budget they get assigned in their day to day scrum managed job, where new feature requests and KPIs are more important than actual usability of their pages, and few people even properly test on multiple browsers, let alone screen readers and the noscript situation. It is just too tempting for them to use some component "someone else already made" "do not reinvent the wheel" etc., while constantly being discouraged to spend more time on making things actually work well.
> Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements.
That doesn't really deal with the consequences we experience at all. The mess is still created and 5-10 additional layers of nodes deep. The idea of making general use components, that "everyone can use in any situation" inside a JS framework, necessarily leads to this. The general purpose components handle cases, that one doesn't even have in one's scenario. Also they are usually dependent on JS, even when it is unnecessary.
We wouldn't have all those shitty JS only pages, that still only show us content, that we could just as well have seen without running any JS at all. Tons and tons of such websites.
This may also partially be due to people in bootcamps learning one trick, a JS framework, and then being let loose on the world of web development, while the basics are still lacking. I have seen people being well paid frontend devs working with NextJS, but then "learning HTML5". So guess what they will build using React. You personally might do the right thing, and in general we have seen somewhat of a push back to server side rendering, which people new to the show think of as a new greatest thing since sliced bread, but still we face an avalanche of badly made web apps, that could just as well be static pages, simply based on modern standard HTML and a touch of modern CSS. In many cases they would serve us better, because they would not break browser functionality, and everything would have a URL, that we can bookmark.
> HTML is also something "someone else already made".
True! But at least it was made by people with vastly more expertise than the average web dev. HTML elements have semantic ideas, and they are very composable and clean. They also already cover almost every use-case one can think of, especially, when composing them into compound structures.
I wouldn't say it is impossible to make good web components, that then render out as clean HTML elements, only doing the bare minimum of what is needed, without breaking anything, but so far I have not seen many sites succeeding at this.
Does this look like it was written by a person who has "vastly more expertise"? This was made by the Chair of HTML Working Group and President of ECMA. It's an awful, unreadable mess. How is that person supposed to lead and shape the future of the Web?
The myth that people at W3C and ECMA are somehow god-tier engineers and designers is just not true at all and it's been proven many, many times. They are completely disconnected from reality and don't build modern apps at all, how are they supposed to know how to do it well? It's why we have TypeScript, why SASS/SCSS was popular, why we need component libraries to add basic fucking features to HTML or why half of browser APIs are abstracted away into JavaScript libraries by people who got frustrated one too many times.
> already cover almost every use-case one can think of
They literally don't, if they did we wouldn't have to build extra stuff on top - no one wants to do all this abstraction work, but there isn't any other way.
If you wanted to build a stupid autocomplete dropdown in native HTML, you literally just can't. You HAVE to use JavaScript. This is a pattern used on MANY websites today, understood and liked by users and it's still impossible to implement natively.
Also competing business interests from Apple, Google and Mozilla make it so even if something IS a standard, it's not actually implemented the same way in all browsers or is not implemented at all.
But have you considered the absolute existential horror of a user clicking a link and a whole new page loads (modulo cached elements) rather than an entirely client side routing? Such a horrific concept of JavaScript as an enhancement would let all varieties of user agents from text message previews to web crawlers to AI agents handle the page without running an entire JavaScript engine and JavaScript resources from all your friendly data collection services.
The thought frankly horrifies me. I hate an accessible and efficient web!
Streaming HTML and Transfer-Encoding: chunked have existed since 1999 at least. I don't actually care about this argument one way or the other, but you can continue updating the site with HTML/CSS indefinitely, zero js required, simply by never completing page load.
I think the complaint is mainly about the failure mode. I guess it would be trivial to use the noscript tag to display a message saying JavaScript is required, instead of showing a blank page that keeps loading.
Toxic positivity is what's abusive and ignorant.
reply