Hacker Newsnew | past | comments | ask | show | jobs | submit | boutell's commentslogin

I THOUGHT I WAS THE ONLY ONE!

I actually nuked my music library off my Mac to mitigate this problem, but it's still a nuisance when the app launches.

Thank you for sharing this!


Recently I got a PR that is (1) genuinely correct and useful, and (2) not from someone who uses the software in question at all. A happy outcome, but clearly the economics of open source contribution have changed.

Although I no way suspect this particular individual of anything untoward, of course it's always possible it could be part of one of the long-term goodwill-generation campaigns mentioned by the Ladybird team. Generating credibility by making seemingly difficult genuine contributions over a long period, then abusing that credibility. But in our particular project we're not in the habit of delegating approval authority, so I'm less concerned about that.


I wonder about this too. The other objections miss the point: if it's faster, and otherwise the same, and doesn't require different hardware, then why not just announce that the standard tier of MiMo-v.25-Pro is now ridiculously fast and raise the price? What does "limited high speed resources" mean if it runs on the same hardware as the rest of their pool?

I think the answer is that there's a tradeoff here where additional throughput for a single person can be achieved only by tying up more resources than a normal request would, even when you take into account the fact that the normal request takes longer to finish. I'm not an expert, but some of the optimizations they describe, particularly the parallel prediction stuff, sound like they could take up extra resources.


> and doesn't require different hardware

But it may well do. They mention TileRT in the announcement, so this speed comes from low level optimization for some specific GPU target.

With availability of SOTA western GPUs being scarce in China, they may well have a mishmash of different GPUs.


They specifically said it's stock hardware, but... yeah, maybe highly specific stock hardware.

Isn't that nitpicking? It's a smaller representation of the data, if you have a certain appetite for decompression time. It could conceivably be worth it. I think it would make a great level 2 cache for older chats.

In 1994 I was 2 years out of school. I'd written one windows shareware application and a whole lot of unix-y things. People were excited about the internet but most people didn't have access. Unix shell accounts via dialup were common though.

One day I was encouraged to write a Windows Sockets emulation layer for ordinary dial-up shell accounts like those offered by netcom. The idea was to allow the use of the recently released Mosaic browser without an actual internet connection. I figured sure, no problem. I'll use curl or some other tool in the shell account to do the actual fetching of URLs, transfer styles over zmodem, and simulate all the tcp/ip calls in the DLL.

I couldn't even get started. The reason is that I couldn't understand how the different Windows applications could all share memory allocated at runtime in the winsock.dll.

I asked a highly experienced ex Microsoft person, and he just said what are you talking about. There's no API to allocate shared memory.

So I gave up. 6 months later someone else did it.

Around then I realized the truth: Windows 3.1 had no memory protection at all. Specifically all global variables in DLLs were shared by default. The hard part wasn't sharing memory among users of a DLL. If anything, the hard part was having good discipline to avoid sharing it.

Since I'd only used multiuser Unix in school, and I knew Windows supported multitasking (even if only the cooperative kind), I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection.


> Windows 3.1 had no memory protection at all

All of the below is... IIRC

Win16, even in protected mode, in general didn't unless you opted out of the shared VDM. This was to preserve compatibility with how non-protected mode code worked. That said 32bit code or code that specifically marked itself as protected mode got it's own memory space.

> I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection

NGL... I was shocked when I found out that MacOS before 10... really didn't have much protections at all.


Owning reference books like Petzold, already doing C++ and TP coding on Windows 3.x, I am quite sure that the protection was there for Win16 applications in 386 Enhanced mode.

Now in regards to DLLs it all depended on which memory segments were being used, and the respective code on DllMain in regards to the thread/process attachment code and related handles.

Knowing what to search for quickly gave me this article from back in the day,

https://learn.microsoft.com/en-us/archive/msdn-magazine/2000...


Do they though? Are physics textbooks putting forward some version of string theory from the 1990s as proven fact?

I believe there was a science fiction story all the way back in the early '80s describing a scenario where physics gets reclassified as a soft science or an art form because it is no longer feasible to prove anything.

You're right that it's not literally frontier. But like recent Qwen releases, it is a lot more capable than anybody thought models of this size could be a year ago, like capable enough to set a ceiling on what you can charge for AI for certain applications. Others still clearly justify a stronger model, but this trend may continue, etc.

Me: I want this

Also me: just a month ago I bought a Bluetooth keyboard and mouse for my phone because they are completely sufficient for the work emergency use case along with the termux app


The thing about a diagonal measurement is it doesn't tell you if it's going to fit on a shitty airline tray table or not. Some laptops with a larger diagonal measurement are not too deep. Others are way too deep.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: