You are not logged in.
I've been trying out the ArtCraft suite — the Rust clean-room reimplementations of the Adobe tools that got a lot of attention this month — on Arch, installed through linyaps instead of the upstream AppImage/Flatpak builds. Posting the numbers since "does it actually work on Linux" seems to be a common question right now.
Short version: all 9 apps I installed launch and render correctly, the four I profiled all pick up the GPU through Vulkan with no software fallback, and I couldn't measure any container overhead.
Environment
- Arch x86_64, Wayland session, 16 threads
- AMD Radeon 780M (RADV PHOENIX), Mesa 26.2.4-arch1.1
- linyaps from the official [extra] repository
- Apps installed with ll-cli
What was tested
- PhotoCraft 0.9.0 — image editor — Vulkan / RADV PHOENIX
- LightCraft 0.8.0 — photo library, RAW development — Vulkan / RADV PHOENIX
- FilmCraft 0.7.2 — video editing, grading — Vulkan / RADV PHOENIX
- VectorCraft 0.11.0 — vector illustration — Vulkan / IntegratedGpu
- EffectCraft 0.9.2 — motion graphics, VFX — launches and renders (panel not captured)
- PdfCraft 0.8.0 — PDF workbench — launches and renders (panel not captured)
- CADCraft 0.6.2 — CAD drafting — launches and renders (panel not captured)
- DesignCraft (no version in UI) — page layout — launches and renders (panel not captured)
- FigCraft (no version in UI) — UI design — launches and renders (panel not captured)
The first four are the ones where I opened the system info panel and read the adapter and backend directly. For the rest I only confirmed the app launches, draws its canvas and doesn't crash.
How it was installed
linyaps is a containerised packaging format (the project formerly known as Linglong); the runtime package itself is in [extra], the applications come from its own repository.
sudo pacman -Syu --needed linyaps
ll-cli search photocraft
ll-cli install ai.storyteller.photocraft
ll-cli run ai.storyteller.photocraft
No Qt/GTK or other runtime libraries needed manually — dependencies ship inside the package. App IDs vary, so check ll-cli search output first.
Three things that stood out
1. The apps don't share a graphics stack. PdfCraft uses egui + hayro, PhotoCraft uses a wgpu compositor on Vulkan, the others differ again. All of them work inside the same sandbox, which is a better stress test than a single app.
2. GPU passthrough worked where I could check it. PhotoCraft, LightCraft, FilmCraft and VectorCraft report the RADV PHOENIX adapter and a Vulkan backend in their system info panels. None fell back to software rendering, which is the failure mode I was looking for.
3. One runtime covers all 9 apps. linyaps layers shared dependencies, so installing the whole suite doesn't mean 9 separate Qt/GTK/rendering stacks. Different model from Flatpak's per-application runtime.
Numbers
LightCraft, with a real library loaded (24 photos, 7 albums), system info panel:
- Frame time: 1.0 ms (122 fps)
- Frame update: 1.1 ms (logic 0.2 ms; slowest frame 22 ms)
- Last loupe render: 710 ms
- Memory budget: 1536 MB
- GPU rendering: on
- Compositor: GPU / window renderer: graphics adapter
How I read these:
- At 60 Hz you get 16.7 ms per frame, so 1.0 ms is roughly 6% of the budget. Whatever the sandbox costs is buried in the refresh interval.
- The 22 ms slowest frame is occasional jitter, above a 60 Hz frame budget, but not noticeable when browsing a library.
- The 710 ms loupe render is a single full-size render and comes from the upstream implementation, not the sandbox.
FilmCraft codec support
Native Linux NLEs usually fall short on professional formats. FilmCraft's compatibility report lists:
- Decode: H.264 (AVC), H.265 (HEVC) Main / Main 10, VP8, VP9, AV1 Main, Apple ProRes, Avid DNxHD / DNxHR, Motion JPEG, AAC-LC, Opus, PCM
- Containers: MP4 / MOV (ISO BMFF), Matroska / WebM, WAV, PNG / JPEG stills
- Export: H.264, Apple ProRes, Avid DNxHR, APV, QuickTime (MJPEG), PNG, TIFF, BMP, JPEG, Targa, DPX, OpenEXR, Animated GIF, Waveform Audio, AIFF, AAC, FLAC, MXF OP1a, MXF OP-Atom
H.265 and AV1 export are marked unavailable in this build. ProRes, DNxHR and MXF OP1a together is unusual for something running natively on Linux.
Two caveats
1. Drag and drop doesn't work under Wayland. Upstream limitation in winit 0.30. Use File > Open, or copy the file in your file manager and press Ctrl+V in the window. If you need DnD, launch under XWayland: WAYLAND_DISPLAY= photocraft
2. X11 is noticeably less smooth than Wayland for this suite. The compositing path appears to be Wayland-oriented.
Other notes
- Everything here is early alpha. Upstream says plainly that it isn't ready to replace professional workflows yet (no generative AI, some tools and typesetting depth missing).
- Versions move fast — several releases in October alone. Update before reporting a bug.
- The linyaps packages are community-built, not upstream builds. Check ll-cli search for the current version and availability.
Not tested
Disk usage and cold start time. I didn't compare linyaps against Flatpak for the same suite, and that's arguably the more interesting number — "what does sandboxing actually cost you in bytes and seconds". If anyone has measurements for either, or frame times from the Flatpak/AppImage builds to compare against these, I'd be interested.
Offline
Appimages here: https://github.com/orgs/storytold/repositories
Offline
https://aur.archlinux.org/packages?O=0&K=artcraft
Standard disclaimer:
Keep in mind that it's very cheap (for now) to have an LLM generate a shit ton of code and then stash some malicious lines inside.
This is not the same as someone writing and curating code for a decade or so and you can kinda expect this not to be a state-level actor trying to turn your system into a drone.
I am explicitly **NOT** saying that that's the case here (there's apparently a business vector attached and "hey chatgpt, write photoshop" has proven to be the most unoriginal idea), but be fully prepared that that kind of shit *is* going to happen and don't acquire bad habits.
Hacking as criminal enterprise is ROI driven and LLMs considerably lower the "I" part.
Offline
https://aur.archlinux.org/packages?O=0&K=artcraft
Standard disclaimer:
Keep in mind that it's very cheap (for now) to have an LLM generate a shit ton of code and then stash some malicious lines inside.
This is not the same as someone writing and curating code for a decade or so and you can kinda expect this not to be a state-level actor trying to turn your system into a drone.I am explicitly **NOT** saying that that's the case here (there's apparently a business vector attached and "hey chatgpt, write photoshop" has proven to be the most unoriginal idea), but be fully prepared that that kind of shit *is* going to happen and don't acquire bad habits.
Hacking as criminal enterprise is ROI driven and LLMs considerably lower the "I" part.
The solution to the problems of AI is more AI. AI's will scan binary code for malware, and along the way find all the bugs the "expert" programmers left in. It's embarrassing that for decades everyone thought "they were the professionals", and then AI happened and security fixes started to pour in. So many that people are having difficulty keeping up. But this is not new news anymore, and in a year or so imagine how secure the kernel will be instead of what we thought it was.
Also, software as you say is now trivial. As AI improves it will decompile, update to modern standards, and recompile any software you want. And you can't copyright a software interface to stop it. Open-source is not quite dead, just now everything will be open-source whether or not it likes it.
Last edited by headkase (Today 08:39:22)
Offline
The solution to the problems of alcohol is more alcohol.
Sounds familiar.
This isn't a matter on whether (better) automated tools will be able to find more bugs (nor whether experts introduce bugs, no Allan-shaming!
)
Malware is NOT a bug and does NOT follow its patterns. Malware is perfectly correctly functioning code that does something undesired.
Malware is a function of steganography - hiding a malicious signal in benign looking noise.
LLMs have proven to make it drastically cheaper to create that noise - proof of signal detection is pending.
And when introducing that into millions of lines of AI slop you'd probably also have the lucidity to test whether the available models can detect it.
And even if: how long does that take - for the LLM but also for somebody to tell it to find that.
it will decompile … you can't copyright
The ArtCraft project stresses that it has not decompiled any software (whether they can actually positively *know* that as it includes what the used models have been indirectly trained on) because that would actually get them into legal trouble for sure.
Offline
The solution to the problems of alcohol is more alcohol.
Sounds familiar.This isn't a matter on whether (better) automated tools will be able to find more bugs (nor whether experts introduce bugs, no Allan-shaming!
)
Malware is NOT a bug and does NOT follow its patterns. Malware is perfectly correctly functioning code that does something undesired.Malware is a function of steganography - hiding a malicious signal in benign looking noise.
LLMs have proven to make it drastically cheaper to create that noise - proof of signal detection is pending.
And when introducing that into millions of lines of AI slop you'd probably also have the lucidity to test whether the available models can detect it.
And even if: how long does that take - for the LLM but also for somebody to tell it to find that.it will decompile … you can't copyright
The ArtCraft project stresses that it has not decompiled any software (whether they can actually positively *know* that as it includes what the used models have been indirectly trained on) because that would actually get them into legal trouble for sure.
I recall the author was mad at them over excessive charges, like cancellation fees. That's their motivation, and binary recompilations are already a thing, and tooling will improve. AI already finds plenty of security bugs and malware is the same. Also, once hardware and software is optimized with better architectures and algorithms what used to be big and expensive could become small and cheap in only a few years. Once the gazillion of GPU's in data-centers yet to be built age out in 5 years you'll likely be able to pick them up cheap(er) as well.
Offline
it will decompile … you can't copyright
https://bridgelegal.org/lotus-v-borland … rinciples/
I meant you can't copyright an interface so existing users can easily migrate, and underneath that interface the code is not the same and is not copyright infringement. Congratulations Adobe! You're being open-sourced! Please do not resist. ![]()
Offline
The solution to the problems of alcohol is more alcohol.
Sounds familiar.
Explain that equivalency? "Alcohol" is a negative bias, and AI is not yet proved for that point either way.
Offline
Moderator Note
Please stop power posting and full quoting of previous posts.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Moderator Note
Please stop power posting and full quoting of previous posts.
I posted them as I thought of the points, sorry to waste precious electrons.
Offline
Explain that equivalency? "Alcohol" is a negative bias, and AI is not yet proved for that point either way.
If you throw postulating platitudes at me I'll throw some back ![]()
I don't want this to be misconstrued as some anti/pro-LLM flamewar.
The point was to remind people of threat vectors from a new technology that's possibly not on their screen - because it's new ![]()
Ftr "alcohol" isn't negative but (even as drug, as most drugs) has some very positive features.
Alcohol abuse however is, specifically when people believe that what causes their problems is actually a solution to anything.
Offline
headkase wrote:Explain that equivalency? "Alcohol" is a negative bias, and AI is not yet proved for that point either way.
If you throw postulating platitudes at me I'll throw some back
I don't want this to be misconstrued as some anti/pro-LLM flamewar.
The point was to remind people of threat vectors from a new technology that's possibly not on their screen - because it's newFtr "alcohol" isn't negative but (even as drug, as most drugs) has some very positive features.
Alcohol abuse however is, specifically when people believe that what causes their problems is actually a solution to anything.
See: https://en.wikipedia.org/wiki/Memex
A memex was an early hypertext system that sought to turn an information explosion into a knowledge explosion. And it worked, the descendant we call the internet is a knowledge explosion. We now have a new problem: integration of all that knowledge. So much is produced that no individual can find it easy to keep up in their own field. The promise of AI, as in the recent solutions to long-standing mathematical problems - shocking mathematicians, is to do the same thing the memex did just at the next level: turn a knowledge explosion into practical and accessible wisdom for whatever profession is needed. The shift from humans trying to track and research documents to code applying the contents of documents you didn't even know existed into real things with minimal effort. "Civilization advances by the number of important actions we can perform without thinking about them". I go to Claude for one-off programs that I need, it takes a few minutes, and software that I needed appears, and it's trivial. Open-source is dead for sure, but so is closed-source: software is done, it's inevitable as AI just keeps getting more competent.
Offline