Maybe, but also, they just hit a few of the largest data centers. Russia simply does not have that many large data centers and it's not so much of a secret where they are located I guess. Such an attack disrupts a lot of things and it's natural that the Russians focus their recovery efforts and the spare capacity they have left elsewhere on more critical services.
There is also the problem, that some OEMs add their own "battery optimizations". If you simply don't run anything its indeed very battery efficient...
Forcing push notifications through some central service has minimal benefits at best. Open source variants are forced to publish annoying persistent notifications and ask the user to flip some "battery optimization" toggle deep inside the settings to not get killed, of course this often enough changes with Android versions.
You're talking about the standard battery optimizations where the end user needs to approve apps repeatedly waking up the app from sleep and running continuously while awake. OEMs have been required to stop doing most of the non-standard things they were doing in relation to this and it's not hard for app developers to deal with anymore unless they care about it on end-of-life Android versions.
The persistent notification for foreground services is mandatory for apps to implement but entirely optional for users. The notification channel can simply be toggled off to hide it. Apps are required to make a notification for each foreground service to provide transparency. It gives apps a way to explain why they're doing it to end users and the notification be toggled off if the user doesn't want it. It can also be kept enabled but collapsed at the bottom with no lockscreen or status bar display. Apps are required to use at least low importance themselves so the user needs to opt in to collapsing and hiding it or turning it off.
Fully open source apps can use UnifiedPush as the Molly fork of Signal does instead of their own push connection. Similarly to FCM, UnifiedPush providers can provide reliable and efficient push messaging including push notifications. Unlike FCM, users can choose the local implementation and the service providing it including the option to self-host it. There are multiple options available as an existing service. There are a growing number of apps supporting UnifiedPush.
Signal's own fallback push messaging for push notifications when FCM isn't present is very inefficient. It substantially reduces battery life even if it's the only app doing push with another mechanism. Molly's UnifiedPush support works much better.
Using a single push messaging connection or at least only a couple (FCM and UnifiedPush) is definitely far more efficient than using dozens. Using many push messaging connections will drain a lot of power due to each needing to be maintained with regular checks which will typically not align well. Having many causes a drastically higher number of wakes from sleep and non-idle time. That's especially true if the push messaging connections aren't implemented very efficiently. Even a single inefficient one can drain a lot of power.
Signal's fallback isn't as bad as it used to be but it's not efficient. They should support UnifiedPush as Molly does for a better non-FCM push experience. Signal's fallback push is a common way people ruin battery life on GrapheneOS.
Looking at the amount of RAM phones have nowadays I don't know if this is an issue, desktop Linux runs fine with those amounts. Also Android is not really memory efficient so they needed this workaround.
I currently have 35 apps "open" on my iPhone, most of which are probably React Native or similar.
Other times I'm sure I've hit 60-70.
Because of iOS's app management feature, most of the apps are actually dead, but if I go back and open any of them, they will open and load on the screen on which I left them.
Android does this too.
Desktop Linux cannot.
Can I open 60-70 or even 35 Electron apps simultaneously on 8GB of RAM on Linux?
And no, I do not want to to back to closing apps, that is simply an inferior experience.
> they will open and load on the screen on which I left them.
You can't be serious. Browsers can't even remember the most trivial of things - a tiny html page, retaining reading position, forcing a reload.
Of course many apps are no better (though some do try, just like on the desktop)
And it's especially worse with user input that just gets lost
> And no, I do not w to to back to closing apps, that is simply an inferior experience.
Ctrl+Q to close and a shortcut to open or is a faster and more convenient than swiping around. As is typing an app's name on a real keyboard. Tapping "desktop" icon is arguably better, though, that a mouse click
Of course some apps implement this better or worse, but for an app that doesn't implement this, booting me to the home page (which is just one tap away from where I was) is still miles better than hogging ram.
I don't want to close apps, I don't want to manage my computer's resources.
> It should just work and it should just work well.
That's just magical thinking (thought I totally agree with the sentiment, it should, and Linux should also be better), it doesn't, you're still doing the management, just using a different set of gestures.
For example, knowing about this poor "incredible engineering" I sometimes have to reopen the app in the middle of using another app not to lose my input/position there, especially when I need some basic cooperative behavior like copy paste in multiple steps, where I need to make sure no steps are lost. The primitive iOS system can't guarantee that! And in some instances I'd take the overall sluggishness due to RAM waste over this because then I'd still manage to complete the task, albeit slower, instead of having to redo the work (and in some old apps I could even save intermediate progress to those ancient things called files that Apple despises)
> which is just one tap away from where I was
Except it isn't. If you've scrolled to X% of the document, there is no 1 tap to get back there! And if it took you 5 taps to open that sub-page sub-group it the app setting, then getting from the hope page will take the same 5 taps + some time wasted remembering where you want to go to. And if you lose your input in the input field, same thing, 1 tap won't magically recover it.
And if you're temporarily in a place without (good) network conneciton, you might never get there in any number of taps becaus the page won't load.
Btw, if it's fine to lose user data, than Linux can OOM your apps for you just fine without any extra management on your side. Sure, its current state of app management is not as good as on mobile, it does lack some "engineering" in this regard, though not sure what's so magical about more careful killing of apps
> it's fine to lose user data, than Linux can OOM your apps for you just fine
That's the point. Android and iOS have cooperative applications by design. They implement an interface and apps will save their state on command and restore it on next run quickly.
You can't get it back properly without the apps being cooperative to a degree
Again, what I've started with - this is simply false. App Store, the first party gateway to all apps, doesn't. It loses the app page you're in all the time and can't even remember your search query. Safari doesn't
> On Linux no app CAN implement this because the protocols do not exist.
What do you mean, what stops an app from saving position and restoring it in the absence of some magical protocol? How have some apps done in since before the phones existed?
Huh? I just tested it now and the App Store reopened on the same page I was on and Safari also opened on this page and it remembered what I had written into the text box.
More generally apps can store whatever info they want when they're going away to be retrieved when coming back transparently.
On the other hand semantics on the Linux desktop are such that the operating system cannot inform an app that it is going away transparently.
An app that is SIGKILL'd cannot save anything (unless it is proactively saving all the time which is terrible for battery life), an app which is SIGSTOP'd must save it's entire memory space and cannot relinquish locks or GPU resources, and an app that is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
No wonder you've been oblivious to this issue with 40 apps. Test better, I suppose? Maybe give it more time for the system to fully offload the app, maybe run a few intensive games if you want it faster or just wait longer?
Have you tried other tabs in Safari? Turned off the internet to see whether it's redownloading a page. (by the way, Safari uses 1G of cache, that's enough to store all my 40 tabs basic htmls, yet it doesn't, it finds other less relevant data more important)
And just for this I've tested two more native apps: opened settings/filters in Magnifier, and started editing a password in Passwords app. I was glad that both of these seem to remember the state, and their app switcher screenshot reflected it (well, except for passwords, which is hidden), but then after a longer time reopened them, and position was gone and I was back on the main page - exactly the experience I came to rely upon with trivial bits of state simply gone.
> is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
Why can't it save the state without asking??? Have you used text editors with hot reload? They just quit with "unsaved" (but not "lost") files.
And GPU buffers? And in-flight network requests? And notification handling? And D-Bus presence? And watchdogs? And other held resources like pids and fds?
If you want to checkpoint/resume applications arbitrarily, as AOSP does, you have to virtualize all of those resources anyway. Check out the CRIU patchset (since merged to mainline) which can even resume applications seamlessly across hosts, without any VM being involved.
This gets brought up several times in this discussion. Hardware with drivers, firmware and device trees exist, see e.g. Fairphone. It even works with open source camera apps (e.g. done in /e/OS). The problem is not (only) the hardware, it is that the Linux desktop stack is wholly unoptimized for phones. And the fact that Meego/Maemo/etc. are now almost two decades ago shows that it is not 'would be easy to solve'. Heck, Linux laptops, which have been available since forever still have far worse battery life than Windows or macOS.
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
Depending on the phone they'd struggle to go in a low power state when the screen is off or can't access other power saving features because the manufacturers keep everything under wraps.
Mythos turned out to be exactly the marketing stunt it smelled like.
There are others like AISLE who seem to be a bit more successful in finding actual issues using LLMs in some shape or form though, whatever they do differently. Chances are high the secret sauce is not so much about the model being exceptionally powerful which would be bad news for the frontier labs.
I think Daniel is giving a more balanced view with:
> Any project that has not scanned their source code with AI powered tooling will likely find huge number of flaws, bugs and possible vulnerabilities with this new generation of tools. Mythos will, and so will many of the others.
Greg's video is a good reality check on the hype. But I'd be careful about generalizing from Linux, libcurl, etc which get far more scrutiny than software projects in general. LLM-assisted bug finding still matter a lot for everyday custom and less popular software.
> That we are finally having a sane pendulum swing towards no copyright is a breath of fresh air.
Might be a short one though if all goes to plan. Just another form of gatekeeping the worlds information and with new gatekeepers replacing the old ones.
> At the same time it's truly baffling going on a site called _hacker_ news and seeing corpo talking points from the 90s/00s regurgitated wholesale. Information wants to be free.
> It's also nice that it translates directly to the file system.
On the other hand, this means that it's bound by filesystem naming rules - e.g. you can't have an object named "abc/", or a pair of objects named "a" and "a/b".
The only reason OpenAI and Anthropic are making a loss is due to training new models to keep up with competition - not because the industry is flawed in terms of business model.
> The only reason OpenAI and Anthropic are making a loss is due to training new models to keep up with competition - not because the industry is flawed in terms of business model.
So in other words they are not profitable? Like you cant say they are profitable and then in the next sentence say they make a loss. That is not how profit works.
The point is that the model is already immensely profitable. There is no fundamental reason why AI isn't profitable. It already is.
Insane competition does not last forever. When chip manufacturing first started, there were dozens of companies that had fabs that made compute chips. Nowadays, only TSMC is viable. Samsung and Intel survived because of geopolitics.
> Is that not self evident by the insane revenue from frontier labs?
No...? Of course not?
Because revenue is only one side of the equation. Did you ever look at total cumulative OPEX and CAPEX, and how long it will take them to even just break even at current growth?
They're likely over $80b ARR by now. They'll be at $800b ARR next year at the same rate. Let's say their growth gets cut down to 3x instead of 10x - that's still $240b ARR by this time next year.
When you are growing so fast, you don't need to make a net profit. You just need to make sure your unit economics are good - which it seems like they are given reports that their gross margins are at 60-70%.
> They're likely over $80b ARR by now. They'll be at $800b ARR next year at the same rate.
And they will be 800 trilion ARR in a couple of years, following that same rate! 8 quadrillion by 2029!
> When you are growing so fast, you don't need to make a net profit. You just need to make sure your unit economics are good - which it seems like they are given reports that their gross margins are at 60-70%.
If their margins were anywhere near this good, they wouldn't need to raise so much money so often.
If you create a machine that turns 1 dollar into 3 dollars, you don't dillute your ownership of the machine, you use your fabulous profits to expand your machine's capabilities.
If their margins were anywhere near this good, they wouldn't need to raise so much money so often.
Why not? They are reinvesting into growth. There isn't a clear winner yet and Anthropic wants to make sure it is one of them. Taking a profit now while letting OpenAI take your marketshare and train better models is not very smart.
Or they bleed money like crazy, and their margins are pretty awful. Which is the correct answer.
Your $200 subscription is a major net loss for them. The vast majority that pays for that would cancel in a heartbeat the moment they had to pay API prices. Which may or may not be profitable, I am not entirely sure. But for the sake of argument, let's assume that it is.
Wihout insight on how much enterprise is paying, it is impossible to draw any conclusions. Unless you have any access to their contracts and are willing to share evidence? I find that highly unlikely.
People here throw around crazy numbers - the dude above was claiming they have some insane good margins, numberd that he took out of his ass.
The only evidence I have is that they are incredibly unprofitable, and they keep raising insane amounts of capital like crazy.
There was a leak sometime ago that they were EBITDA positive during a quarter where they didn't pay for part of their compute. And EBITDA is a cute metric to use when depreciation is actually very important to them, as a model from a year or so ago is nearly worthless.
serving models is very profitable (70%+) but the issue is you need to invest in training the next iteration. but so far all of anthropics models have been profitable fully loaded
the vast majority of the labs revenue is from enterprise api usage (theres public sources from the information and ramp). but the risk there is customer concentration, where most of the revenue comes from other tech companies and a chunk of it is from foreign labs distilling
so i am drawing a conclusion that the labs' business model is good, maybe not as great as boosters think it is. if they make real progress on the biosciences like drug discovery that could turn it into an amazing business
This is not evidence. This is random people speculating on Anthropic's margins without any real evidence.
Just because it is on some blog post, it does not make it true.
I wasted the time to read the first blog post. It considers 100% utilization over the course of years to calculate an estimation, and it did not consider depreciation for the model itself. That thing is extremely extensive to create, and after a relatively short amount of time is considered outdated.
Are we still calculated $200 subscription token spend based on their highly inflated API token cost and then concluding that they must be losing money on all $200 subscriptions?
Sure, there is revenue, and market valuation. Is there _profits_ in frontier models ?
What is the horizon for openai and anthropic to _make_ money ? Will they achieve that by charging more for frontier models, or investing slightly less in training frontier models, etc... ?
I've heard it before and believe it that one reason is because many of the developers are working on new maxed-out machines and network connections both at work and home, so they don't notice problems for older or cheaper ones and/or can't justify it to management.
Taxis in general are a working and proven business model. You could have been skeptical about the way they approached it but surprise surprise, you can make money providing taxi services. Less so with "AI", it's not proven at all that this can be made profitable in the near future.
The failures of past doomsayers are important to keep in mind. It’s hard to say “well, but we know things they didn’t know at the time, but this time that won’t happen.” I will observe, however, that Uber’s revenues come from consumers. Consumers are never going to be willing to spend enough on AI to justify OAI and Anthropic’s spending, even if a single company captured all of their demand. They recognized this and pivoted to software engineering and enterprise customers. These are much more sophisticated buyers than someone trying to catch a cab or get a burrito delivered, and more able to be patient or expend resources to find a better, cheaper provider.
It also bears mentioning that if any particular AI lab manages to survive and succeed in the way Uber has, there will be several multibillion dollar corporate gravestones behind it. In fact, I don’t even think that nobody can be the Uber of AI. I just think it can’t be OAI or Anthropic. The debt is too great and it’s priced under old assumptions.
reply