unDE 0.2.0 — необычная командная строка и панель клавиш

Не чем?

Нет, там автор ничего так и не показал. А тут имеется рабочий прототип с исходниками, есть на что посмотреть.

Неплохо, неплохо. Проголосую за полное управление с клавиатуры, в том смысле что мышь тоже можно использовать, но не обязательно.

Чем это вам личкрафты не угодили? Вполне себе годный комбайн. Я им кажный день пользуюсь для чтения новостей, чятиков и прочей фигни. Пока что жив.

Более правильное название проэкта будет: unDEad

А управления с клавиатуры до сих пор нет…

Мыши — зло, и с ними надо бороться!

автору - запастись терпением
и успехов !

Плохо, что нет музыки. Восьмибитный дабстепчик был бы аутентичен...

Вам с дедфудом объединиться

Посмотрел скриншоты. Что за ад?

DawnCaster> Ват ? Когда Лёня и это успел ? Это ведь шутка, так ? Или я что-то пропустил в своей уютной криокамере ?

Он про gummiboot.

DawnCaster> Если-бы он был написан на D - совсем другой разговор-бы был.

В критике мелькало бы не «systemd», а «system-D».

devzero> Ждём systemd-motherboard и systemd-CPU

Лучше сразу проприетарный systemd-kerneld, и пусть сваливает из мира линукса.

Но я не представляю ситуации, чтобы надо было выбрать по именам 1000 файлов и все они такие разные, чтобы ни find'а не применить, ни шаблонов..

ты в саппорте видать не работал, с секретарями не общался...

Посмотрел скриншоты. Что за ад?

Посмотри видео. Ад получается из-за того, что полупрозрачный терминал накладывается на основной гуй. Если его так можно называть. А по сути ничего страшного там нет.

А по сути ничего страшного там нет.

Ну да, человек ко всему привыкает.

Уникальная способность луноходов объяснять так, чтобы небыло понятно. Точнее, отсутствие этой способности.

Бесполезная игрушка, в сочетании с некомпетентностью автора в UI, юзабилити и Unix way. Я сомневаюсь, что это поделие обгонит по юзабельности и скорости хорошо настроенную типовую среду (vim + netrw + ctrlp или emacs + evil + dired-plus + icicles/helm + bookmark-plus + настроенное автодополнение).

Это какой-то уникальный клинический случай. Судя по беглому просмотру проекта, в жизни автора произошло даже не одно, а несколько событий, которые даже поодиночке обычно вставляют человеку мозги на место и предотвращают от занятий хернёй в разработке ПО и в подходе к личному инструментарию:

- Юниксы/Linux

- Vim

- Работа разработчиком в течение как минимум нескольких лет

- Чтение книг по юзабилити (Раскин и т.д.)

- Семья, дети

Тем не менее ни одно из них не сработало. Я вообще не представляю, как ещё адекватно объяснить, что так делать не надо.

круто, но, думаю поворуют как только интересные вещи обретут б.м. законченный вид.

хорошо настроенную типовую среду (vim + netrw + ctrlp или emacs + evil + dired-plus + icicles/helm + bookmark-plus + настроенное автодополнение).

Жизнь не заканчивается программированием, Алё!

Проголосую за полное управление с клавиатуры, в том смысле что мышь тоже можно использовать, но не обязательно.

Удвою этого анонимуса.

Ну это одна из сторон жизни опенсорса, да.

Ставь dmd с dlang.org

$ wget -c http://nightlies.dlang.org/dmd-nightly/dmd.master.linux.tar.xz
$ tar Jxf dmd.master.linux.tar.xz
# apt-get install libdb5.1-dev
$ cd unde-code
$ export PATH=../dmd2/linux/bin64/:$PATH
$ make
...
Performing "debug" build using dmd for x86_64.
bdb2d 5.3.28: target for configuration "library" is up to date.
derelict-util 2.0.6: target for configuration "library" is up to date.
derelict-ft 1.1.3: target for configuration "library" is up to date.
derelict-sdl2 1.9.7: target for configuration "library" is up to date.
unde 0.2.0+commit.1.gca50394: building configuration "default"...
Linking...
To force a rebuild of up-to-date targets, run again with --force.

unde-code$ ls -l unde 
-rwxr-xr-x 2 lk staff 22045861 Янв 31 17:52 unde

unde-code$ ./unde 
Open Database. If it takes long, try `./unde --force_recover`
Ошибка сегментирования

$ ./unde --force_recover
Open Database. Recover mode enabled. Please wait...
Ошибка сегментирования

libdb 5.3 должно быть, скорее всего из-за неё. Но иногда из-за openGL падает. Подробнее bt в gdb тебе ответит.

Колоться от этого он, правда, не перестанет

libdb 5.3 должно быть, скорее всего из-за неё

Может perror будешь кидать?

Но иногда из-за openGL падает

GL нативный из Debian stable (NVIDIA), тут траблы быть не должно.

Может perror будешь кидать?

Не понял, поясни, причём здесь seg.fault и perror?

Не понял, поясни, причём здесь perror?

Ну, можно проверять на NULL перед free(...) и т.п. Типа, вместо корки, просто выдавать ошибку.

В таком случае вообще-то все уже проверено. Просто из-за того что библиотека другая данные попадают совсем не в ту функцию которую должны попадать и интерпретируются совсем не так как мы ожидали.

Я не могу это контролировать.

Занятная вещь. Помнится, я давненько читал и видел пару скринов. Когда появилась первая рабочая версия со скриншотами?

Работать будет только в линуксе?

Хотел было попробовать но:

farex@home:~$ unde 
Open Database. If it takes long, try `./unde --force_recover`
Clean logs.
Database opened.
~/.unde/mime NOT FOUND
Example of line "text/plain = gvim"
Go Mark 1
Desktop 1 created
lc_messages=C
lc_messages=ru_RU.UTF-8
FPS= 0.000000, average draw time: -nan ms

core.exception.RangeError@source/unde/path_mnt.d(120): Range violation
----------------
??:? _d_arraybounds [0x6bf39f]
??:? unde.path_mnt.__array [0x684aff]
??:? immutable(char)[] unde.path_mnt.PathMnt.get_key(const(unde.lsblk.LsblkInfo[immutable(char)[]])) [0x6841b6]
??:? unde.file_manager.find_path.unDE_Path_Finder_Flags unde.file_manager.find_path.find_path(unde.global_state.GlobalState, berkeleydb.dbtxn.DbTxn, unde.lib.CoordinatesPlusScale, unde.path_mnt.PathMnt, unde.lib.DRect, unde.lib.SortType, const(int)) [0x5e3b7b]
??:? void unde.draw.draw_screen(unde.global_state.GlobalState, berkeleydb.dbtxn.DbTxn) [0x5d3d1f]
??:? _Dmain [0x6813ae]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x6c41b2]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x6c40fc]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x6c416e]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x6c40fc]
??:? _d_run_main [0x6c406d]
??:? main [0x68157f]
??:? __libc_start_main [0x8c0e182f]

Первая версия со скриншотами появилась в середине декабря.

Что за система?

Ни разу не ловил подобного на старте.

lsblk покажи.

куда смотрит Линус, руководство RH и прочие

ну сам подумай, куда им до тебя? ты и все их юзкейсы уже решил, и на безопасном баше всё переписал, осталось только всех клиентов RH переманить - и мы в шоколаде.

В windows работает все кроме консоли (только внутренние команды). Это починить тоже можно, но я пока не осилил.

Ubuntu server + i3wm

farex@home:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial
farex@home:~$ 

Вы в своём сарказме все такие остроумные, шо прям пипец.

А между тем, во времена когда мониторы были выпуклые а иниты были на башах, в них почему-то не находили регулярно уязвимости одну эпичнее другой... Да и, кстати, работало это всё более чем сносно на 32-64 метрах ОЗУ так что systemd в этом плане совершенно ничего не оптимизировал.

А между тем, компании вполне могут принимать неверные стратегические решения. Примеров только за последние лет 10 набралось уже огромное множество. Вы можете шутить и кукарекать дальше, но я считаю, что проекты вроде systemd - при всех обстоятельствах и вызовах нашего времени нельзя писать на C - слишком много потенциальных возможностей накосячить, слишком много кода, слишком сложно всё это поддерживать будет. ИМХО, уж лучше и правда на баше делать.

Отличный пост. Пользоваться я, если серьезно, не буду, но как арт-инсталляция очень понравилось самобытностью. Повеяло BBS, Фидо, ранним Вэбом и прочим аутизмом (в хорошем смысле слова).

Ага, вот тогда-то я и видел, значит. Потому что помню скриншоты - специфичные, такое не забывается.

Ах вот оно в чём всё дело! А /-то, / у вас на каком устройстве?

Он горюет от того, что lsblk ему не показал слеша..

Да, блин завязку на lsblk надо явно переделывать...

Ах вот оно в чём всё дело! А /-то, / у вас на каком устройстве?

sdd5

Вы в своём сарказме все такие остроумные, шо прям пипец.

А как ещё на это реагировать?

в них почему-то не находили регулярно уязвимости одну эпичнее другой

Вы не находили? Или кто? В моём мире вот находили людей, пользовавшихся pkill для остановки сервисов. А нормально pid-файл создать вообще могли через раз. Вообще, как только копи-паста из соседнего сервиса не помогала - хоть вой.

проекты вроде systemd - при всех обстоятельствах и вызовах нашего времени нельзя писать на C

Поддерживаю, вот только C++ не лучше, а Rust пока сырой. Всё остальное предлагать - даже не смешно. Ну Go может быть, но хрен его знает.

ИМХО, уж лучше и правда на баше делать.

Нет, серьёзно? Вы на нём что-нибудь больше двух команд писали? У нас тут есть средних размеров проект на баше, я ещё не видел большего глюкодрома. Ну и классика с rm -rf /usr/$VARNAME ещё вспоминается? У нас похожее было, только удалялось всё из ~/.ssh на хосте (а должно было в chroot).

Нафиг-нафиг. Лучше вас они знают, что делать.

А mount что показывает?

Нет, серьёзно? Вы на нём что-нибудь больше двух команд писали?

Писал. Намного больше двух команд. Проблемы в баше, разумеется есть. Для того чтобы нормально писать на баше нужно как-то по минимуму понимать основы программирования (внезапно, да?).

я ещё не видел большего глюкодрома.

Если руки из жопы, а точнее квалификация «программистов» низкая, то на любом языке вы получите глюкодром. Нужно просто уметь правильно применять разные инструменты для разных задач. Сложные системные и высокопроизводительные задачи - C и C++, всякая автоматизация - баш. Я в целом, не против единого стандартизированного системного менеджера. Я против того чтобы делать такие гигантские проекты на чистом C, вот и все. Слишком высока вероятность ошибиться и получить уязвимость покруче любой уязвимости на баше.

Нафиг-нафиг. Лучше вас они знают, что делать.

Конечно лучше. А ещё бытует мнение что большинство не может ошибаться...

Для того чтобы нормально писать на баше нужно как-то по минимуму понимать основы программирования (внезапно, да?).

Угу, и знать все приколы баша. И желательно отлаживать одним взглядом. Или хотя бы знать, как сделать ошибки фатальными во всем скрипте, а не только где вспомнили на них проверять.

Если руки из жопы, а точнее квалификация «программистов» низкая

И таких программистов будет сильно больше нуля на любом реальном проекте. Простой жизненный факт. Никто не будет нанимать гениев писать скрипты инициализации на баше.

Слишком высока вероятность ошибиться и получить уязвимость покруче любой уязвимости на баше.

«Если руки из жопы, а точнее квалификация «программистов» низкая» (c) DawnCaster ;)

А ещё бытует мнение что большинство не может ошибаться...

Есть мнение, и не только моё, что специалисты в некоторой области ошибаются в ней реже, чем диванные аналитики.

/dev/sdc2 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdc2 on /mnt/sdc2 type ext4 (rw,relatime,errors=remount-ro,data=ordered)

У тебя /dev/sdc2 2 раза смонтирован. Убери это (umount /mnt/sdc2), если хочешь корень на /mnt/sdc2 - поставь символическую ссылку (rmdir /mnt/sdc2; ln -s / /mnt/sdc2) и после этого unde заработает.