Подскажите, хватит ли 16 ГБ ОЗУ или лучше брать 24 ГБ?

Если по хорошему, то для эффективной работы нужно от 128Гб ОЗУ.

зависит от весов

как мобильный терминал ябллы рулят

как стационарный - очевидно лучше брать какой десктопо/сервер не от ябла - хотя если есть что-то ёще более серьёзное их студии вроде тож вполне норм

если же ужиматся в бюджет - то очевидно макбуг ненужное ненужно

мне просто думается, что для кодинга вряд ли. ?

Локальный квен-кодер вполне нормально работает и кодит. Небыстро, но терпимо.

Ну, в pandas комфортнее же.

А можно поднять кликхаус в контейнере!

. Высокая частота памяти в макакбуках ничего не дает против полноценной DDR5 на 8000 Мгц.

Да плевать на частоту, в маках каналы памяти важнее

Терминал связанный с облаком не требует яблы. Он и так будет работать. Тут все выглядит как попытка усидеть на якобы стабильной оси. Если редакторам видео там программ насыпали, то программистам чем такое ближе я не понимаю. Это просто ARM процессор прибитый гвоздями к закрытой оси. Настоящие программисты знают как оптимизировать код и скорее выберут Gentoo и в любом случае их x86-й ноутбук станет быстрее. А вебмакакам конечно предпочтительнее будет иметь магбук. Дорогие понты и не более того. Комп может очень сильно превосходить ноутбук. И если кто-то хочет за ноутбуки много денег поупка ПК не относится к категории ужимания в бюджет когда оперативная память стоит денег. Просто у одних программистов есть мозги, а другие всеми силами ищут поводы потратиться на макбук.

яблы это бизнес ноуты тока с рюшечками для конченых кастомеров

just it

Локальный квен-кодер вполне нормально работает и кодит. Небыстро, но терпимо.

Любопытно, спасибо. Надо попробовать.

брать 128 mini pc локально поставить qwen и балдеть..

подразумевал duckdb.select from pandas|polars df ибо апи у пандас тот ещё сок мозга на фоне уже за полвека отполированного sql да и декларативность в целом у последнеего более эффективней векторизуется и по памяти что и причина сего топика

а ваще(ТСу) у макбуков латенси их nvme не так сильней отличаются от ram чем в целом по палате :)

MacBook

Для разработки не годен. Если только чисто под маки софт писать. Для разработки (кто бы что не кукарекал в этих интернетах) варианта только 2: пишешь десктоп берёшь Windows и Visual Studio (та которая не Code, а полноценная IDE от Microsoft), пишешь веб/консольку/линуксячий софт с претензией на кроссплатформенность (именно что с претензией, он всегда будет инороден в оффтопиках и маках, а ещё в любой более-менее серьёзной софтине, если она не на Java придётся писать платформозависимые костылики, да даже на Java может придётся) можешь брать Linux, фигни на ровном месте там будет меньше чем в маках, заодно и тестировать будешь сразу в той ОС, где оно будет на проде/у ЦА крутиться.

По поводу ОЗУ на разработку: всё зависит от того что ты собираешься разрабатывать. На некоторые виды разработки 128 гигов мало, надо хотя-бы 512 оперативки и пару сотен гигов видеопамяти, готовая машинка до 22 года стоила 20 000 000 рублей. Сейчас, вероятно дороже. На то чтоб сайтики клепать или системный софт писать хватит и 8 гигов, ну или 16 если тормозной Java софт юзать. Если деньги есть, я бы 64 или 32 гига брал сейчас. С запасом, чтоб лет 10 ничего не менять и не трогать.

Смотри, раз у тебя БД, докеры, браузеры, то я думаю что веб. У веба есть такая штука, как сервер. Если ты пишешь софт для богатой компании, то там много-много оперативки будет, они заплатят. А если пишешь для ООО Рога и Копыта или двигло какое форумное, то рассчитывать надо на то, что готовый софт с БД, докером, ОС, движком, редисом и всем остальным должно будет уложиться в 1 или 4 гигабайта.

Я выкинул его и писал на SQL в Postgree. Задачку где у Pandas-а не получалось справиться на 64 гигах оперативки и 10 часах вычислений решил на офисном ПК-моноблоке с 6 гигами оперативки за 20 минут. Ну да, на написание кода ручками ушло вместо 30 минут 2 часа. Такие дела.

Я вас умоляю. Иерархические кластеризации, расстояния левенштайна и всё такое не надо в SQL писать. Это почти brainfuck для таких задач.

16 ГБ ОЗУ хватит, лучше брать 24 ГБ, а ещё лучше 32 ГБ.

ЯМЗ-7511 425 л.с, ЯМЗ-240 битурбо 500+.

Ну а какие варианты? С пандасом мне надо было бы либо 512 гигов оперативки (а где деньги на это брать то, из своего кармана, так они у меня не бездонные, а дырявые)? Потому да, csv в sql, там предобработка с трансформацией данных в нужный вид и дальше полноценная обработка из питона пачками, которые можно разом переварить.

Если деньги есть на мак, бери топовый мак, иначе – деньги на ветер.

Ну а какие варианты?

Ну вот последние годы polars с pyarrow, можно пандас в dask засунуть.

Всё равно, считаю что для трансформации, аналитики и предобработки данных SQL удобнее, если знаешь его. Хотя бы тем, что из того-же питона можно выбирать только то, что интересно/подходит под условия, чем костылить эти же условия на ЯП, которые изначально не были для этого предназначены. SQL конечно тоже не всегда годится (csv бывает и больше лимита у таблиц, например), но это уже другой вопрос.

Эм... Я вот на простом T-SQL с CTE как-то реализовывал линейную регрессию + сезонность для автопланирования по данным продаж. И честно скажу, ну его к бую. Всё хорошо в меру. Теперь я даже итерационное обновление из внешней базы в airflow делаю, а не на хранимках в триггерах (хотя, конечно, на SQL).

Зачем ты это руками делал, ещё и на T-SQL? Бери postgree как все нормальные люди, там есть REGR_SLOPE, REGR_INTERCEPT из коробки. Если у тебя многофакторная регрессия, то да, придётся повозиться, если не хочется велосипеды чужие тыкать. Но вообще, регрессия это уже не трансформация, очистка и предобработка. Тут уже можно и просто select-ом данные вытягивать куда тебе надо.

Бери 32, а лучше 64.

От меня тогда не зависело, что брать.

Сколько бы памяти не было, перечисленная блоатварь гарантированно сожрёт её всю. Так что бери максимум который только может быть на поделиях Apple. Я х.з, выпускают ли эти долбодятлы что-то с 64-128Гб, но если выпускают - бери макбук с 64-128Гб. Столько блоатварь не прям сразу сожрёт, а чуть погодя. Но по-любому в итоге мало окажется.