Комментарии 70
Имхо здесь не хватает хаба "Я пиарюсь" :) Неплохой путь для восьмиклассника, молодец!
Поставь свои конфига на тот же linux.org.ru там подскажут
Но БАМ, винда на моем Sony дала сбой и исходники Accends ушли вместе с остальными
И в чем проблема достать файлы с лежачей виндой?
Ну а как я понимал, винда была не очень для программирования
По какой причине она "не очень" для программирования по-твоему?
По какой причине она "не очень" для программирования по-твоему?
позволю себе вставить свои 5 копеек и ответить за автора: ну хотя бы из-за отсутствия пакетного менеджера (сторонние вроде chocolatey оставим за скобками), и-за чего всё нужное для раработки (включая и инструменты вроде IDE и зависимости для вашего кода) приходится не просто устанавливать а прям добывать..
а автор молодец, для своего возраста очень хорошо стартанул, однажды доростёт до понимания что arch это не "круто" а как он выражается "кринж", и возможно на хабре появится ещё один хороший разраб/админ/etc с интересными статьями.
Да как бы он имеется. А при чем тут "зависимости для вашего кода" и пакетный менеджер ОС мне не совсем понятно.
мне удобнее пользоваться линухом как основной осью, это поспокойней как-то. я недавно кодил на винде (просто фронт надо было писать и стоял дуалбут) и я скажу винда 11 очень хороша для программиста, который пишет Frontend, Backend на python, js. Ну а так как я учу Rust (для написания Software и Backend) мне требуются CLI инструменты. А на винде с ними небольшая беда. Да и норм пакетного менеджера (кроме winget, косячный, но работает) на винде нет (scoop, choco я пробовал, не пишите). Я просто выбрал Linux
И какая беда с CLI инструментами?
Они не являются "first-class citizen", грубо говоря. Да, можно сказать что powershell это даже мощнее чем bash. Но это совершенно другой порог входа, и он все равно "несколько сбоку". Открываешь случайный гитхаб репозиторий, и там будут инструкции для linux/macos. Опытный разработчик может разобраться что с этим делать если у него Windows. Помимо WSL можно поставить и mingw bash какой-нибудь. Но просто в Linux это удобнее, большинство приложений кроме декстопных под windows скорее всего будут работать на linux сервере, есть огромное количество легко доступных инструментов для дебага, которые отлично интегрируются. Одной командой можно запустить strace и что-нибудь грепнуть. Как бы странно это не звучало linux куда более "user friendly" в плане разработки, и если новичок не имеет цели программировать windows приложения, то зачем все это дополнительные сложности? Открываешь репозиторий, копируешь команду с установкой пакетов - готово. Под windows это надо будет разобраться как все это добро поставить, потом что делать с тем что make файл не очень кросплатформенный оказался и т.д. Когда речь про разработку - старый мем про "троллейбус из буханки хлеба" это скорее про windows.
Когда речь про разработку - старый мем про "троллейбус из буханки хлеба" это скорее про windows.
а это не только про разработку, это в целом так во всём.. просто понимание этого приходит не ко всем.
Один лишь принцип обмена данными между CLI командами (тупо текст) - это уже провал.
Линукс удобнее в плане разработки только тем, что действительно зачастую готовую команду готовят только под Линукс, не более.
И да, большАя часть веба крутится в Линукс и следовательно разумнее использовать целевую платформу для разработки. Только мир разработки не только вебом полон.
я говорю, мне удобно пользоваться линуксом как основной ОС. Если надо что-то настроить, зашел в конфиг, поменял, и рестартанул (или сбилдил и рестартанул)
Любая вещь становится удобнее, когда начинаешь в ней разбираться. Винда изначально удобна для новичка и становится более удобной, если начать разбираться в том, как она работает
А расскажите как она работает? ну там за пределом папок, файлов и путей в PATH. (все тоже самое, что есть в любой ОС) Потому что минимальное копание дальше приводит к: реестру, COM интерфейсам и бинарникам/библиотекам о которых практически ничего не известно, если это конечно ни какая-то распространенная библиотека с официальной документацией. Это мы даже еще не спустились на уровень ядра и драйверов.
Как минимум наличие широкого API отличает эти семейства ОС
Не то чтобы я докапываюсь, мне действительно интересно. Но что такое "широкое API" ?
Наличие «широкого API» это огромный минус Windows. Это же API, а куча наслоений API из разных эпох. Стоит просто сравнить с тем, что предоставляется разработчику на MacOS или Android. Если вы на какое-то Windows API завяжетесь, то станете привязаны к Windows, а сейчас принято писать кроссплатформенные программы. Windows набивают разными библиотеками, а C++ runtime там вечно отстаёт от реальности и программы должны носить его с собой.
То же будет если вы завяжетесь на апи Мака или Андроид. Вы будете привязаны к этим платформам.
И при чем тут плюсовые библиотеки, которые идут как бы при установке не понятно. Во-первых, они не всем нужны, а во-вторых, достаточно считать, что их в системе нет. Никто не принуждает их использовать.
И у винды есть разные уровни апи, как новые, так и старые. При этом старые не меняют, что позволяет использовать достаточно старый софт без проблем.
Про MacOS и Android это был пример более стройного и однородного API. Понятно, что невозможно написать приложение без привязки к системе невозможно. Но только на WinAPI никто GUI-приложения не пишет. Это либо было MFC (которое умерло при первой возможности, когда стало возможным перейти на .NET), либо популярные разработки от Borland (библиотеки которых реализованы в стиле борьбы с трудностями WinAPI, то есть предоставляющие разработчикам то, что быть получено штатными средствами системы).
И как хорошо, что плюсовые библиотеки не всем нужны. Оказывается, уже можно не писать на C++. Достаточно .NET и требовать всего лишь обновления .NET Framework до 4.8.x, чтобы ваша программа запустилась.
В общем, стремление предоставить в API все сервисы (включая формирование электронных писем) это не для удобства программиста, это для того, чтобы привязать пользователей и разработчиков к своей системе. Привязать в плохом смысле. Десятилетия для Windows использование сторонних библиотек было проблемой — их откуда-то качали, куда-то клали, чтобы обеспечить собираемость проекта.
И сначала с помощью IE развитие web'а было задержано на многие годы («наш сайт должен открываться в IE), а теперь посмотрите, много ли программ продолжают использовать mshtml для отображения HTML-контента. Нет, сейчас всем проще подключить webkit или что-то подобное.
Я уж молчу, что в системе с нормальным API (на самом деле ABI) не устроили бы такой мощный DLL Hell, с которым пришлось бороться дополнительными ужасными и бессмысленными способами.
Ну вы тут ошибаетесь. Во-первых, WinAPI предоставляет возможность создавать нативное API равно как и Android, а не принуждает. И равно как и Android или Linux или Mac позволяет создавать и не нативные GUI. При этом, основное API по управлению окнами остается.
Тот же Borland (а сейчас и давно уже не он, а Embarcadero) позволяет создавать кроссплатформенные приложения и под Win и под Linux и под Android и под Mac. Одним кодом и без внешних зависимостей.
То что в Винде быстро и удобно можно использовать нативный GUI - это не проблема, а дополнительная возможность. И он как раз не зависит от сишных устаревающих библиотек или дотнета. Дотнет - лишь обертка над нативным и не нативным GUI (если речь сейчас о GUI).
И нет никакого строго и однородного API в Маке и Андроид. Там меняется многое как и в винде. Разные версии апи. У андроида так каждый код новое апи, которое урезает или меняет функционал. При работе с API Android в сравнении с API Windows - я вообще не нашёл разницы. Те же проблемы. Точно такие же. Местами проверки на версию ОС, чтоб использовать то или иное API. Рантайм библиотеки так же цепляешь рядом, чтоб были. Разницы вообще никакой. Только философия разная.
И никогда не было проблем в Windows со сторонними библиотеками. Если программа их требует - это задача разработчика обеспечить, чтоб они были там, где их программ будет искать. Собственным API ОС обеспечивает и гарантирует обратную совместимость. А сторонние библиотеки - это головная боль разработчиков (кроме разработчиков Delphi)
Не очень понял, в чём я ошибаюсь.
WinAPI к ненативным GUI не имеет отношения, потому что они делаются вопреки (или же перпендикулярно) механизмам, предоставляемым WinAPI.
Ну вот я привожу Borland в пример, как явление, позволившее обеспечить масовую разработку софта для Windows, без ужасов WinAPI, а вы мне его же приводите в пример про кроссплатформенные приложения. Достоинства решений Borland лишь подчёркивают нищету WinAPI, а не являются следствием полезности WinAPI. И то, что там смогли сделать кроссплатформенность, к WinAPI никакого отношения не имеет.
В Винде нельзя быстро и удобно использовать нативный GUI. Это не быстро и не удобно. А .NET далеко не обёртка, слишком многое там сделано внутри, без перехода на unsafe code.
Вы вот вроде как утверждаете, что нет однородного API в Маке и Андроид, что там «меняется многое, как и в винде. Разные версии апи». Оно там меняется и есть разные версии апи. В WInAPI никаких версий API нет. Вы бы видели эти функции WinAPI, у которых порядок аргументов зависит от версии Windows.
Ещё раз, сравнивая с Андроид, где у вас есть возможность собираться с апи разных версий: в Windows ваше приложение обречено на линковку с ABI неизвестных версий, и это ключевая разница.
Про то, что «никогда не было проблем в Windows со сторонними библиотеками», не то, что бы это враньё, но не могу согласиться. Microsoft всегда вела себя так, как будто таких библиотек не существует. И да, вы верно заметили, устроила так, что эти библиотеки — головная боль разработчиков. А хотелось бы без головной боли. Например, vcpkg или что-то подобное.
В WInAPI никаких версий API нет
Эм. А что, версии API в Android не от версии Android зависит? У этих платформ одинаково API. Да и у всех.
Я знаю как может меняться WinAPI от версии к версии. Но только точно не может быть так, что внезапно изменили порядок передачи аргументов. Там всегда дублируют функцию.
Епрст. При разработке Андроид ты будешь точно так же проверять версию Андроид, чтоб вызвать ту или иную часть апи. Как и на Винде будешь проверять версию Винды.
Это пол беды, а потом может оказаться что под разные дистрибутивы команда будет выглядеть иначе. Но это скорее про инфрастуктурные/системные команды
А при чем тут "зависимости для вашего кода" и пакетный менеджер ОС мне не совсем понятно.
Я думаю, имелась в виду возможность использовать при разработке библиотеки установленные в систему. `apt|rpm|pkg|... install opencv ffmpeg curl boost qt6`, и всё - можно собирать код использующий эти библиотеки.
Но это не библиотеки для кода. Это рантайм библиотеки
Это зависит от репозитория. Где-то они не разделяются, где-то нужно добавить -devel суффиксы.
Ну тогда это не очень удобно, когда возможность сборки твоего проекта внезапно зависит от внешнего пакетного менеджера, а не от менеджера пакетов IDE или экосистемы языка.
Это только от безысходности, когда системного пакетного менеджера нет. А когда он есть и из него ставятся и система, и приложения, и инструменты, и библиотеки всех языков сразу (что особенно важно в местах их пересечения, например питоновских биндингов к плюсовым библиотекам), нет никакого смысла иметь ещё один, ограниченный и вдобавок привязанный к какой-то IDE, когда у меня, во-вторых, другая IDE, а во-первых, IDE для сборки вообще не нужна. Сборка это `git clone && cmake|meson && ninja` плюс упомянутая установка зависимостей.
Разверните, пожалуйста, свою мысль насчет пакетного менеджера и библиотек, иначе она пока выглядит как то, что не соответствует действительности.
По своему опыту могу сказать следующее:
Если взять, например, языки javascript, python, ruby, то тут как в других ОС: устанавливаешь интерпретатор и сопутствующий инструментарий (что в Windows не сложней, чем в Linux) и разницы в нахождении и установке библиотек нет (скорей всего, за редкими исключениями, которых я не знаю).
Для C/C++ есть vcpkg (который доступен и для других ОС). Пакетные менеджеры для Go, Rust так же работают как и в Linux.
всё просто, в системе должен быть только один метод поставки софта и его зависимостей, когда в системе появляется их несколько система превращается в неуправляемую помойку как винда.
устанавливаешь интерпретатор
выполняя лишние действия вроде скачивания, проверки чексумм и запуска инсталлера оного, хотя этим должен заниматься ПМ
и разницы в нахождении и установке библиотек нет
Для C/C++ есть vcpkg (который доступен и для других ОС). Пакетные менеджеры для Go, Rust так же работают как и в Linux.
и вот он камень предткновения, вместо одного общесистемного ПМ мы имеем зоопарк решений разной степени всратости
@HemulGMэто кстати и для вас ответ
Ну это вздор. Во-первых в Линукс системах у каждого несколько разных пакетных менеджеров. Во-вторых нет никаких ограничений поставить софт как попало из собственно инсталлятора. Всё в точности как на винде. В Лине такой же зоопарк с установкой. Разные пакетные менеджеры, разные принципы пакетов и т.д.
Интерпретатор питона в винде ставится одной строкой через тот же пакетный менеджер. Вдобавок ко всему, VS Code или PyCharm ставит его самостоятельно. А сами IDE ставятся одной строкой из пакетного менеджера или парой кликов и магазина.
Во-первых в Линукс системах у каждого несколько разных пакетных менеджеров.
не у каждого, только у тех кто любит замусорить систему
Во-вторых нет никаких ограничений поставить софт как попало из собственно инсталлятора.
есть огромная разница между возможностью и необходимостью
Интерпретатор питона в винде ставится одной строкой через тот же пакетный менеджер.
Нету в винде родного ПМ (а сторонние роли не играют, мы же тут про ОС говорим а не про сторонний софт для этой ОС, но даже если мы будем учитывать какой нибудь chocolatey он всё равно не станет в винде единым способом поставки ПО, всегда останется центр обновлений винды, самообновляторы самого ПО и прочий ненужный мусор)
VS Code или PyCharm ставит его самостоятельно
и это их персональный недостаток так же не имеющий отношения к треду
и вторая проблема - среди win юзверей нет привычки пользоваться нормальными методами, на одной тачке создаётся мешанина.
Первые два ответа относятся и к винде. В том же виде. Без исключений.
Нету в винде родного ПМ
Почитайте что такое winget
И что за нормальные методы? Вы их сами для себя определили? Не слишком ли высокомерно? Тем более всех под одну гребенку.
winget может стать единым методом поставки ПО на винде? нет? кто бы сомневался..
Эм. Это такой же способ поставки ПО как и в Линукс. Повторяю, в линукс также есть другие способы, такие как Магазин или установка вручную с сайта. Вдобавок менеджеры пактов есть разные, есть разные способы упаковки пакетов (например flatpak), разные источники/репозитории в самих менеджерах и т.д. Там бардак местами больше, чем на винде. И всё это около-официально.
Повторяю для тех кто читает через строку: есть огромная разница между возможностью и необходимостью
спасибо большое за мнение. просто я начал изучать компьютер с ранних лет. Arch довольно хороший дистрибутив, но его расфорсили (как например ubuntu, debian) я им пользуюсь и мне это нравится. скорее всего, через некоторое время попробую Void Linux или Gentoo, но сейчас занимаюсь разработкой, и времени менять что либо нет. спасибо!
винда упала вместе со всеми файлами.
Ну сейчас, как юзер Arch Linux, могу сказать что мне намного удобнее сидень на линуксе, чем на винде 10
Что значит "упала вместе со всеми файлами"?
Как вариант, запоролась таблица разделов или $MFT, или просто диск перестал читаться, для неопытного человека это непреодолимая проблема в любом случае.
Ну так тогда проблема тут не в винде, винда упала по этой же причине. Ну а восстановить файлы не сложно даже подручными средствами и доступом в интернет
наверно это и произошло. винда не запускалась вообще, кидало в биос
Ну так помер жесткий диск. Данные на нем по большей части сохранились (на тот момент). Достаточно было подключить диск к рабочему компьютеру и забрать всё что нужно
ну извините, мне было 11
но все равно, спасибо за прочтение статьи. это первый опыт написания статей
Ну так для этого нужен во-первых другой комп, во-вторых некая утилита низкоуровневого доступа к диску, в-третьих если вдруг там был SSD и он накрылся из-за потери сервисной информации, и это не поможет. Здесь по двум словам 11-летнего ребенка, далекого от эникейства, точный диагноз нельзя поставить. А @DirtyHornet на наглядном примере узнал, что бывает, если вовремя не делать бэкапы, всё польза.
Меня больше удивило почему исходники не в гитхабе или гитлабе?
Не пинайте пионэра, все так начинали, так что верной дорогой идете дорогой товарищ!
По делу - не ограничивай себя Python, или вообще просто языками программирования. ЯП это всего лишь "довесок" к твоим знаниям в какой-либо области - будь то алгоритмы параллельных вычислений, UX, графика или что-то еще.
По сути - то, что Linux в среднем лучше для разработки - соглашусь, потому что большинство server-side работает на Линуксе, и под тот же Android удобнее разрабатывать если у тебя есть "нативная" консоль. Однако для очень многих задач WSL2 вполне адекватен.
Как сказал @vesper-bot: не хватает хаба "Я пиарюсь", а если по существу то молодец, желаю успехов в развитии и в будущей работе :)
Хехе, рад за автора, немного обидно..хотя скорее стыдно, что автор на два года младше, а похож на мидла минимум, успехов)
Очень круто ?) У меня кстати у мамы зенбук, очень крутой ноут, мне все асусы нравятся. А я вот в линуксе дальше "поставить убунту на ВМ, поставить минт на ВМ, поставить убунту на рил ноут и понять что это далеко не айс"... И всё. В программировании почти не умею, немного HTML/CSS/JS. Так что ты крутой
Мне 14 лет, в июле будет 15
Молодец. Как раз таких статей не хватает. Т.е как можно с детства войти в ит и как мотивировать . У меня сын 1ый класс закончил, я уже в середине первого собирал вместе его будущий комп. Пока в игры играет, надо как-то теперь его вовлечь чтобы он копался глубже чем просто игры
Как я вникал в Linux с 4 класса? Все по полочкам