null
...
run a live distro (or Pi 5)
The Official Linux Thread
- Thread starter Responsible Allen Iverson
- Start date
run a live distro (or Pi 5)
dev's can code faster and develop more apps, it'll just get easier to get cross-platform support when existing app code can be refactored into another programming language and window manager.
if it becomes easier for devs to support apps on linux even though the share of users is smaller than than can attract more users to the platform. windows phone failed because for a few reasons but mostly because users couldn't find the apps they wanted to use.
i'm also betting the open source nature of the linux desktop will offer tighter integration with LLM/A.I solutions than OSX or windows and that'll help attrract more users as well.
null
...
coked out anti unix twaddle.
unix principle = commands do one simple thing and do that simple thing well.
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features""
Unix philosophy - Wikipedia
pollute unix with window-isms brehs.
null
...
who says that any speed-up will be significant enough to make this viable?
"can be" - by AI you mean?
wouldn't refactoring the WM api make more sense?
infinite context length window, increasing token output per seconds, improved coding ability with each new release means this is the obvious and inevitable conclusion.
yes "can be" because the transformers models are built to translate data. for example take a script in one language and ask an LLM to convert it to another language.
refactoring could also lead to making it perform better depending on the hardware, OS and window manager.
null
...
infinite or unbounded.
how do you manage "infinite" factors?
do you know what the halting problem says?
xXMASHERXx
Superstar
People don't really care about that. They care about ease of use, familiarity, and convenience.because of privacy (windows concerns) and apple walled-garden pressure.
if you're on IPT, they regularly update the zorin torrent if you dont want to pay. idk who pays for linux anyway outside of RHEL weirdoes
i hear this all the time but i use a combination of proprietary and open source software on my hackintosh. macports+homebrew (set your $PATHs correctly lol) is wonderful. i never use that lame ass app storebecause of privacy (windows concerns) and apple walled-garden pressure.
homebrew gave new life to my imac g4. i put macports and tigerbrew on it and i can sort of use tls/ssl again! (sort of)
null
...
nah.
2025 is one of the major pressing iT issues.
that is why (for example) apple has been using privacy as a selling point.
the issue is that most people can't quantify or readily fix privacy problems. learning and/or relying on linux is a risk factor.
iOS 15 Privacy Protection Highlighted in Apple's Latest Video for European Audiences
Apple has shared a new video in which Tim Cook highlights the company's commitment to privacy features in iOS 15 and iPadOS 15.
wccftech.com
null
...
fair enough.
a problem with dev on macs is compatibility.
older programs (esp. free ones) and tightly bound to OS/hardware code are being swept out of usability.
this allows modern charging models to assert (subscription) and rules out certain builds on modern macs.
i used to use a free util called wake on LAN. i copied that thing from laptop to laptop but no longer.
now you have 1 password forcing people to their paid model on M machines.
complex c++ software like asterisk does not build.
emulation might be acceptable now with M4's but my mac is not that new
i suppose the same way it does now and chooses what to output like each generation from the same prompt can lead to a different output.
i'm not sure how the halting problem relates to the quoted comment.
null
...
that choice is randomised (on tie).
no magic and no secret sauce.
it is a direct implication.
null
...
I guess well find either way
no need to guess. ask chatGPT
you need to read it tho. might help with the spamming
TL;DR computers cannot understand code.
Why does the Halting Problem apply to computer programming, and how do we know it is true?
The Halting Problem applies to computer programming because it proves that there are limits to what we can predict about a program’s behavior using other programs or algorithms. The Halting Problem asks: “Is there a general algorithm that can determine, for any given program and input, whether the program will eventually halt (finish running) or loop forever?” This question is deeply relevant to computer programming because programmers often want to know whether a piece of code will terminate or not—especially when trying to catch bugs or ensure a program is reliable.
We know the Halting Problem is true—and unsolvable in the general case—because Alan Turing mathematically proved it in 1936. His proof showed that if such a universal halting algorithm existed, it would lead to a logical contradiction. He used a clever self-referential argument: he imagined a program that takes another program as input and does the opposite of what the halting algorithm says it would do—leading to a paradox. This means such a halting-checking program cannot exist.
Why this matters in programming:
- It proves that no tool can perfectly analyze every possible program to say whether it halts or not.
- It explains why automated program verification is inherently limited.
- It shows that some bugs (like infinite loops) might never be detected by analysis tools, no matter how smart they are.
So, the reason the Halting Problem applies to computer programming—and why we know it’s true—is because it’s a proven mathematical limitation on what computers can analyze about themselves and other programs.
-
What does the halting problem have to do with LLM code conversion from language to language?
The halting problem, a foundational concept in computability theory, plays an important role in understanding the limits of what Large Language Models (LLMs) can do when converting code from one programming language to another. While LLMs can appear to translate code successfully — for example, turning Python into C++ — they are fundamentally limited by the fact that no algorithm can decide, in all cases, whether a program will halt (finish running) or run forever. This limitation directly applies to code translation tasks in subtle but significant ways.
Here's why:
- Preserving Behavior Requires Solving the Halting Problem (Which Is Impossible)
When converting code from language A to language B, ensuring that the new version behaves exactly the same includes ensuring it halts in the same situations. But due to the halting problem, there's no general way to determine whether arbitrary programs halt, let alone whether two translated versions halt in the same way. So LLMs can't guarantee behavior-preserving translations, especially for complex or unusual code. - No Guarantee of Semantic Equivalence
Two programs written in different languages may look similar but behave differently if one halts and the other doesn’t. Since proving full semantic equivalence is undecidable in the general case (again, because of the halting problem), LLMs can only guess based on patterns learned from data — they don’t know whether the code is truly equivalent. - Translation Quality Depends on Decidable Subsets
LLMs work well on common, well-behaved code where halting and correctness aren’t in question. But for anything nontrivial — recursive functions, dynamic input-driven loops, edge cases — they may silently introduce bugs or misbehavior during translation because they can’t reason about halting or correctness in a provable way.
TL;DR:
The halting problem has everything to do with LLM code conversion from language to language because it defines a hard limit on what can be known or proven about program behavior. Since LLMs cannot determine whether a piece of code will halt — and therefore whether its translated version behaves identically — they are fundamentally constrained in their ability to perform correct, reliable, and safe code translation at scale.
-
Why would LLMs find threaded programs harder to reason about?
LLMs (large language models) find threaded programs harder to reason about because concurrency introduces complexity that’s not always explicitly written in the code. Threaded programs can behave differently depending on timing, race conditions, synchronization, and shared state—things that aren’t always obvious just by looking at the code.
Here’s why this is hard for LLMs:
- Non-determinism: In threaded programs, the same code can behave differently each time it runs because thread scheduling isn’t fixed. LLMs are trained on static patterns of code, so this unpredictability makes it harder to reason accurately.
- Hidden dependencies: Threads often share variables or resources. If one thread modifies a value while another reads it, the outcome depends on the exact timing—something LLMs can’t see from the code alone.
- Synchronization complexity: Constructs like locks, semaphores, and barriers add layers of logic that are subtle and easy to misuse. Understanding when and where locks are acquired or released requires precise tracking, which is challenging for models trained on language rather than executing code.
- Sparse training data: Threaded code is less common and more specialized in general programming datasets. That means LLMs may not have as much exposure to good examples or debugging patterns involving threads.
So, LLMs struggle with threaded programs because the logic isn't always in the text—it’s in the invisible interplay between instructions over time.
linux has the same issues. i expect all hell to break loose once those morons decide to drop gtk2
i remember my fltk apps not launching under wayland for years. ive had enough of linux, it only runs on my raspi