LINUX.ORG.RU
Форум — Talks  

Ядерная ностальгия


0

1

Скриншоты сделаны вчера на i7-2600K/8 Gb RAM, Linux 4.7.0, glibc 2.24, GCC 6.1.0, ncurses 6.

http://saahriktu.org/tmp/scr1471357088.png , http://saahriktu.org/tmp/scr1471357242.png , http://saahriktu.org/tmp/scr1471357356.png , http://saahriktu.org/tmp/scr1471358096.png , http://saahriktu.org/tmp/scr1471358703.png , http://saahriktu.org/tmp/scr1471358907.png , http://saahriktu.org/tmp/scr1471360589.png , http://saahriktu.org/tmp/scr1471360643.png , http://saahriktu.org/tmp/scr1471360696.png , http://saahriktu.org/tmp/scr1471360783.png , http://saahriktu.org/tmp/scr1471361158.png , http://saahriktu.org/tmp/scr1471361279.png , http://saahriktu.org/tmp/scr1471364756.png , http://saahriktu.org/tmp/scr1471364886.png , http://saahriktu.org/tmp/scr1471364991.png , http://saahriktu.org/tmp/scr1471365031.png , http://saahriktu.org/tmp/scr1471365213.png , http://saahriktu.org/tmp/scr1471365234.png .

★★★★★
← Кинематограф. Пьянь. ЖЖ. 1927.
Как вернуть старый дизайн ВКонтакте? →
Ответ на: комментарий от Lavos

Нет, это собственная сборка на основе LFS. А от ядер только менюшки для скриншотов.

saahriktu ★★★★★
() автор топика

По названию подумал что тут будут фотки с различных ядерных испытаний и был сильно разочарован:(

Napilnik ★★★★★
()

похожие темы доставили

unt1tled ★★★★
()
Ответ на: комментарий от Stahl

Чтобы юзать локаль KOI8-R совсем необязательно быть таким же как Эдик-М. А скриншоты сделаны таки при локали KOI8-R.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

совсем необязательно

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

Stahl ★★☆
()
Ответ на: комментарий от cvs-255

У разных ядер по-разному. Сборка ядра 2.1.132, например, падает с 

include/linux/types.h:10:9: ошибка: unknown type name <<__kernel_dev_t>>
 typedef __kernel_dev_t  dev_t;

include/linux/types.h:13:9: ошибка: unknown type name <<__kernel_nlink_t>>
 typedef __kernel_nlink_t nlink_t;

...

include/linux/wait.h:11:22: фатальная ошибка: asm/page.h: Нет такого файла или каталога
 #include <asm/page.h>
Если же выполнить 
cp /usr/include/linux/types.h include/linux/
cp /usr/include/linux/wait.h include/linux/
то оно начинает падать с 
include/linux/fs.h:22:24: фатальная ошибка: asm/atomic.h: Нет такого файла или каталога
 #include <asm/atomic.h>
Можно сразу выполнить 
cp /usr/include/linux/* include/linux/ -R
И тогда всё сразу встрянет на том заголовочном файле, которого в сегодняшних Linux'ах уже нет: 
include/linux/mm.h:16:22: фатальная ошибка: asm/page.h: Нет такого файла или каталога
 #include <asm/page.h>
linux/mm.h уже всё. А в том файле было 
/*
 * Linux kernel virtual memory manager primitives.
 * The idea being to have a "virtual" mm in the same way
 * we have a virtual fs - giving a cleaner interface to the
 * mm details, and allowing different kinds of memory mappings
 * (from shared memory to executable loading to arbitrary
 * mmap() functions).
 */
Окончательно убедиться в выпиленности этого можно пропатчив этот файл до 
#include <asm-x86_64/page.h>
#include <asm-x86_64/page.h>
И тогда вылезет это: 
include/linux/mm.h:38:2: ошибка: unknown type name <<pgprot_t>>
  pgprot_t vm_page_prot;

include/linux/mm.h:83:8: ошибка: unknown type name <<pgprot_t>>
 extern pgprot_t protection_map[16];

include/linux/mm.h:101:58: ошибка: unknown type name <<pte_t>>
  int (*swapout)(struct vm_area_struct *,  unsigned long, pte_t *);

include/linux/mm.h:102:2: ошибка: expected <<;>> before <<pte_t>>
  pte_t (*swapin)(struct vm_area_struct *, unsigned long, unsigned long);

include/linux/mm.h:120:2: ошибка: unknown type name <<atomic_t>>
  atomic_t count;

include/linux/mm.h:241:31: ошибка: unknown type name <<__get_free_pages>>
 extern unsigned long FASTCALL(__get_free_pages(int gfp_mask, unsigned long gfp_order));

...

include/linux/mm.h:256:22: ошибка: unknown type name <<free_pages>>
 extern void FASTCALL(free_pages(unsigned long addr, unsigned long order));

include/linux/mm.h:257:22: ошибка: unknown type name <<__free_page>>
 extern void FASTCALL(__free_page(struct page *));

...

include/linux/mm.h:269:87: ошибка: unknown type name <<pgprot_t>>
 extern int remap_page_range(unsigned long from, unsigned long to, unsigned long size, pgprot_t prot);

include/linux/mm.h:270:71: ошибка: unknown type name <<pgprot_t>>
 extern int zeromap_page_range(unsigned long from, unsigned long size, pgprot_t prot);

...

include/linux/mm.h:339:24: ошибка: <<current>> undeclared (first use in this function)
      > (unsigned long) current->rlim[RLIMIT_STACK].rlim_cur ||

...

include/linux/mm.h:339:38: ошибка: <<RLIMIT_STACK>> undeclared (first use in this function)
      > (unsigned long) current->rlim[RLIMIT_STACK].rlim_cur ||

include/linux/mm.h:340:17: ошибка: dereferencing pointer to incomplete type <<struct mm_struct>>
      (vma->vm_mm->total_vm << PAGE_SHIFT) + grow

include/linux/mm.h:341:38: ошибка: <<RLIMIT_AS>> undeclared (first use in this function)
      > (unsigned long) current->rlim[RLIMIT_AS].rlim_cur)

include/linux/slab.h:15:23: фатальная ошибка: asm/cache.h: Нет такого файла или каталога
 #include <asm/cache.h>
slab.h сегодня переехал в /usr/include/proc/slab.h. После 
cp /usr/include/proc/slab.h include/linux/slab.h
Можно узнать также что в прошлое ушли как и asm/delay.h так и linux/delay.h. Ну и т.д.

С ядром 2.4.0 аналогичные проблемы. А сборка ядра 2.4.37 падает с 

#error "GCC >= 4.2 miscompiles kernel 2.4, do not use it!"
В ядрах 2.6.x вообще сурово хардкодили, там даже менюшки почти везде не запускаются, поскольку make жалуется на устаревший синтаксис, Ну и т.д.

saahriktu ★★★★★
() автор топика

Эх блин, взял и выкинул свой старье.
А щас вроде бы и жалко. Смотрю теперь, как посоны американские на ютрубе балуются со всякими ПК тех лет.

А ведь с другой стороны, зачем этот тормозной хлам...
Ведь помню, как 180МГц с трудом пережевывали установку ВинНТ4.0.

Deleted
()
Ответ на: комментарий от lenin386

Не умею не собирать, а патчить старые. Впрочем, я такой задачи выше и не ставил. Я просто привёл примеры поверхностных проблем. Если исходники не нужно патчить, то что там уметь-то? «make oldconfig && make bzImage» - и всё.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от Stahl

Достаточно лишь быть <…> сумасшедшим вимером

У нас есть проблемы с UTF8?

dexpl ★★★★★
()
Ответ на: комментарий от saahriktu

KOI8-R хватает не только для кириллицы, но и для латиницы.

Ее не хватает ни для того, ни для другого.

dexpl ★★★★★
()
Ответ на: комментарий от saahriktu

Не надо ничего патчить, надо убрать из /usr/include либо линки на include файлы от других (новых) ядер, либо сами include файлы от этих ядер. Оно у тебя потому и не собирается.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от dexpl

Как это «не хватает»? Для латиницы хватает даже ASCII. А KOI8-R совместима с ASCII. И вдобавок ещё и кириллицу содержит, для этой задачи её и придумали.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Как это «не хватает»?

Для латинского алфавита — хватает, для текстов на человеческих языках — нет: ни знаков препинания (тире где?), ни типографских знаков (кавычки где), ни диакритики (умляуты где?).

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Так я же говрил именно про латиницу [a-zA-Z] и кириллицу [а-яА-Я] - и всё, не более этого. Для этого хватает.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Так я же говрил именно про латиницу [a-zA-Z] и кириллицу [а-яА-Я]

Разве что для этого и хватает.

dexpl ★★★★★
()
Ответ на: комментарий от lenin386

Те версии ядер про x86_64 вообще не знают. Если просто распаковать тарбол и ничего не менять, то 

> cd linux/
> make menuconfig
Makefile:186: arch/x86_64/Makefile: Нет такого файла или каталога
make: *** Нет правила для сборки цели <<arch/x86_64/Makefile>>.  Останов.
Но, можно сделать 
cp arch/i386/ arch/x86_64 -R
sed -i "s/ -m.86 -DCPU=.*$//" arch/x86_64/Makefile
И тогда оно начинает собираться. Но, дальше нужно основательно патчить.

Linux 2.4.37 знает про x86_64. Если там убрать заголовочные файлы ядра из /usr/include, то оно выпадает с 

/usr/include/bits/local_lim.h:38:26: фатальная ошибка: linux/limits.h: Нет такого файла или каталога
 #include <linux/limits.h>
Если же их оставить на месте, а убрать заголовочные файлы собираемого ядра, то оно выпадает с 
mv: невозможно переместить '.ver' в 'include/linux/version.h

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

О чём ты говоришь вообще. Между x86 и x86_64 нет никакой разницы в плане того, что ошибки bus_error на нормально функционирующей системе возникать не должно никогда. Это ошибка невыровненного доступа к памяти, она характерна для всяких жоских архитектур типа Sparc. x86 и x86-64 вообще пофиг, выровненный доступ или невыровненный. Не должно быть такой ошибки, я не знаю, как ты её достиг. Что качется всего того, что ты описал дальше - это из-за того, что у тебя в /usr/include хидеры от сильно других ядер. Либо их (хидеров) там вообще нет, надо скопировать из того дерева, что собираешь. Причём, в несколько мест.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от lenin386

надо скопировать от текущего

Точнее от собираемого. Я уже так попробовал, и сборка 2.4.37 таки пошла, но засыпалась на линковке: 

dma.o: In function `set_64bit':
dma.c:(.text+0x0): multiple definition of `set_64bit'
sched.o:sched.c:(.text+0x1b): first defined here
dma.o: In function `get_order':
dma.c:(.text+0x4): multiple definition of `get_order'
sched.o:sched.c:(.text+0x0): first defined here
dma.o: In function `read_lock':
dma.c:(.text+0x1a): multiple definition of `read_lock'
sched.o:sched.c:(.text+0x9c): first defined here
dma.o: In function `cpuid':
dma.c:(.text+0xc9): multiple definition of `cpuid'
sched.o:sched.c:(.text+0x24): first defined here
dma.o: In function `cpuid_eax':
dma.c:(.text+0xe1): multiple definition of `cpuid_eax'
sched.o:sched.c:(.text+0x41): first defined here
dma.o: In function `cpuid_ebx':
dma.c:(.text+0xe8): multiple definition of `cpuid_ebx'
sched.o:sched.c:(.text+0x4d): first defined here
dma.o: In function `cpuid_ecx':
dma.c:(.text+0xf1): multiple definition of `cpuid_ecx'
sched.o:sched.c:(.text+0x5b): first defined here
dma.o: In function `cpuid_edx':
dma.c:(.text+0xfa): multiple definition of `cpuid_edx'
sched.o:sched.c:(.text+0x69): first defined here
dma.o: In function `thread_saved_pc':
dma.c:(.text+0x103): multiple definition of `thread_saved_pc'
sched.o:sched.c:(.text+0x77): first defined here
dma.o: In function `rep_nop':
dma.c:(.text+0x10c): multiple definition of `rep_nop'
sched.o:sched.c:(.text+0x85): first defined here
dma.o: In function `sync_core':
dma.c:(.text+0x10f): multiple definition of `sync_core'
sched.o:sched.c:(.text+0x8d): first defined here
dma.o: In function `mark_info_dirty':
dma.c:(.text+0x119): multiple definition of `mark_info_dirty'
...
И т.д.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

А вот так вот получается ошибка шины: 

open("sys.c", O_RDONLY)                 = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24569, ...}) = 0
mmap(NULL, 28672, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa9df433000
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7fa9df439000} ---
+++ killed by SIGBUS +++
Таким образом, эту ошибку вызывает mmap().

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Ведь помню, как 180МГц с трудом пережевывали установку ВинНТ4.0.

Фигню морозишь. NT4 нормально работала на пентиуме 133МГц, и даже на 486DX4-75 (мы запускали и работали даже на 486DX2-66).

no-dashi ★★★★★
()
Ответ на: комментарий от lenin386

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

crypt ★★★★★
()
Ответ на: комментарий от crypt

Плохо тому, кто первый раз слышит про ловушки, «trap alignment check» и т.п. вещи.

saahriktu ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Кинематограф. Пьянь. ЖЖ. 1927.
Talks
Как вернуть старый дизайн ВКонтакте? →