Anthropic is... making the US government shut down their flagship model on purpose? The conspiratorial thinking on HN is approaching UFO subreddit levels.
It's so difficult to have rational AI discussion here anymore. Half (or more?) of the developer community seems to have some form of AI hysteria that causes them to throw all logic out the window in service of the magical machine god.
I don't see how one could possibly come to that conclusion, except by rejecting out of hand the idea that there could be a true threat requiring genuine caution.
None, but the executive branch doesn't have any power to summarily prohibit American citizens from using dangerous things. If the danger checks out and can't be mitigated then Congress will have to pass a law.
Are you asking somebody what evidence they have that their observations are wrong? Like “I see you have an opinion there. What facts are you aware of that disprove it?”
No, I'm asking whether it's a fact-based opinion or a subjective one.
For example, I think that plant based meat is pretty much a dead end in the consumer market, but I can imagine things that would convince me I'm wrong about that. We could see sales of plant based meat skyrocket one year, or we could see a major beef producer announce that it's cutting 50% of the workforce in response to plant based meat, or we could see someone invent a new process that tastes much better. So I'd be interested to hear what someone who disagrees has to say, and perhaps they might convince me.
I also think that chocolate ice cream is bad. But there's nothing you could tell me to convince me that actually chocolate ice cream is good, because that opinion is not about external facts in the world, it's about me and what I like. If you tried I'd roll my eyes and ignore you.
So you see why it's an important distinction. If the original commenter was trying to say that they have specific factual beliefs about how dangerous the models are, we might be able to have a productive discussion about it. If they only meant to say that they personally don't wish to think about the potential dangers of AI models, then there's no point in continuing.
From what I understand gstreamer is more about building complex pipelines and plugins, ffmpeg is better at playing some obscure 20 year old video format extremely efficiently so you can watch it compiled for a potato.
That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins.
Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
A lot of us are happy gnome doesn’t support tray icons. We are sick of devs thinking their app is so important it needs a visual presence at all times. If I need your app I’ll bring it to the foreground, we have the technology.
Global shortcuts definitely a pain point with Wayland but the portals are making progress.
Yeah, I don't want want to take away from anyone. The COSMIC team is doing amazing and hard work. I started dev on claude-desktop-debian with Pop!OS COSMIC as my daily. We're just in a weird spot for that particular issue right now. In 3 years, it'll be something else. That's the nature of fragmentation.
While GNOME tray lovers and haters both exist, only one of those two groups is liable to submit an issue against my repo looking for help getting icons working correctly.
> A lot of us are happy gnome doesn’t support tray icons.
A lot of us = very few people in total, apparently.
There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros and overwhelmingly installed on those that don't have it. Even Gnome itself has started development on a native systray, although in classic Gnome NIH fashion they either want to implement a new standard or are were even considering using the deprecated snixembed standard instead of using what 99% of Linux does :+)
(Technically they want it for pretty good reasons, but good luck forcing all Linux applications to implement yet another standard, especially the commercial applications)
> There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros
Back when I still had a need for it it was solely because some apps do not have proper support for missing tray icons (you can only fully close them via the tray icon), not because I actually like the feature.
I appreciate that GNOME tries to move on from this. Unfortunately it doesn't have the market control that Windows has, so not all app developers follow suit.
The tray icon dock/panel in KDE is fully removable. You can just delete it. So the opposite of that is also a thing. No one is forcing you to always have a visual presence of a program. Even Windows let's you hide tray icons forever if you want.
But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.
All these issues can happen in any platform, Linux is just the more annoying/unpredictable one, with GNOME taking the cake for being so obtuse. There is either a carelessness from the developer or the ad-hoc nature of those "tray icon" systems is to blame.
> But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.
Can you name some that act like this? In 30 years I don't think I've ever seen that behavior...
That's precisely what is wrong with the state of the UI for Linux. Instead of boring, long research into user habits, finger memory, and productivity, resulting in boring standards like IBM CUA or Apple HIG, we got a bunch of opinionated engineers who think that people using computers fall into two categories: wizards, who are happy to spend their life tinkering with config files and making various pieces work together - and a bunch of losers not worth developing software for...
(Until Microsoft had actively started fracking it up, sometime around Windows Vista) just like a Roman citizen landing up in any town of the Empire, one would be able to effectively and consistently navigate around, using both keyboard and mouse across most Windows applications. Everything worked in a boring, predictable way. Everything used standard API that provided the whole spectrum of UI capabilities.
With Linux, unfortunately, this was never considered ideal and instead we have a zoo of different paradigms and technologies (plus intense politicking of UI development). Which means, when something happens to work as expected without excessive ServerFault/ChatGPT trawling and config/gconf/dbus wizardry, it feels like a sheer delight and an exception rather than a rule.
How do I bring your app to the foreground if I can't see an icon anywhere? I just installed Ubuntu for the first time a few weeks ago and genuinely don't see how people are supposed to use it, coming from a Windows/Mac background. How does a Linux user know what's running, without going to a terminal and running top?
The lack of desktop UI affordances in the leading "user-friendly" Linux distribution should be seen as a five-alarm fire by anyone interested in promoting wider Linux acceptance on the desktop. There are reasons why Linux can't get past low single-digit adoption no matter how badly Apple and Microsoft screw their users, and I'm sure the half-assed desktop UI is one of them.
> I don't know what the 'super' key in GNOME is, and don't care
This is like having someone tell you that they refuse to use an iPad because the home button confuses them. That's your choice.
I've used GNOME professionally for 7 years now, and I've taught kids to use it at robotics workshops. If you can believe it, many of them are unable to use macOS and Windows at all, because their school districts don't buy them laptops anymore. I'm sorry that GNOME isn't a carbon copy of your favorite OS, but it's not hard to use whatsoever.
So you really couldn't figure out what "Super key" meant, even with context? I feel like you are being hyperbolic. This isn't magical hidden Linux knowledge. Honestly, if not being able to find what applications you have running, and not even trying pressing the large button on your keyboard with the windows logo on it was so traumatizing, you might want to just avoid Linux entirely.
No, I didn't realize that the "Super key" was the Windows key, and no, I didn't think to try it. I never use the Windows key myself, because it's never needed. I'm either in a DOS or PS box, or if I'm working at the desktop, the taskbar gives me all the affordances I need including a 'Type here to search' box.
Key point is that I don't want to press any keys to maintain my awareness of what's running on the machine. Processes with windows associated with them should always be apparent in one way or another. Ubuntu got the less-useful part of the taskbar right -- the quick-launch icons on the column at left -- while failing to do the important thing, which is to show, well, tasks.
I remember when they first started putting Windows keys on keyboards. If you think AI pisses people off, LOL... you weren't reading Slashdot and other Linux-adjacent sites when those keys started showing up. It's amusing to see that they've been embraced (if not extended) by the haters.
> Processes with windows associated with them should always be apparent
KDE and GNOME both solve this with a dock, the same way that Windows and macOS solve it.
> It's amusing to see that they've been embraced (if not extended) by the haters.
The haters by-and-large don't use it. Those haters use esoteric tiling WMs that don't bind anything to super by default.
The KDE and GNOME developers have a direct usability goal. With respect to Slashdot's opinions, the Linux desktop would still be stuck in the 90s if we listened to them. Your perspective as a DOS/PowerShell user is not any more valuable, considering you barely use Windows as-is.
KDE and GNOME both solve this with a dock, the same way that Windows and macOS solve it.
Not by default, GNOME doesn't. Try installing Ubuntu. You get nothing but a blank desktop by default. The bar at left only shows shortcuts for launching tasks, not running tasks themselves.
Your perspective as a DOS/PowerShell user is not any more valuable, considering you barely use Windows as-is.
Those advocating an OS with 5% market share might do well to listen to other perspectives once in a while.
And that this key is called "superkey" is a widespread standard on computers?
Or just linux?
I think the latter. And it might surprise you, but there are computers with no linux installed. I think the vast majority actually. So why the need for insults?
Pretending like the person I'm responding to isn't being willfully ignorant isn't helping. It's pretty simple to guess what "super key" means just from context, if not, it's a very quick (in the op's case) llm query away. Let's be real here.
As someone whose last interaction with Windows was 98 and have been on Mac ever since I also had no idea what a super key was. Also Googled “Windows key” and realized I had seen it before in pictures but never thought about it.
I used some sort of *nix on a VAX terminal in college and ran SUSE on my machine once I realized I hated Windows 98 but all of that is ancient history at this point lol. All of that is to say that it is possible for someone to be peripherally interested in this topic and not be aware of what a super key would be even in context. Maybe someone that uses Windows could pick up on it earlier but I certainly didn’t:)
I am real. I used computers for a long time. Also linux, but not exclusivly.
Guess what, I also only learned recently (some years now I think) after making it mire default, that on linux the windows key is called super key. And the person you insulted clarified he did not use linux at all.
So, how should he have known, despite working with computer extensivly?
> We are sick of devs thinking their app is so important it needs a visual presence at all times
KDE Plasma allows hide selected applications from the tray and make those accessible in a popup window. The solution to this problem is not to remove the feature entirely, but actually implement it properly.
I don't like tray icons. What I like less is an app that runs in the background anyway when I didn't ask it to and that behavior is hidden. It's infuriating to "quit" an app and it's still there. At least gnome finally addressed that with the little background apps widget.
I still don't see what was so broken about X's security model that it warranted a whole new protocol (with its own problems that it's still solving 15 years later) instead of an extension to X11.
Did you hire a Linux release engineer? Or was the situation the typical team of devs maining macOS that have never heard the term “Wayland” before plus That One Guy who switched to Ubuntu last year and advocated for it?
There are companies that do this right. But it often requires a hire. Too many companies think they can just yolo it because Linux isn’t a serious OS or whatever and then are surprised when it doesn’t work out well.
But a full time hire? The GP's post implies that wouldn't make business sense for them, as even half a day occasionally on it is too much...
>> So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere. The number of tickets with Linux issues keeps growing and each one is taking more time to debug, all for a number of customers that is so small you can’t justify doing it.
Of course an experienced Linux release engineer can do it faster and more reliably. That's probably the cheaper option. But the business still has to decide their Linux customer or user base is large enough, or strategically worth supporting, to justify the cost however they do it.
For many businesses even fractional Linux support is not justifiable for the small number of Linux users and support requests they're unable to handle. Though I can't imagine that being the case for Anthropic!
(Hint: This is one of the things I consult on, if anyone is looking to pay for quality Linux release engineering and platform testing. I have hundreds of historical and current Linux VMs, multiple architectures old and new (esp. x86, ARM and RISC-V), some of them embedded, fairly deep knowledge of how the kernel and libraries work together, and test harnesses. Also I test some compiled applications for portability across other OSes and architectures, including Windows, MS-DOS, MacOS, BSDs, SunOS, HP-UX, etc. going all the way back to the early Unix lineage.)
Even for those who do this right, some things change under your feet because OSS maintainers of kernel feature A want to stop supporting V1 of A when V2 has been out for a decade. But the features missing in V2 are supposed to be provided by userspace B - and they are yet to tackle the functionality altogether. So now your app will just have to regress in features. It is very easy to ship OSS code as a maintainer of a project, it is very difficult to keep up with Linux as a developer unless you stick to libc. There is no one source of truth with regards to how things should work, there is no one roadmap, and maintainers care a lot more about complexity than maintaining feature parity of backwards compatibility. I do not blame them, but then it is difficult to target linux. Much easier to support a platform with guarantees and a shared vision. Saying this as someone who has only used Linux at home for 20 years.
Thanks to the Linux kernel's extremely high backward compatibility, and virtually all the libraries being open source, you can ship old or frozen versions of libraries with your application if you have to. You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality, while using the distro version if that's more up to date and still has the functionality. You can do the same for auxiliary programs your application uses.
I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications.
There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies.
It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty.
You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date.
Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI.
One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.
> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.
You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.
The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.
The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.
If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)
You cannot ship features that depend on cgroups v1. You may not ship features that depend on netlink attributes that exist on some distros, not others.
Yes, there are a few exceptions to the Linux kernel's backward compatibility. I've encountered others, but I don't remember which any more. They are quite rare, though.
cgroups v1 might be the most irritating, because it was useful and something a shipped application or service might realistically use.
This isn’t an issue in practice because the software running on Linux is open source. Yes if you want to distribute proprietary binary blobs and have them work forever it’s going to be a challenge, but in that case better to stick with the binary blob operating system.
The only proprietary software I have running on my machine is electron apps, which are essentially bloated VMs. As we’ve seen from this thread, this is still apparently too great of an engineering feat for anthropic to tackle. I don’t think I’m unique in this regard.
Tons and yeah of course some are also Electron apps but not all... Proprietary apps I can think of include Chrome, Teams until a few years ago (I think they just gave up), Steam, the JetBrains IDE's, Cursor, Discord, Matlab, ...
Of course a lot of Linux users these days just live their lives through browsers. That's pretty sad.
> The main reason must companies don't publish Linux electron apps
But they do? Companies don’t publish anything BUT electron apps. If desktop Linux gets anything from outside of FOSS, it’s electron. See Spotify, discord, slack, vscode… list goes on. I don’t think a for profit company has provided a GTK or qt app for Linux in the last 20 years.
I applaud your efforts but this is a supposed trillion dollar company with a product that probably has thousands of electron apps in its training set. They should be paying you.
Electron apps don’t work well across all of the Linux distributions if you’re doing anything that isn’t very simple.
The comment was that the Electron apps aren’t being released for Linux even when they exist because Linux is so much harder to support, even in Electron.
If they don’t have resources (or desire) to keep the Electron app working on all the Linux distros then they definitely won’t have the resources to write a completely separate GTK app for the few Linux users.
Microsoft gave up on teams for linux, the app that's available now is a community electron webapp wrapper, and Zoom isn't electron at all, its QT but they chose the path of only supporting a few distros (Ubuntu, Debian, Mint, RedHat) and they also don't rely on system QT versions, they vendor it.
If your app is open source, I say just build & test on one of the major distros and let the community port it to others. If its closed source, well, good luck. But if what the parent said is true, that you now collect a bunch of very vocal pissed off customers because you didn't support their favorite distro, then its just not worth it at the current marketshare that desktop Linux has.
There's also the challenge of you just can't make any assumptions about what may be present or not on someone's Linux machine, even with the major distros.
According to the latest SO dev survey Ubuntu has 28% market share among developers. Considering coding seems to be the one place LLMs have found product market fit, I’m not sure how you can make the argument that the market share is too small. For other companies, absolutely. For ones marketing towards developers, seems like a mistake.
How many devs use or would use a GUI app vs. just claude code in the terminal? My guess is not too many.
I personally think they should port it, but, the developer product does already run on Linux, in the terminal, as is the case with the majority of other dev tools.
Using a largely-stock Ubuntu desktop for work the past 6 years, Zoom has also been one of the most broken mainstream apps I've every used on any system ever. I appreciate they provide a native Linux option, but it has consistently been barely functional—often fully unusable to where I'd join important calls from the browser instead.
If all you want is a chat interface you can install Claude.ai as a PWA. The value proposition of the Claude desktop app includes being able to screenshot and interact with desktop app windows, the file system, etc. That drags you into desktop environment and compositor API hell.
So tired of the nonsense.
reply