Здравствуйте, flаt, Вы писали:
F>1. Зачем ставить Linux на голое железо ноутбука, если основная цель — поиграться с С++17? Есть же WSL (в случае Win10) или виртуалки, в конце концов
Насчёт Win10 и WSL:
Всё это (Win10 и WSL) видится мне несколько искусственным.
Насчёт виртуалки — подумаю, может и неплохая идея, спасибо.
Пока работаю на dual-boot.
F>2. Зачем ставить Linux, если основная цель — поиграться с С++17? Есть же GCC (mingw-64, к примеру), Clang
Я в курсе насчёт MinGW — ранее занимался с ним.
Для среды MS Windows — это также искусственная штука, когда есть MSVC-2017.
Для студии — я уже давно разобрался, как компилоровать в ней коды на C++17.
Основные цели и направления — как освоение C++17, так и расширение профессионального кругозора.
Так, если сегодня мне требуется разработка ПО (C++; Qt) для Windows, то завтра — возможно потребуется кроссплатформа и Linux
P.S. Я в курсе, что это всё есть, но я добился — и уже осуществил свою идею — компиляция примеров из книжки: http://rsdn.org/forum/cpp/7122404
Кстати, автор вышеуказанной книги настаивает рекомендует, чтобы читатель применял именно Linux.
К M$ (в плане работы с C++) автор относится достаточно сдержанно.
Здравствуйте, AlexGin, Вы писали:
AG>Всё это (Win10 и WSL) видится мне несколько искусственным.
А что не так? Мне понравилось. Единственное, нельзя в FS напрямую лазать (вернее можно, но чревато), чтобы конфиги, например, поправить, надо какой-нибудь SSH поднимать. А так — они даже фоновые процессы сейчас запилили, в рамках пользовательской сессии.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, AlexGin, Вы писали:
AG>>Всё это (Win10 и WSL) видится мне несколько искусственным. Ops>А что не так? Мне понравилось. Единственное, нельзя в FS напрямую лазать (вернее можно, но чревато), чтобы конфиги, например, поправить, надо какой-нибудь SSH поднимать. А так — они даже фоновые процессы сейчас запилили, в рамках пользовательской сессии.
То есть (я выделил "самый смак") — работаем с Linux, а работь с файлами не можем.
Я верно понял?
Это не просто искусственно, это супер-противоестественно...
Здравствуйте, Ops, Вы писали:
...
Кстати, на том же самом ноуте — я вчера успешно запустил из под WMVare (точнее: WMVare Workstation 12.5.7)
ту версию убунты (16.04), котрая НЕ РАБОТАЕТ на голом железе
В принцыпе, можно было и 18.04-ю запустить таким же образом, но она ИМХО пока весьма сырая
Здравствуйте, AlexGin, Вы писали:
AG> AG>То есть (я выделил "самый смак") — работаем с Linux, а работь с файлами не можем. AG>Я верно понял?
Неверно. Там есть FS "системы", а есть смонтированные виндовые диски. С виндовыми работай как хочешь, а с лялиховой FS только изнутри лялиха, но не виндовыми средствами.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Мне удалось поднять, на WMVare 12.5, UBUNTU 16.04 — на том же самом компе, где эта же 16.04 не работала при установке на голое железо
Конечно, здесь есть и свои недостатки:
1) Проседание производительности, так как одеовременно с нашей ОС, работает одновременно на том же CPU и host ОС.
2) Я не могу даже видеть диски host ОС в нашей убунте.
Но — есть и приятные моменты:
a) Не надо перезагружаться, чтобы перейти в другую ОС.
b) Работает drag & drop с головной host ОС.
Здравствуйте, Ops, Вы писали:
Ops>Неверно. Там есть FS "системы", а есть смонтированные виндовые диски. С виндовыми работай как хочешь, а с лялиховой FS только изнутри лялиха, но не виндовыми средствами.
OK!
Такой вот вопрос:
Если (в моих приложениях для Linux) я буду работать с файлами — в стиле старого-доброго ANSI-C: fopen(); fwrite(); etc...
При этом, буду обращвться только к "своим" ext4 дискам, а НЕ к NTFS дискам.
То в этом случае, теоретически, всё должно везде отлично работать.
Практически, как я понимаю, здесь водятся Драконы...
Здравствуйте, AlexGin, Вы писали:
AG>При этом, буду обращвться только к "своим" ext4 дискам, а НЕ к NTFS дискам.
Это если ты смонтируешь отдельный ext4. "Свой" раздел там на базе NTFS, это обычная папка, но с дополнительными метаданными, из-за которых и не стоит туда лезть напрямую виндовыми программами.
AG>То в этом случае, теоретически, всё должно везде отлично работать. AG>Практически, как я понимаю, здесь водятся Драконы...
Не слышал о таком. Вроде изнутри все работает как надо, проблемы только при записи в корневой раздел минуя подсистему лялиха.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
AG>Мне удалось поднять, на WMVare 12.5, UBUNTU 16.04 — на том же самом компе, где эта же 16.04 не работала при установке на голое железо
Странно что, 16.04 не становится на железо, на которое становится 14.04.
AG>P.S. Также насчёт C++17 — удалось разрешить все проблемы: AG>http://rsdn.org/forum/cpp.applied/7154509.1
Здравствуйте, kdw, Вы писали:
kdw>Странно что, 16.04 не становится на железо, на которое становится 14.04.
Похоже, что авторы убунты попытались обработать какие-либо кейсы современного железа, вроде как где-то работает.
Но здесь получился облом.
Ранее не обрабатывали — и всё проходило.
Вот в таких случаях и понимаешь что в девизе "мелкомягких": "One Microsoft way" есть большая сила...
AG>>P.S. Также насчёт C++17 — удалось разрешить все проблемы: AG>>http://rsdn.org/forum/cpp.applied/7154509.1
kdw>Да, прочитал, только геморно все это.
Это совсем НЕ геморно, а вполне даже просто — если проделать это неоднократно (на рабочем компе, на домашнем, на ноуте).
Ну и никто же не настаивает ставить всегда все пакеты: ограничиться, например, свежими GCC 8 и clang 6.
Или та же утилита CMake — первый раз собрал из исходников и сформировал *.deb пакет. А дальше — ставь его через dpkg -i ...
