Rendered at 08:00:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jefurii 1 days ago [-]
Sure it's not a crime but I don't want your vibe-coded shit mingling with my actual code written by actual humans.
ganelonhb 1 days ago [-]
the question becomes, is it the end user’s decision to decide what packages they download/use or is it the repository/package manager’s responsibility to show end users which apps are allowed to be used or not.
I understand the objections to vibe coding, but for those of us who don’t care how a good tool was built (when it actually is good), this just forces us away from your favorite platform. Like it or not, this is the present and these AI tools are available. People will use them.
That said I think it’s utterly ridiculous that this article was written using AI.
sgarland 1 days ago [-]
So download the release from the tool’s Git{Hub,Lab} page.
ganelonhb 18 hours ago [-]
I mean, yeah. I don’t even use flatpak. I’m really arguing against flatpak on these grounds; that I don’t believe it to be the package manager’s job to police which packages I’m allowed to see on some arbitrary ideological grounds.
sgarland 7 hours ago [-]
Have you read maintainer guidelines for a major distro, like Debian's [0]? I would wager there is between 0 - 1% chance that a vibecoder would be willing or able to meet these.
> But the policy doesn't distinguish between someone who prompted an LLM to generate an entire app in five minutes and a developer who used Copilot for autocomplete while writing 90% of the code themselves.
How is using autocomplete "Vibecoding" now? I remember y'all that the "definition" for vibecoding requires the "prompter" to not look at a single line of code
vrighter 23 hours ago [-]
Autocomplete with an LSP is fine. That's always correct.
Autocomplete with an LLM, which generates snippets for you is just a lubricated version of "copy and paste back and forth between chat window and code window"
6yyyyyy 1 days ago [-]
BASED. I'm going to feel a lot better about getting software from Flathub from now on.
wildredkraut 1 days ago [-]
Well, there is still AppImage, this might be the right way to go with in this case.
grigio 1 days ago [-]
Flatpak has better software isolation and support
digitalPhonix 23 hours ago [-]
> The problem is structural
> The policy is asymmetric, and that's what makes it harmful.
Well I found the problem
already
sgarland 1 days ago [-]
> One shared that they were flagged for using Claude Code to submit the pull request, not to write the app.
Who is opening up an LLM to run git push?!
fragmede 1 days ago [-]
You don't open the LLM app specifically to run git push, you're already in the LLM app, using it to generate code, and having that app operate git as well.
graemep 1 days ago [-]
Further evidence that Flatpack does not solve the problem of distributing applications.
The same is true for existing Linux package managers. You could say apt = git, Debian repos = Github.
Its not entirely true either because neither git nor Github do things like dependency handling.
There are lots of alternatives to Github. Of the two alternatives to Flathub mentioned in the article, one has disappeared, and the other has all of 93 packages.
feverzsj 1 days ago [-]
Intentional littering is a criminal offence in most places.
krater23 1 days ago [-]
Why should Flathub accept vibecoded shit. You don't let just anyone who rings the doorbell into your house, either.
AuthAuth 1 days ago [-]
flatpak accepts half finished game demos without a patch in years
grigio 21 hours ago [-]
This is the biggest contraddiction of this times
Arodex 1 days ago [-]
"Vibecoding isn't a crime"
Meanwhile, a few ranks away on HN:
"Big AI to humanity: drop dead"
"The End Of Upward Mobility – AI is coming for the meritocracy"
epihelix 1 days ago [-]
One man's vibecoder is another bot's freedom fighter?
ChristmasTomer 22 hours ago [-]
[dead]
spacedcowboy 1 days ago [-]
This is good to know. ‘I’ built a compiler for a language I call ‘xc’, similar to Objective-C but designed to be cross-platform and have less square brackets :). It can run on any of {Windows, Mac, Linux, Zynq} and produce code for any of {Windows, Mac, Linux, Zynq, WASM, iOS, Android, m68k, 6502}.
It needs no host-platform tools to compile code, so for example I have a signed binary on my iPhone, written and signed entirely on Linux.
The compiler (v 0.61, not the released v0.6) currently produces code that is between 5x and 0.5x the speed of clang when measured at -O3 on both, against ObjC code, which is pretty good for a nascent compiler. The geometric mean of 19 mini-benchmarks comes in at xc being roughly 6% faster than clang.
Since there is also a framework and gui-designer under way, I’d like to release it as more than a tar.bz2 file for Linux at some point. Flatpark would seem to be appropriate :)
How is this supposed to be relevant to the article we're discussing?
QuadmasterXLII 1 days ago [-]
'I', presumably
spacedcowboy 1 days ago [-]
Yeah, thought that was pretty obvious, alongside the “AI-friendly” flatpark. Guess I’ll be more explicit next time…
Neywiny 1 days ago [-]
Zynq isn't an operating system? And you seem to be mixing OSs and architectures? Zynqs and I believe Versals contain both ARM (R and A) cores and a microblaze core. They can run bare metal, Linux, an RTOS, or whatever because they're just CPUs.
spacedcowboy 1 days ago [-]
Yeah “I” wrote the OS too, for the Zynq, or at least significantly extended FreeRTOS. See https://atari-xt.com
Zynq is an FPGA with dual Arm A9 cores, on one of which I run the OS, the other is earmarked for the m68k/030 emulator. There’s a hardware 6502 in fabric which has ANTIC, POKEY, and HDMI output (with audio). The OS includes a compositing window manager which uses shared memory to give each GEM window a retained-mode drawing surface.
You can see it booted up, running the emulator in either of:
The compiler is self-hosting, so can run on the OS on the FPGA, but this is quite long-winded an explanation so I just shortened it to Zynq.
The “I” in quotes is (for those who didn’t notice) an indication that I used an LLM to help me do all this.
Neywiny 16 hours ago [-]
It's really not. Zynq-7000 can have 1 or 2 A9 cores, Zynq MPSoC can have 2 or 4 A53 cores. It sounds like what you've done is modified the freertos A9 port. It's abundantly clear that you had LLMs do this, trust me.
spacedcowboy 15 minutes ago [-]
A few things:
- The Zynq MPSoc is the Ultrascale Zynq (released 4 years later), not the plain Zynq. A “good” (7020) plain Zynq board with decent I/O ports costs about £100, the very cheapest Ultrascale boards are twice that with far less expansion ports - to get similar I/O you’ll be up in the 3-4x price bracket at least. They’re very different products, fabricated on different technologies (16nm, not 28nm), with fundamentally different internal architecture (eg: Ultrascale has built-in Ultraram, far better power management, quad A53 + dual R5F vs (max)dual A9, codecs on some, ddr4 support,…)
- This isn’t the first OS I (without the quotes) have written for the Zynq. I wrote the OS for the Apple Vision Pro, quite some time before LLM’s existed, when it was a prototype on my desk, consisting of a Zynq being the boot-up device and architecture controller for a bunch of the fastest and largest FPGAs on the planet interconnected with optical fibre. And this one did not rely on FreeRTOS (or any other OS) for anything.
- I would agree with you that it ought to be blatantly obvious that I’ve used an LLM to help out, the timescale itself should be a dead giveaway. However, the very first comment I got (“How is this supposed to be relevant to the article we're discussing?”) seemed to miss the quotes around the “I”. The signoff comment was more a “get a life” response to the subsequent down-voting haters than anything else. LLMs are just tools, you still need the skills to direct them and correct them on anything as significant as a compiler.
- “modified” is carrying significant water… XTOS has dynamic linking, can launch external programs from disk not just compiled-in tasks, has shared memory, swap, threading, system calls, a posix layer, networking, virtual filesystem support, boot-script support, interactive shells with ptys, and a graphical compositing window manager which outputs 1080p HDMI (ie: with the embedded audio islands, not just DVI over an HDMI interface). But yes, “I” still use FreeRTOS for context switching and interrupt control.
I understand the objections to vibe coding, but for those of us who don’t care how a good tool was built (when it actually is good), this just forces us away from your favorite platform. Like it or not, this is the present and these AI tools are available. People will use them.
That said I think it’s utterly ridiculous that this article was written using AI.
0: https://www.debian.org/doc/manuals/developers-reference/deve...
How is using autocomplete "Vibecoding" now? I remember y'all that the "definition" for vibecoding requires the "prompter" to not look at a single line of code
Autocomplete with an LLM, which generates snippets for you is just a lubricated version of "copy and paste back and forth between chat window and code window"
> The policy is asymmetric, and that's what makes it harmful.
Well I found the problem already
Who is opening up an LLM to run git push?!
https://xkcd.com/927/
Its not entirely true either because neither git nor Github do things like dependency handling.
There are lots of alternatives to Github. Of the two alternatives to Flathub mentioned in the article, one has disappeared, and the other has all of 93 packages.
Meanwhile, a few ranks away on HN:
"Big AI to humanity: drop dead"
"The End Of Upward Mobility – AI is coming for the meritocracy"
It needs no host-platform tools to compile code, so for example I have a signed binary on my iPhone, written and signed entirely on Linux.
The compiler (v 0.61, not the released v0.6) currently produces code that is between 5x and 0.5x the speed of clang when measured at -O3 on both, against ObjC code, which is pretty good for a nascent compiler. The geometric mean of 19 mini-benchmarks comes in at xc being roughly 6% faster than clang.
Since there is also a framework and gui-designer under way, I’d like to release it as more than a tar.bz2 file for Linux at some point. Flatpark would seem to be appropriate :)
1: https://compile-xc.org/
Zynq is an FPGA with dual Arm A9 cores, on one of which I run the OS, the other is earmarked for the m68k/030 emulator. There’s a hardware 6502 in fabric which has ANTIC, POKEY, and HDMI output (with audio). The OS includes a compositing window manager which uses shared memory to give each GEM window a retained-mode drawing surface.
You can see it booted up, running the emulator in either of:
Https://0x0000ff.co.uk/mov/xt/xtos-aug-11.mov
https://0x0000ff.co.uk/mov/xt/ballblazer.mov
The compiler is self-hosting, so can run on the OS on the FPGA, but this is quite long-winded an explanation so I just shortened it to Zynq.
The “I” in quotes is (for those who didn’t notice) an indication that I used an LLM to help me do all this.
- The Zynq MPSoc is the Ultrascale Zynq (released 4 years later), not the plain Zynq. A “good” (7020) plain Zynq board with decent I/O ports costs about £100, the very cheapest Ultrascale boards are twice that with far less expansion ports - to get similar I/O you’ll be up in the 3-4x price bracket at least. They’re very different products, fabricated on different technologies (16nm, not 28nm), with fundamentally different internal architecture (eg: Ultrascale has built-in Ultraram, far better power management, quad A53 + dual R5F vs (max)dual A9, codecs on some, ddr4 support,…)
- This isn’t the first OS I (without the quotes) have written for the Zynq. I wrote the OS for the Apple Vision Pro, quite some time before LLM’s existed, when it was a prototype on my desk, consisting of a Zynq being the boot-up device and architecture controller for a bunch of the fastest and largest FPGAs on the planet interconnected with optical fibre. And this one did not rely on FreeRTOS (or any other OS) for anything.
- I would agree with you that it ought to be blatantly obvious that I’ve used an LLM to help out, the timescale itself should be a dead giveaway. However, the very first comment I got (“How is this supposed to be relevant to the article we're discussing?”) seemed to miss the quotes around the “I”. The signoff comment was more a “get a life” response to the subsequent down-voting haters than anything else. LLMs are just tools, you still need the skills to direct them and correct them on anything as significant as a compiler.
- “modified” is carrying significant water… XTOS has dynamic linking, can launch external programs from disk not just compiled-in tasks, has shared memory, swap, threading, system calls, a posix layer, networking, virtual filesystem support, boot-script support, interactive shells with ptys, and a graphical compositing window manager which outputs 1080p HDMI (ie: with the embedded audio islands, not just DVI over an HDMI interface). But yes, “I” still use FreeRTOS for context switching and interrupt control.