blinkingled

Yes 27B - not so much of a surprise but I was hoping for a usable coding model that's local and fast - this is fast but maybe not usable. I used Gemma4 26B before and it wasn't good in my testing.

I asked it to implement the simplest todo in ghostty codebase and it failed badly - kept going in circles fixing one compile error and introducing another. Qwen 3.8 was slower (40 tok/s compared to 75) but did get it done.

Ugh stop posting links dude - answer what do you mean by your previous claim for fixing everything you were complaining about earlier - "you should use open-weights models that run locally and "harnesses" built by members of the community" - like how is that not contradicting what you are saying - if open weights and local harnesses can do it Anthropic and OpenAI will do it faster and better. That doesn't make sense at all in this conversation.

I wasn't talking about fixing the tools or using open weight models - I don't need to watch anything to know that's an option. You are also now contradicting your earlier stance somewhat by saying what I was saying - LLMs can and will get better - you have now introduced an irrelevant open vs close element which doesn't really matter. There's no way only open weight models and harnesses get better - if you understand even a little, proprietary models with access to same open information but with billions to burn on research and hardware will get better faster.

I am not lowering myself or lionizing anyone - I am being practical about this. If we as a society have a workable stance for/against LLMs that is beneficial to all of us I am very open to hearing about it - It would however be fair to say that I am pessimistic given a lot of our collective history. And on oop of that nobody seems to be talking about any real solutions either this time around. Just being dismissive or being all-in are equally bad approaches.

Even after acknowledging that LLMs are fuzzy matchers and have been hyped, I am in the camp that rationally believes they will get better at some things including hunting bugs / chasing security vulnerabilities - my point also is that you and me can do whatever we can but on the grand societal scale we are not going to make a difference as far as slowing LLM adoption down - it just makes sense for some things and there's a lot of people with time and money that will make it do the rest - that's how it works until everything is saturated in the market.

So no I have no way to address anything you said - that was the point, I don't believe you can - not with regulation and not with voting with your money (I am sure some people tried to vote with their money to slow down mega stores and keep the mom and pop shop alive - there maybe some of those still there, but largely it's big chains occupying most of the market) - that stuff hasn't worked - heck LLMs work better today that that stuff has ever.

Just for the 'record' - I am totally with you on the hype and just in general the normalization of sleazy behavior surrounding it but I'm not sure we as normal people have any say anymore including where our money is going to be invested.

> he repeats some myths in the video, or at least confidently states some things that are not demonstrated to be true

I am genuinely curious what the myths/unproven things he states - I watched the video and it's repetitive sure but not much felt controversial to me.

Fair point, but he was talking about Mythos in particular and the point wasn't so much that LLMs will always have false positives rather he was saying they are causing a lot of them right now and how to deal with it.

Also as other replies said Linux kernel process is to assign CVE to everything - some of them may be just DDOSes, very hard to exploit and everything in between. All of them are bugs so they all get fixed and it's not a bad thing if distros ship those fixes and people update their kernel.

It's great to hear about $topic from someone no-nonsense and in-the-know like Greg KH. You can verify all of this too - since, well Linux kernel. (As opposed to what Microsoft or Apple claims to fix as far as LLM finds.)

Mythos may not be great today but it is not far fetched to imagine bug discovery, analysis and fixes can be made much quicker, accurate and even newly possible with specialized models trained on say Linux kernel specifics - with codemap/coding standards/threat models, good and bad coding patterns, tools to validate etc. an LLM can be much more relentless than humans and if it has the help to be accurate it will be worth the electricity burned. Oh and another model trained on triage data to validate the first one's findings would be good.

(I think Microsoft is doing this internally - different models trained internally alongside Mythos - there was some talk about it on the tubes, don't recall where exactly.)

> this work is focused on laptops with Snapdragon X2 Series. It does not currently cover desktop form factors, earlier Snapdragon X platforms, or other development boards. Readiness also varies by OEM design and Snapdragon X2 Series variant.

So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.

I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.

As a KDE Connect user for a few years I know it doesn't always work without reconnecting especially with sleep cycles on the phone and the laptop but it does everything on Android at least - clipboard sync, notifications, sms, calls, remote control and media playback control. Must be iOS restrictions that made the author go through the admirable effort.

IOW Linux ecosystem has better vertical integration without any direct ties with Android :)

Different programming languages are very obviously not the same thing - different cp command implementations are similar conceptually to having different linker implementations that all do the same thing. But you knew that so not sure if there was a point you were trying to make there.

Writing linkers must be incredibly rewarding - go has its own, there's mold, there's LLD, there's the OG GNU bfd LD and now Zig has one too! I am sure there's a Rust one too - Wild!

Every one of them is faster than the others too lol! Mold for one tries really hard to be GNU ld and to be useful as an independent linker most have to - I guess Zig/Go ones are purpose built so at least those don't duplicate GNU ld compatibility.

Now they only need to make sure that a supply chain for replacement batteries exists, there is regulation and competition and options remain available for a reasonable price.

There are plenty of old Dell and HP laptops with replaceable batteries which can only be found on eBay or some random seller that does who knows what under the refurbishing process.

I am a full time KDE/Arch user and since Plasma 6 haven't had any HiDPI issues including monitors with different DPI or X11 apps - of which there are very few nowadays.

> Tesla’s fix will involve an additional redundancy to keep the lightbar affixed to the windshield, should the glue fail.

Good news - it only affects 6000 vehicles with the optional lightbar which is dealer installed. Bad news - Tesla finds it ok to let its dealers do glued lightbar installations and can't really fix the glue failing part so they are adding redundancy.

I meant the I have no interest in knowing anything about any company's internal tech stack and also no interest in tying my application to one company's internal stack. Much of it sounded like lock-in to me.

Stopped reading at proprietary. Seriously why would I care tying my app to something proprietary and have no way out of it?

I was referring to the "HTTP request in Tokyo to find the nearest instance in Sydney" part which felt to me like a differentiating feature- no other cloud provider seems to have bidding or HTTP request level cross regional lookup or whatever.

The "decision that long predates Corrosion" is precisely the point I was trying to make - was it made too soon before understanding the ramifications and/or having a validated technical solution ready? IOW maybe the feature requiring the problem solution could have come later? (I don't know much about fly.io and its features, so apologies if some of this is unclear/wrongly assumes things.)

> The bidding model is elegant, but it’s insufficient to route network requests. To allow an HTTP request in Tokyo to find the nearest instance in Sydney, we really do need some kind of global map of every app we host.

So is this a case of wanting to deliver a differentiating feature before the technical maturity is there and validated? It's an acceptable strategy if you are building a lesser product but if you are selling Public Cloud maybe having a better strategy than waiting for problems to crop up makes more sense? Consul, missing watchdogs, certificate expiry, CRDT back filling nullable columns - sure in a normal case these are not very unexpected or to-be-ashamed-of problems but for a product that claims to be Public Cloud you want to think of these things and address them before day 1. Cert expiry for example - you should be giving your users tools to never have a cert expire - not fixing it for your stuff after the fact! (Most CAs offer API to automate all this - no excuse for it.)

I don't mean to be dismissive or disrespectful, the problem is challenging and the work is great - merely thinking of loss of customer trust - people are never going to trust a new comer that has issues like this and for that reason move fast break things and fix when you find isn't a good fit for this kind of a product.

This^. Keith W on Dtrace blog said it a decade ago https://wesolows.dtrace.org/2014/12/29/golang-is-trash/

I like Go but I don't really like their NIH / replace everything with our stuff stance - esp on system tools like assemblers and linkers.

Bye Microsoft - I'm already on Linux on all my desktop and workstation machines and working on migrating off of the MacBook Pro.

It's only going to get more and more unpleasant in the commercial desktop OS landscape - need to start contributing money and effort to few OSS projects to keep the dream alive.

Yeah, what I do is make use of the freedom fully when I can and that way it's like I have fulfilled my quota for procrastination and it's easy sailing for the stuff then I need to do :D - complicated and works for me but YMMV. Feels intuitive to me lol.

If you truly enjoy the procrastination as opposed to fighting it or distracting to another thing - sooner or later you'll want to do the thing you were supposed to do.

Try that out. There is a reason why you don't want to do something and that fundamentally has to do with your mental relationship to the task - the repetition fatigue, the way you think and feel about it etc. needs a reset and enjoying the idle procrastination time gives you that.

IOW Zen mantra - when you procrastinate just procrastinate without resistance.

I am happy for a new browser/engine but I'm highly skeptical that Ladybird will ever come close to Chrome or Firefox in terms of features, compatibility and performance. It's just very hard to imagine. There's servo and look at where it is after 13 years!

No offense to anyone really but browser engines are inhumane amount of talent and effort. Might as well just keep making Firefox better.

Ugh I upgraded excitedly and can't stand the UI - there is no upside to any of it. Also for some reason things are also beachballing and VSCode keeps crashing - new M4 MBP. All the system log errors are present exactly as they were and my USB-C dock with Ethernet port still doesn't work.

I have been working on finding out ways to make use of AI a net-positive in my professional life as opposed to yet another thing I have to work around and have cognitive load of. Some notes so far in getting great benefits out of it on couple projects -

* Getting good results from AI forced me to think through and think clearly - up front and even harder.

* AI almost forces me to structure and break down my thoughts into smaller more manageable chunks - which is a good thing. (You can't just throw a giant project at it - it gets really far off from what you want if you do that.)

* I have to make it a habit of reading what code it has added - so I understand it and point to it some improvements or rarely fixes (Claude)

* Everyone has what they think are uninteresting parts of a project that they have to put effort into to see the bigger project succeed - AI really helps with those mundane, cog in the wheel things - it not only speeds things up, personally it gives me more momentum/energy to work on the parts that I think are important.

* It's really bad at reusability - most humans will automatically know oh I have a function I wrote to do this thing in this project which I can use in that project. At some point they will turn that into a library. With AI that amount of context is a problem. I found that filling in for AI for this is just as much work and I best do that myself upfront before feeding it to AI - then I have a hope of getting it to understand the dependency structure and what does what.

* Domain specific knowledge - I deal with Google Cloud a lot and use Gemini for understanding what features exist in some GCP product and how I can use it to solve a problem - works amazingly well to save me time. At the least optioning the solution is a big part of work it makes easier.

* Your Git habits have to be top notch so you can untangle any mess AI creates - you reach a point where you have iterated over a feature addition using AI and it's a mess and you know it went off the rails after some point. If you just made one or two commits now you have to unwind everything and hope the good parts return or try to get AI to deal with it which can be risky.

I love using KDE and use it on all my desktop machines. I even have a source compiled version ready to test / hack on if I need - utterly fun and easy to build using kde-builder and works on most distros including Ubuntu/Debian, Arch and Fedora.

That said, I don't think having yet another immutable distro is a great idea if they are only going to punt and use Flatpaks. They can run flatpaks on any distro out there. So not really understanding the idea behind this. Nothing really stands out from the article - they still need to make KDE work great with most other modern versions of the distros so it isn't like Flatpaks based KDE is going to give them an edge in having the best KDE on their own distro.

What am I missing?

Thanks, that is definitely a good sign - given the rendering engine monopoly state of Chrome+derivatives and lack of great momentum behind Firefox adoption we need Apple to actively keep Safari not just viable but great even if only on macOS/iOS.