What do you mean far behind? Far behind what? The new (actually the old one too) Qwen can give you bounding rectangular prisms around things in a scene, OCR text with ink spilled on it correctly, read graphs and understand spatial relationships, I think it's pretty impressive for something I'm running on like a 5 year old GPU.
yeah i know lol, that’s kind of my point. impressive that it runs on your gpu, but it still can’t tell you what happens if you tilt a glass. that’s what world models are working toward. but even then..so what? you get a perfect simulator. it knows the glass tips. it still doesn’t know why someone tipped it, or what happens if they don’t. A four year old can do this and we’re just barely on step one and a half.
> Please don't comment on whether someone read an article. "Did you even read the article?
I get that it's frustrating - that's what open source allows though. I used to run a blog. I ran a few websites, open sourced, that were similar in a general way (users can make stuff on the site and share it others). I found the site duplicated. In fact it's still duplicated to this day. Oh well.
It being an "acquired taste" is part of the appeal. A lot of high-end stuff is ass-ugly on purpose. If everyone liked it because it simply looked nice, you couldn't tell who's "in the club" of other rich people. Brands will attach elaborate stories and histories to objects to make people feel cultured that they have invested time in acquiring the knowledge, but really it comes down to in-group object recognition.
My least favorite of that eras Gerald Genta designs. The original Royal Oak is comparatively far more attractive. Both are outdone by the 222 (different designer though), but it's all subjective.
Ads for Patek Philippe on the back of The Economist get more and more annoying over time. (e.g. the president writes "How Happy I am to be a Nepo Baby")
These things are shibboleths. It doesn't really matter what they look like or whether they are actually any good for their ostensible purpose so long as they signal that you are a member of the correct group.
NTA but almost certainly, the advantage is that Qwen3.5 is extremely generic already so adapting it to a specific task is way easier than training a NN from scratch. It's probably akin to how OCR is now just something I use Qwen for even though I have access to dedicated OCR tools, Qwen is good enough and it's already in my vram. Modern VLLMs are pretty great at answering basic questions about an image by default and I'm guessing finetuning takes them from "pretty good" to "good enough to use in production".
OCR as a use case for LLMs cracks me up because traditional NN OCR is probably more accurate, but significantly more efficient. I figured people would chain it with LLMs to fix misscans.
This, I was really impressed recently when I met a C# dev who was also a programmer (as opposed to your standard C# SaaS dev who just copy pasted from the framework docs and stack overflow and was fully automated by Claude in 2025) and he showed me how nice the language has gotten since I last used it over a decade ago when it was just Microslop Java. They've really put in work and it has a lot of great functional constructs now.
Cube 2: Sauerbraten too! Definitely spent some evenings playing that with my roomies back in the day before we invariably went back to Q3. What an insane resume.
I have fond memories of porting Cube, Sauerbraten and AssaultCube to the Mac back in the day. Given what i've seen from Wouter back in the day i am not surprised he is still on it full steam…
Unfortunately from what I read a couple of times, including a month or so ago, GrapheneOS discourages and doesn't support rooting the phone for security reasons that seem vague to me and don't appeal to my need to actually own my phone and OS. You could still root it with some third party tools from what I know, but not having root as the default makes it less of a secure FOSS OS and more of a closed down toy.
As for payment apps and other crap that refuses to run if I, the owner and administrator of my own device, don't have admin access, I would just refuse to run it. What's next - websites refusing to work if I have root on my Linux desktop?
LineageOS also discourages and doesn't support replacing the core of the OS with a rootkit providing persistent app accessible root. GrapheneOS is no different from LineageOS in that regard. People do this with GrapheneOS regardless of our strong recommendation not do it. Our reasons for discouraging it aren't vague. It very directly harms the security model and is not a good approach to implementing any of the features hacked together through it. Those features should be properly implemented to fit within the overall approach taken by GrapheneOS. Giving root access to a huge portion of the OS harms security even if you never use the feature. It does not mean you can't do it, we only recommend you don't.
I agree that the features should ideally be provided by the base system so that the user does not have to "hack them in" with root-powered apps. But the reality is that most Android "distros" simply do not support the features that I would consider basic functionality. I mainly root for three reasons:
- Backing up all app data via Neo Backup. Android has an auto-backup feature that backs up app data to the user's Google Drive, but unfortunately the app developer can simply opt out of this, and the user cannot do anything about it. This means that app data may be lost when migrating to a new phone, as the app data is stored in directories that are not accessible in the filesystem without root.
- High-quality call recording via Call Recorder. For some reason, some (most?) phones do not allow apps to access the raw incoming audio stream. Non-root apps have to rely on capturing the other end through the microphone, which is horrible.
- /etc/hosts-based ad blocking while using a VPN via AdAway. DNS-based ad blocking is possible via apps like AdGuard, which use a local VPN to accomplish this. Unfortunately, Android only allows one VPN connection at a time, which means that without root I would not be able to use a VPN for any other purpose while simultaneously blocking ads.
---
I have no experience with GrapheneOS, so I'd be interested to hear if these features are possible on it without rooting. If not, can I request these features somewhere?
Rooting is a very bad idea. https://madaidans-insecurities.github.io/android.html#rootin... But GrapheneOS is fully open source and provides great build instructions, so you can always make your own build and add whatever features or privileged apps you like within the standard AOSP frameworks for privileged apps with system integration.
> DNS-based ad blocking is possible via apps like AdGuard
DNS-based blocking can also be accomplished by using Android's native Private DNS feature with a resolver that blocks ads. You could even host your own on a VPS if you are more comfortable running name resolution and DNS-level adblocking on infrastructure you control.
Thank you so much for replying! Seems promising, I will take a closer look. I'm definitely looking forward to possibly buying a Graphene-powered Motorola phone in the future.
Rooting is only a bad idea if there is an alternative. Unfortunately I have to root my devices because there isn't an alternative method to provide me, the physical owner of the device with control over the device. I would much prefer not to generally have root on my phone but to be able to access root externally or via a hardware switch or some other scheme. ADB root is fine.
The alternative to "running as root" isn't "not having access to root".
>Rooting is only a bad idea if there is an alternative.
An alternative to accomplish what?
>to provide me, the physical owner of the device with control over the device
Control over what properties or behaviours of the device, exactly?
No offense, but these complaints feel more like aesthetic ("I want to log into a user named root") than practical ("I want to be able to do things that could only be done under root")
You're missing the point completely, of course there are more secure ways to do a lot of things, the problem is that if there isn't an alternative "secure" mechanism to accomplish what I want if I have root I can just get it done whatever way works for me. I do not want to run into a situation like I did prior to having root, where my voice memos unbeknownst to me end up in some sort of elevated privileged enclave and I can't copy them over to my computer.
There's a myriad of reasons to have root, like baseline I want to be able to watch my network traffic. I want to be able to spoof my location, I want to be able to sftp into my phone and mount it as a drive because it's convenient. I want to access sensors and log them in the background. I wanna just run normal linux daemons.
I don't need any of these reasons though, all I need is the desire to be the ultimate arbiter of what happens on my devices. I don't need to or want to control all aspects of what goes on my device, I'm fine giving up control, I'm not fine with it being taken away from me. Everything else is secondary, the person with final say on what happens on my device should be me.
I'm trying to understand why rooting Android is such a sin.
If I give root to my terminal so I can browse and edit any files I want, I'm placing a lot of trust in the terminal, sure. But trusting the terminal seems reasonable, as it's an important (basic; fundamental; necessary) part of any "real" OS. If I don't trust the terminal to not be malicious, why should I trust my OS? Anything could be compromised from a supply-chain attack. If we don't trust anything, we can turn off the computer and have perfect security, but if we accept that there's a trade-off between security and usability, we have to place some trust in some parts of the system.
> It does not matter if you have to whitelist apps that have root — an attacker can fake user input by, for example, clickjacking, or they can exploit vulnerabilities in apps that you have granted root to. Rooting turns huge portions of the operating system into root attack surface; vulnerabilities in the UI layer — such as in the display server, among other things — can now be abused to gain complete root access.
So if some app can somehow exploit the display server, it can inject commands on the terminal and hide the real output? I know the X server on Linux has (or has had) major security issues [1] that don't provide any real GUI isolation. Is that the type of issues Madaidan is talking about?
I don't know much about Android's display server, but if it's possible for an app without root access to exploit it, couldn't that app inject touch events or keystrokes in another app, or read the other app's screen? How would not having root benefit me if a random can view or control other apps without my knowledge by exploiting the display server? [2]
From what I gather if an app with root access has vulnerabilities, it makes it easier for another app (or other type of malicious code) to use it to gain root. But if the UI layer, to use Madaidan's example, has a vulnerability, it seems like it could be exploited successfully, with awful consequences, even if the malicious code doesn't get root in the end. So if I choose several apps to give root access to, I would just extend the attack surface from {all of the OS and its various layers} to {all of the OS and its various layers and those several apps}.
> root fundamentally breaks verified boot and other security features by placing excessive trust in persistent state.
I don't understand this. Could someone explain it with more details to me, please?
Of course the topic as a whole is much more complex than that, but I'll try to summarize it. Android has 3 systems of access control [1][2]:
- Discretionary Access Control, i.e. the standard Unix file permissions
- Mandatory Access Control, implemented in the form of the SELinux and YAMA LSMs (GrapheneOS stopped using YAMA in the 2024031400 release and replaced it with advanced SELinux policies)
- Android permissions which have to be disclosed in the AndroidManifest.xml, and most of the time need to be granted by the user at runtime
Root simply bypasses ALL of these security mechanisms. This is a clear violation of the principle of least privilege, since most of the stuff you are doing with root probably doesn't require access to your entire filesystem, and could easily run within an SELinux context. But writing and deploying a modified SELinux policy would take extra time and effort, and devs are lazy, so they just use root to completely bypass it.
As madaidan points out, only a tiny subset of system processes on Android run as root. [3] And Android has clear guidelines about what root process are and aren't allowed to do. From the AOSP documentation:
> Where possible, root code should be isolated from untrusted data and accessed via IPC.
> Root processes must not listen on a network socket.
> Root processes must not provide a general-purpose runtime for apps (for example, a Java VM).
Desktop systems are very different from Android and iOS. Out of Android's three major security mechanisms, they typically only implement one. This is why ransomware is so insanely successful. Every program has access to all the files and folders of the logged in user, including network shares, etc. Even on systems that implement application sandboxing and a permission system, such as macOS, it's only an afterthought, and isn't enforced properly. (macOS is still miles ahead of Windows and Linux though) For example, when installing a 3rd-party terminal emulator such as iTerm2 on macOS, you have to grant it the permission to access your entire file system (otherwise you will be limited to the home directory IIRC). But this permission also applies recursively to every process started within the terminal, greatly limiting its usefulness.
> I don't understand this. Could someone explain it with more details to me, please?
Android uses Verified Boot to protect against both Evil maid attacks [4], i.e. someone modifying the operating system on the hard drive, and malware persistence. By default, the Android /system partition is mounted in read-only mode, unlike for example your C:\Windows directory, or system directories like /bin on Linux. This prevents malware from modifying the operating system. If you ever get malware on Android or iOS, in most cases you can get rid of it, by simply rebooting your device. Unless of course, the malware has some persistence mechanism. Root obviously provides a great vector for persistence, since the system partition could simply be remounted in a writable mode, and the system could be modified however the attacker wants to.
When you build your own copy of AOSP or GrapheneOS, include your modifications, and sign the image with your own Verified Boot keys, that image can't be modified or tampered with by an attacker. It's perfectly secure to do that (of course only if you can trust the extra code you're including).
I'll read the links you posted a bit later, but for now I have a few questions that could help me clear some misconceptions I might have. I haven't used a rooted Android device yet, so I might be wrong about how it works. I've read about magisk and other methods a bit and am at familiar with the security concepts you wrote.
Let's say I give root permissions to a terminal app TermGood and I don't give root permissions to an app GameEvil. I trust TermGood fully - I accept that if TermGood is malicious or if it has some exploitable bugs, it's game over. I don't trust GameEvil at all, but I trust the OS to limit the damage it could do since it doesn't have root permissions.
1. Could I run TermGood with root only sometimes? Run it with root, close it, then run it with the normal restricted permissions. That's just to clarify how rooting works in general.
2. For MacOS you wrote "this permission also applies recursively to every process started within the terminal, greatly limiting its usefulness.". For Android, if I run a program like ls or vi from TermGood, will it be launched with root permissions, too? Will I have fully trust that ls or vi are not malicious or exploitable in certain ways (e.g., running vi on a file created by GameEvil that exploits vi).
3. Will GameEvil have any way to compromise the OS, to circumvent some security boundaries or to do any other damage it wouldn't have been able to do if I hadn't "rooted" the OS?
3.1. Would GameEvil be able to launch TermGood on its own without my knowledge? Or somehow piggyback on TermGood to take advantage of its root permissions?
3.2. If there's a bug in the UI layer (the "display server" - what Madaidan gave as an example) and I had TermGood open as root, GameEvil could inject some keystrokes into TermGood to read its screen (like the output of a cat command, for example).
3.3. Just because TermGood could have root access, does that somehow make GameEvil more likely to gain root access itself? On Linux, if there is sudo installed, it might increase the attack surface because sudo might have exploitable bugs. What could GameEvil exploit?
4. If I don't root my OS by any of the available means, what would my alternatives be for full control and customization?
4.1. AFAIK with adb you don't get rw access on / if the OS is not rooted.
4.2. Let's say I want to X (e.g., backup / to a server when it commands it to) without rooting. Would I have to create the app, then modify security policies in a way that would enable it to run without root, but with granular permissions for X specifically and nothing else, like permissions to read / and to listen on a network socket, maybe by changing the SELinux policies and/or the Android permissions of the app? Or would that be impossible? I don't really have a specific X in mind, but I want X to be as broad as possible. That's what makes it a real OS for me - being able to do anything on it.
5. If TermGood is compromised, it could reinfect the root filesystem after booting and effectively bypass Verified Boot. Or, if I used TermGood to change something on /, e.g. `touch /testfile`, would I be able to sign the new root filesystem? Ideally I should be able to control all the keys and sign the whole chain of trust whenever I make a change.
6. Android doesn't have FDE, so evil maid seems relatively easy (although any unrestricted physical access to the device should be treated extremely seriously, even with FDE in place). Is that correct?
Basically, if we assume that:
* I fully trust TermGood and the processes it spawns to not be malicious or have exploitable bugs;
* I could resign any changes I've made so I can keep Verified Boot working.
Then, would I be able to give TermGood root and keep my security?
>but not having root as the default makes it less of a secure FOSS OS and more of a closed down toy.
I don't get it, it's "less of a secure FOSS OS" to not have root by default, but it's secure to run random apps as root and breaking android's security model? What's the threat model here?
Yeah, this is the deal breaker for me as well. The fact that I own my device is non-negotiable. It is the reason I left the stock OS and I'm not going back. The idea that I can't access my own files if an app doesn't explicitly give me access is wild to me. I understand there are security risks of a root permission but it is important to have that fallback when you need it and the existing permissions aren't sufficient.
The "access your own files" thing is so insane! Hard to describe my feelings [negative] when I found out that all of my voice notes were in the voice recorder and the easiest way to get them out was to manually send each one to myself over discord. Google helpfully mentions that you can just "download them through google takeout" and doesn't leave any option for people who don't just give all their personal data to google.
I use a FOSS voice recorder app from F-Droid. It's just called "Voice Recorder" with an orange icon. It does exactly what it says, records audio from your microphone, lets you play them back. They're just files on the device.
Anytime I need a "simple" utility, I check f-droid first to get the one-trick-pony app over spyware from the play store.
Other utilities I use are:
WorkTimer: pomodoro app
DiskUsage: self explanatory
Http Request Shortcuts: setup home screen app shortcuts that run http requests
LineageOS also discourages and doesn't support replacing the core of the OS with a rootkit providing persistent app accessible root. GrapheneOS is no different from LineageOS in that regard. People do this with GrapheneOS regardless of our strong recommendation not do it. Our reasons for discouraging it aren't vague. It very directly harms the security model and is not a good approach to implementing any of the features hacked together through it. Those features should be properly implemented to fit within the overall approach taken by GrapheneOS. Giving root access to a huge portion of the OS harms security even if you never use the feature. It does not mean you can't do it, we only recommend you don't.
LineageOS provides ADB root access in stock builds. Sure, it isn't as convenient as some su apps but at least I can use ADB to access every file on the device. It probably also improves the attack surface compared to a su app.
> It very directly harms the security model
What do you mean by this? You mean that it is a "god permission" that bypasses other permissions? If so then yes, with great power comes great responsibility and it shouldn't be used lightly.
> and is not a good approach to implementing any of the features hacked together through it.
Maybe not, but is there an alternative? What is your recommended way to access all files of any app? This is my primary use case. Modification would also be valuable but I would be ok with read-only access.
> Giving root access to a huge portion of the OS harms security even if you never use the feature.
Can you explain why root access must be given to a huge portion of the OS? Why can't it be limited to specific apps or features (like ADB shell)?
> It does not mean you can't do it, we only recommend you don't.
Of course. It is your right to recommend whatever you want :)
> [I want root,] The fact that I own my device is non-negotiable.
I read that a lot, and I agree that I want to own my device. But that does not mean that I should have root access on the OS I choose to install on it.
Owning my device means that I should be able to install whatever OS I want. It does not mean at all that OS developers must do whatever I tell you to do.
Yes, that is why it is a deal breaker. I'll choose to run a different OS. I didn't say that GrapheneOS must support root. Just that I won't run it if they don't.
And I'm fine with you wanting root on the device you own. But you were implying that not having root means that you don't own your device. I disagree with that. You can totally own your device and not be root.
I think it is important, because I read a lot of comments that imply that "owning their device" means "owning the developers". And that's a wrong fight.
The real fight is that it should be illegal to prevent me from installing my preferred OS on a general-purpose computer.
Fair enough. Owning means having a choice. The unlockable bootloader enables that. But for me the choice of OS will be one that lets me access all files on the device should I need to.
What should that support look like? Maybe have a userdebug build already built and available? I don't include a root account on hardened container images for some of the same reasons they cite. So including it for everyone and creating a way to activate it is suboptimal for people who don't want that trade off. A parallel build pipeline seems the most reasonable to me?
Yeah, I would be fine with a different build stream. I do think it could be sufficiently secure in a single stream but it will always be increased attack surface so the safest option is to do separate builds.
I also don't include a root account in my container images, but you probably have a root account on the sever that runs them in case you need to debug something. But you can probably also build and deploy a new container. At the end of the day you almost always want some last-resort way to access the data stored in case something goes very wrong. Whether that is for backups, "hostile" data export or for other reasons it is important to me.
I don't actually. Devs don't get root at my employer. Even on a vm. I have rootless podman, and can be root in a container. Even our gitlab instances don't have any privileged runners. So kaneko etc.
There's nothing GrapheneOS-specific about it and it doesn't prevent rooting. LineageOS doesn't officially support it any more than GrapheneOS does. It doesn't stop people doing it for either. Our recommendations aren't law.
Any files created by apps in their main data directories are inaccessible on most distributions of Android (I think it is actually required to be Google certified). The exception is apps that go out of their way to store files in user accessible directories or provide a feature to export or share data out of the app.
By rooting your device you can access the app data directories as you wish.
As far as I know, root and tap to pay are pretty much mutually exclusive, at least if you meant Google Pay? Unlocked and rooted devices do not pass remote attestation. And it's not just something you can fake when you have root, since it is anchored in hardware (the attestation certificate chain is signed by a hardware-backed key and contains the verified boot state and verified boot key).
I can tap to pay with google pay on my rooted pixel while the spoof key isn't blacklisted, IIRC it uses dumped credentials extracted from other devices but I can reliably spoof Play Integrity and SafetyNet. It would be nice to not have an adversarial relationship with my things for once.
"While the spoof key isn't blacklisted" is the critical bit. Soon, all the keys will be, as these old devices age away from being too common to blacklist.
GrapheneOS doesn't give you root access, citing security issues it introduces.
You could re-compile your own copy with root access, though not sure if we'll then be back to some non-certified OS that can't make payments...
Yikes. Nevermind. The whole phone security model is one of the worst things to happen to computing, the concept that you shouldn't own your device for safety is so fucked.
> the concept that you shouldn't own your device for safety is so fucked.
That's not it. The concept is "if you choose to install this particular OS on the device you own, then it comes with this particular security model". That's totally fine. If you own your device, you can run Linux on it and you'll have root access.
"Not owning your device" means "not being able to install the OS you want on it". I want to own my device, obviously. But it does not mean that I own the developers of every OS in the world and that they should do whatever I tell them to do, for free.
I mean sure but I should be able to have DMA on some level, like I should be able to rootkit whatever software on my device, because it's on my device.
A non rooted device is NOT really my device, just seems like a leased device.
If we want to use banking app we have to use a non-rooted/leased device. That is what is really messed up. Personally I only use bank now that has website for banking. If they don't have a web site only app, then it is a red alert for the company.
Android is not UNIX, and that's a good thing. The root account was a historical mistake and not having access to it doesn't mean you don't own your device. That mindset is just trying to project how things worked with a half century old operating system with how modern operating systems work.
What a disgusting take. It's actually so depressing to see anyone say this, presumably sincerely. It's how all the modern operating systems I use work.
It's what makes computers so wonderful and powerful, you can just have it do whatever you want. Turning that into "whatever google decides i should be allowed to do" is not gonna lead us to a bright future.
With Turing completeness you can do whatever computation you want. If you want to go outside of Turing completeness and starting interacting with the real world or other apps that is when security models need to exist. There isn't a reason to allow a program to act however it wants. Why should we allow for programs to secretly spy on a user's mic with no visual indication. It's okay to bound what is possible with a device. This already happens in practice with other operating systems. Redhat can still be useful even if you don't have permission to write new CPU instructions (only Intel and Amd have they signing keys to add new instructions). Sure Intel may be limiting what you can do, but it still is a useful machine without it that many people successfully use and gain value from every day. Even as a smaller example root on Linux has limits on how it can interact with the kernel. It may be root, but there are still limits on what it can do without loading a kernel module to modify things. If you want a less secure operating system where things are less secure like allowing the user to be spied on you can make your own, but the average person wants to have a secure device.
Yeah and security models are fine. Having root on my device isn't the same as running everything as root. e.x. I want to access my files on my device over SSH so i don't have to keep plugging my phone in, sadly turing completeness doesn't get me there when I can't give my SSH daemon access to the filesystem. These are all solved problems, we're just CHOOSING not to expose the solutions to the end user under the guise of security in order to retain control.
Making it so that you can't overly share data with apps is not an issue with root not being available. That is an issue with the capabilities the os exposes to you.
The answer to every security issue not "add a backdoor".
> That is an issue with the capabilities the os exposes to you. The answer to every security issue not "add a backdoor".
Problem is, I strongly suspect we'd still be having the same discussion even if we were talking about "allow the user direct access to all files*" instead of "allow the user full root rights".
Because while some of those missing capabilities are "simply" a matter of it being too much effort to provide a dedicated capability for each and every niche use case (though that once again raises the question as to whether you prefer failing open, i.e. provide root as an ultimate fallback solution, or fail closed), with file access I guess that this was very much an intentional design decision.
What do you mean it's not an issue with root not being available. Root solves the problem, that's the whole point, when the OS doesn't expose the capability I want I can just read the file or piece of memory. The reason for root is that I want to have the failure mode be "ugh i have to go deal with the root security i've elected to have to do XXXX" rather than "well i guess i'm sol"
I think is great, if there are no ramifications when skilled people unlock it.
There's just too much hacking going on, malicious behaviour, to allow uneducated masses to have root on a phone. I've seen so many people just not understanding the outcome of their actions. You'd get people rooting because some shady app lied about why, and just wanted control.
And we don't need more botnets. And it's why banks sometimes throw a fit.
So if a recompile does the trick, and no downside, then it'd be fine.
Lots of freedoms have downsides that are outweighed by the upsides, I'm absolutely unconvinced that the line lands on the far side of allowing you to control your phone.
Location: I'm from the BAY, I rep it hard.
Remote: Sure
Willing to relocate: No
Technologies: JS (both ends), C (mostly embedded, some high perf), Python/Torch (mostly model inference), 15YoE
Résumé/CV: On request.
Email: thot@thiic.cc
Looking for contracting/part time work specifically anywhere bootstrapped, not seeking outside investment, and working on a product that will be sold and not rented out. Open to fulltime for the right fit.
Why is this a meaningful distinction to you? What does "reason" mean here? Can we construct a test that cleanly splits what humans do from what LLMs do?
Ok, but if you read my comment you would note that I constructed a category of humans who can reason but cannot count the r's in strawberry.
I think you don't know what it means to reason, and are dismissively claiming AI cannot reason as though it invalidates a point made earlier without even having a sturdy definition in your head. I think for you to say "LLMs can't reason" in this context is essentially a NOP.
It is hard to define reasoning or thinking, these are vague concepts. I use them to indicate there are areas where these machines take obviously wrong decisions, because they are above all probability weighing machines based on a corpus, that is not I hope you would agree thinking, so you must believe there is some emergent properties which constitute thinking since you're so confident these machines are in fact doing that.
AI companies use these terms (thinking, reasoning etc) to try to trick users into anthropomorphising pattern matching machines and so that people believe they are true general intelligence.
I don't think we've reached AGI yet, though we are closer than previously, and I'm skeptical LLMs will be the route - they are impressive, but they are better at tricking humans than at performing complex tasks they have not seen before IME.
Do you think we have seen AGI yet from LLMs? If not how would you define their limitations?
I'm pointing out that they don't 'think' or 'reason' like humans, they're very impressive, but I don't think they've reached the bar for thinking yet, as simple logic puzzles or puzzles like this prove (until the LLM authors take note and add special workarounds for those particular use-cases).
I believe most LLMS no longer fail at this, because they've been given the tools to do so (for example use python under the hood to count letters), but it's an important observation because it shows us that they don't think like us.
reply