rldjbpin

i wonder how much traffic can be avoided by pushing for bandwidth-considering updates to the git client itself.

things such as shallow clone by default, applying lazy evaluations on repo with large commit volume (e.g. partial remote-related operations at branch level until it is switched to), etc.

if reading these overloaded graphs is the problem, most readers (nowadays through automated consumption) only care about the current snapshot of a project's code. that too in probably the main branch.

github can probably make the git maintainers implement this. feels like it is worth trying at least.

for a team that was using the underlying stack (other than the ui library) for other components, trying this is a low-hanging fruit of an experiment. this should not automatically become the recommendation for everybody. (yes i do hate electron apps)

for a large project like electron, it is up to the maintainers to optimize it while preserving the api. if they can do this with typescript, they can also explore this with electron. perhaps a native webview option instead of chromium?

with current memory crisis, devs with cushy performant laptops bought over a year ago should realize that we yet again have hardware constraints and need to act accordingly. however, putting the pressure at the wrong place is not as productive.

ain't no way i am affording one, but it would have been nice to choose if you want a touch panel or not, just like the matt finish.

clearly it will be a while before it would be a standard across the lineup (air is still fanless, perhaps to a fault), so allow someone to continue the old way without needing additional complexities with a touchscreen. perhaps allow to save by downgrading to a non-touch one?

regardless, oled panels tend to be a mixed bag in terms of text rendering. i wonder if they did a good job with theirs. having adaptive refresh would definitely help those on dark mode in terminal to eek out even more life out of their laptop.

welcome change if so i suppose. however the better half of the past decade have been rough for sourcing for them, but they keep making decisions that often don't make sense in terms of consistency.

i'd understand using micro-usb on a $5 sbc, but now with themselves charging for accessories, especially on the rpi 5 with the $15 power supply, something's gotta give.

i appreciate the challenges with properly supporting a standard at a reasonable component cost. but in a sea of poorly designed usb-c, doing micro-usb otg for the new zero would be outright ridiculous if they go ahead with it.

the video out has similar grievances where a cheap usb-c dongle is better than adapting hdmi in niche, fragile ways. i hope the model a still allows using the bandwidth provided by the soc to still add ethernet and regular connectivity for those who would rather implement it themselves.

whether the focus is at commercial partners or still the foundation's core audience, i hope they stop nickel and diming on the simpler components going forward. tough times to make hardware as usual but i hope they keep on trucking with the releases.

the designs shown by op are wayyy out there. the ones i've grown up with were much more spartan in comparison. just having any lights, forget the ones used for actual lighting, remains a foreign concept to me. these ones look like the lighting and looks have higher priority than the core function.

for me just having a brushless motor and a remote was good enough lol. maybe smart home functionality nowadays perhaps.

quite interesting to see the public discourse over ethics of the current buzzword. meanwhile people have been happily getting mad rich through software companies making money through addiction, ads and surveillance throughout the last couple decades.

also, all of this seems like crying wolf as usual, which won't help for when we finally get there. lowkey, following this noise is getting as horrible as getting all your news from linkedin posts.

this release could be an email or a website post. they happen to do a devday so i understand the formal announcement i suppose.

meanwhile the downgrade to the 200 plan, while not as outrageous as github copilot, is just not good pr fwiw. the base number, i.e. what plus users get, is arbitrary as it is, so there was no need to break the appearance of "20x". using the efficiency excuse is not helping here lol. same as further segmentation of pro plans with ultrafast mode.

most people don't understand hybrids i believe, and this video [1] (aptly titled) explains well how they work.

plug-in hybrid don't make sense to me based on the op's experience, but the regular hybrids (where you don't charge the battery) makes perfect sense today, more than ever arguably. same tech as f1 cars fwiw (not that this season they are being very favoured)

[1] https://www.youtube.com/watch?v=KnUFH5GX_fI

a lot of the discourse and mania around this topic reminds of of the movie don't look up.

while not my cup of tea and not going to rewatch it, i see a repeat of a lot of the ways people react to "world-changing" topics.

or in other words, a lot of hand-waving since past few years is only going to be crying wolf when maybe we ever get there. perhaps before nuclear fusion or gta 6!

given the trend, the next airpods pro has to be remarkably different or only 30 usd over the wireless option for the base 5.

we got access to their platform from work. the "best" model, or the one i've used the most so far is GLM-5.2!

for all the promise, i would temper my expectations for a frontier model for coding or general purpose. but for niche use cases (document parsing, voice*, etc.) and as a platform to handle finetuned versions, etc. for small-ish pilots, i can see the value of partnering with them.

if the core model could be any open-weights solution out there, the moat dissolves really quickly.

As a free user for several years, the MCP integration was exactly something I was looking forward to for getting a rough cut!

Sadly, things are not quite as straightforward for non-Studio. For one, you need to be a paying customer to get access to the new feature. Moreover, a community-based solution [1], which previously worked for all users, have now artificial limitation in implementing automation for Free users.

Quite a shame really but maybe it will trickle down over time (like expanding export resolution support). Regardless, a much more open implementation than Adobe, who'd like you to pay for yet another chat window.

[1] https://github.com/samuelgursky/davinci-resolve-mcp#free-edi...

maybe my brain is fried when the first thing i think of is "show bobs"

the language's main repo [1] has been archived since feb this year.

i wonder when the migration was started and whether it made sense to not migrate it to another framework instead.

[1] https://github.com/stackless-dev/stackless

nebula is nice, and a lot of its founding creators are on my sub list.

however, a lot of creators in it had direct ownership. i wonder how it works for those who joined later on and may not share the same.

one of the creators used to be super-active, however now switched the style of videos (completely fine and up to the creator), but now it has gone to radio silence for a better part of a year.

maybe the current creator economy is so bad that once you can get a gig like nebula, it pays you enough to stop the treadmill of churning out content.

it happens to be a title well-known but also natively supported. for a wide sea of games and their hostility towards open standards such as vulkan, we get a handful of games supported in their platform through partnerships. in the end of the day don't hold your breath for their involvement unless the game publisher does all the work.

very ironic but easily explainable. as they sell their own integrated platform now, with server rack partners behaving like graphics cards oems now.

to be able to maximize customized solutions, they would like to own the entire stack which is not already commodified. the cpu remains the only final frontier in this.

there are always side-effects possible, but i wonder if all these efforts can be applied outside of ai ever.

convenient how they hide the older generation pricing by default.

the new price is welcome but still 60% more expensive than 5.4 (which is now comparable to 5.6-terra).

i conveniently also leave out the "-pro" tiers, which was comically expensive. but i feel like openai consider them suitably comparable to sol, and it must be them offering a huge bargain.

context: working in tech consulting with non-tech industry partners.

outside of coding scenarios, anthropic is just not quite the best choice for regular folks.

depending on the cloud/office stack used by the company, the userbase is better poised to use the native ai offering than moving to anthropic and connecting everything with them. same goes for third party guys trying to tie it all together.

not to discount them or their features, but beyond small companies or startups, we don't see the same levels of adoptions now nor maybe in the near future.

those asking us to build genai solutions for them also do not choose anthropic first over the main model offered by their current CSP. anthropic made itself available across the board finally, but it was already too late for most projects planned out for the upcoming quarters. also, we don't use the absolute biggest model nor instantly migrate to the latest one. the insane price jumps do not help with the same. especially when we quote something that may no longer be true down the line.

aside: good luck to the FDE folks hired by the frontier labs. i wonder if they would really get to handle large company-wide projects in practice.

good writeup. a similar approached once saved my bacon when my laptop got bricked during the covid supply chain fiasco.

the programmer, especially with crocodile clips, can be used for other laptops with bios chips of the size. however, it is always nice to have info from someone else who has previously done this. while it took a lot of digging for the specific laptop i had, at least with framework we hope to see more high-quality writeup like this.

the memory kit i bought earlier this year has been within ~10% of the price for the past 8 months. do with that as you may. a simple ddr5 stick of 6000 mt/s cl30 if wondering.

ever since i had my own money, gpu or general hardware had some excuse to fleece us. however, with ram the blatant collusion throughout history does not invite confidence.

this looks as dramatic as it does because the recent trend happened right after a major crash in prices. throughout the years, the usual price for an 8gb stick would hover around 50-80 usd (albeit laptop one, might be lower for desktop). ddr5 also started being 50-100% more expensive than the incumbent when it first dropped. it took a better part of a year to be in a similar price bracket as ddr4.

all this to say, this situation sucks but those of us with 64+ gigs, bought during the last crash, are eating good but got used to using much more memory than they really need.

while it is insane to pay a decent cpu price for 16 gigs today, getting a "good enough" computer still makes more economic sense than a max plan from a frontier lab.

it is nice to see continued enthusiasm for kernel programming and optimization. however, it would be nice if they have more eyeballs at the rocm side of things. gpu mode does have some challenges for amd's platform, but it seems sparse in comparison.

> Who even uses Facebook in 2026? Instagram I get it, but Facebook?

i don't think non-fb apps are only running the meta's ad revenue, which is meant to overtake google's.

while i personally don't use it, does not mean they are not getting enough eyeballs.

since the leadership change, youtube has been on a similar crusade against adblocking. however, despite all the things that happened, ublock, even in the lite version, is able to work on the website. this has been quite well-covered and even discussed here.

however, found it interesting that fb was able to quietly win the battle. however, it is a shame that nothing can be done on the mobile front, at least inside the apps. it is insane how sometimes every other thing you see is a sponsored post or an ad.

in one of the labs i worked for, this idea was put to the test by using an encoder to compress sensor data streamed inside an automotive system. while a niche use case, we were able to successfully do it and in a reliable, self-contained system.

we are blessed to be in an arbitrary field where we are free to steal ideas from other disciplines and find new innovations in our own.

while this approach gives much more insights on the various requests made, if you are mainly interested in the underlying harness and its moving parts, there is already an in-built feature.

to use it, open the meatballs menu (...) of your current copilot conversation and click "show agent debug logs". it opens a tab showing all the various tool calls and prompts being sent out behind the scenes and how model selection is happening (if auto). it also gives insights on token consumption as well. moreover, vscode has been quietly shipping updates and recently you can connect your own otel service to get this information in a way you can put to use yourself.

while copilot has turned me off post their pricing changes, they have been doing tons at their own pace. highly recommend going through this feature if you find the op interesting.

(let's keep in on the downlow)

time for another approach to run your agent's web searches through this (or by mocking browser signature), with potential cf bypass built-in!

given their specs [1] show ~100 mm^2 of silicon for each billion params (albeit in 6 nm process), what will come first: nuclear fusion or one of these that can handle the multi-trillon param models of today?

[1] https://taalas.com/products/

nice to see more initiatives to improve vcs in the current chaos and paradigm change.

simultaneously, i find it curious that the ide's git integration feels incomplete in front of vs code and its forks.

git is not perfect but for a lot of users, a better ux can help solve most of their grievances. regardless, network effect exists and it would take more than a killer app/site to get this going.

i would not outright dismiss this attempt, just like svn guys may have treated git back in the day.

i feel that the proposed approach is close to becoming "demo prawn"* territory.

similar to cpu benchmarks (e.g. geekbench, which also had a recent update), the goal is to distinguish model in some arbitrary thing. however, it is not quantifiable but subjectively even the latest show distinctive differences regardless.

large context window is still relatively new and not "feasible" even commercially, so making that a requirement for a benchmark would not make it accessible especially for open-source ones.

* yes, i misspelled it intentionally