LINUX.ORG.RU
Ответ на: комментарий от anonymous_sapiens

>вы путаете - архитектура x86_64 полностью совместима с 32-битными приложениями
Не звизди. Линковать 32-битные библиотеки к 64-битным нельзя и наоборот. То ли дело в винде, ненавистный линуксоидам COM прозрачно позволяет использовать их в обе стороны.

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

> То ли дело в винде, ненавистный линуксоидам COM прозрачно позволяет использовать их в обе стороны.

То-то и видно, с какой сокростью распространияются 64-битные винды. К 2010 году они едва ли вышли из 1%, хотя уже в 2005 году я лично ввел в продакшн несколько компов на 64-битной федоре. Неокторые из них эксплуатируются до сих пор. Молчал бы уж, вантузятник.

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

Не звизди. Линковать 32-битные библиотеки к 64-битным нельзя и наоборот.

В случае с ядром это и не требуется.

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

В рамках одного процесса? Интересно как это реализовано. (не троллинга ради, действительно интересно)

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

>То-то и видно, с какой сокростью распространияются 64-битные винды.
Работает - не ломай. Слышал такую поговорку, мастер-ломастер?

я лично ввел в продакшн несколько компов на 64-битной федоре.

Одмин локалхоста? Ололо.

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

> Работает - не ломай. Слышал такую поговорку, мастер-ломастер?

Неужели «нам это не надо». Ню-ню, сиди, используй 2.5 Гб из 4 и радуйся.

Одмин локалхоста? Ололо.

Ты-то, я вижу, только на лоре языком работаешь, убогий.

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

>Иди поставь винду на суперкомпьютер, а также на телефон (телевизор и точку доступа), убогий.
Типичные отговорки красноглазика, ей богу. Не нужны мне твои суперкомпьютеры дома, я хочу рабочую беспроблемную мультимедийную систему. С кластерами на несколько сот нод мне хватает *бли на работе.

anotheranonymous
()
Ответ на: комментарий от namezys

mac os x

там ядро и приложениря могут быть как 32 бита, так и 64 - независимо друг от друга

Покажи uname -a.

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

>Неужели «нам это не надо». Ню-ню, сиди, используй 2.5 Гб из 4 и радуйся.
Не научился использовать ресурсы правильно? Твои проблемы недопрограммера. Почитай почему постгресовцы не озабочены переносом pg на win64 и не кукарейкай, лол.

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

> Не нужны мне твои суперкомпьютеры дома, я хочу рабочую беспроблемную мультимедийную систему.

Не нужно мне твое говножележо из китайского подвала. МОЕ железо работало с линуксом из коробки. Более того, оно используется до тех пор, пока не выйдет из строя или устареет, а не до первого обновления винды.

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

>Линковать 32-битные библиотеки к 64-битным

omg

COM прозрачно позволяет использовать их в обе стороны.


omg omg omg

anon_666
()
Ответ на: комментарий от anotheranonymous

> Не научился использовать ресурсы правильно? Твои проблемы недопрограммера. Почитай почему постгресовцы не озабочены переносом pg на win64 и не кукарейкай, лол.

Научи матричку 32000х32000 of doubles укладывать в 2 гига, а?

Почитай почему постгресовцы не озабочены переносом pg на win64 и не кукарейкай, лол.

Да мне пох, почему. Факт в том, что 64-битные винды все еще в жопе, хотя 8 лет прошло с момента анонса соотв. процов.

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

>Научи матричку 32000х32000 of doubles укладывать в 2 гига, а?
За это недопрограммеров у**ывают кочергой с размаху, чтобы род не продолжали, если ты не знал, ага.

Да мне пох, почему. Факт в том, что 64-битные винды все еще в жопе, хотя 8 лет прошло с момента анонса соотв. процов.

Факт в том, что сейчас линуксовые сервера почему-то потихоньку сливают винде и их уже 50/50 не смотря на то что они 64-бита поддерживают, вот не задача.

anotheranonymous
()
Ответ на: комментарий от annoynimous

Факт в том, что 64-битные винды все еще в жопе, хотя 8 лет прошло с момента анонса соотв. процов.

20 лет, если всякие MIPS'ы вспомнить =).

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

Если у ТС проц не поддеерживает x86_64, то ему поможет только qemu, да.

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

>omg

omg omg omg

Да, вот так вот прогресс и проходит, мимо линуксоидов, которые ничего кроме слизанных технологий 10летней давности не видят.

anotheranonymous
()
Ответ на: комментарий от anon_666

Да, и в контексте одного процесса возможен либо x64-режим, либо x32.
Это аппаратное ограничение.

anon_666
()
Ответ на: комментарий от anotheranonymous

> За это недопрограммеров у**ывают кочергой с размаху, чтобы род не продолжали, если ты не знал, ага.

Поучи меня еще сайнс делать, недоумок. Если твоему быдлокодеришкинскому умишке не осилить более 100 элементов в матрице, это не значит, что это никому не нужно

Факт в том, что сейчас линуксовые сервера почему-то потихоньку сливают винде и их уже 50/50 не смотря на то что они 64-бита поддерживают, вот не задача.

А в 91 году его там вообще не было. И если винда будет идти на серверы с такой же скоростью, как на 64 бита, то линуксу еще долго никто не угрожает. Пора уж признать, что никуда, кроме x86 десктопов винда выйти не в состоянии. Да и вышла она туда потому, что у нее на момент появления этих x86 десктопов конкурентов-то и не было (ну, кроме может OS/2)

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

>То ли дело в винде, ненавистный линуксоидам COM прозрачно позволяет использовать их в обе стороны.

ничто не мешает делать это под никсами используя любой другой RPC механизм

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

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

ничто не мешает делать это под никсами используя любой другой RPC механизм

Только вот производительность при этом будет страдать ой ой ой как =). Об этом другойанонимус забыл упомянуть.

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

Линковать 32-битные библиотеки к 64-битным
прогресс

Скорее костыль..

Этот костыль невозможен и в венде.

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

Я знаю, но тут товарищ за пруфом побежал, мб чего принесёт %)

anon_666
()
Ответ на: комментарий от annulen

гамильтониан для 5-мерного УШ. Да, его можно, конечно, держать на диске, но тогда чтение-запись съедят большую часть времени. Как раз самое интересное происходит в районе размеров 4-6 гигов.

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

>гамильтониан для 5-мерного УШ

УШ- уравнение Шредингера? никогда так не сокращал:)

суровые астрофизики?

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

>Только вот производительность при этом будет страдать ой ой ой как =). Об этом другойанонимус забыл упомянуть.
Если корба тормознутая ой ой ой как, то это не значит что COM такой же.

anotheranonymous
()
Ответ на: комментарий от annoynimous

>Поучи меня еще сайнс делать, недоумок.
Да тебя бесполезно учить, ты - отброс. Мне то приходится с массивами данных близкими к петабайтным, так что не смеши меня своими матрицами.

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

В педивикии такого не нашёл, а мсдн лопатить трафика не хватит %)

anon_666
()
Ответ на: комментарий от anotheranonymous

Если вы про

Линковать 32-битные библиотеки к 64-битным


то это действительно невозможно, архитектура проца не позволит %)

anon_666
()
Ответ на: комментарий от anotheranonymous

Этот костыль невозможен и в венде.

Если ты этого не знаешь, то это не значит что это невозможно, просто ты это не знаешь, лол.

Ещё раз: смешивать 32х-разрядный код и 64х-разрядный невозможно в рамках одного процесса.

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

Только вот производительность при этом будет страдать ой ой ой как =). Об этом другойанонимус забыл упомянуть.

Если корба тормознутая ой ой ой как, то это не значит что COM такой же.

Мы вроде про библиотеки говорили, ага? Так вот, по сравнению с локальными вызовами внутри одного процесса, потери на RPC будут просто катастрофическими, как ни крути.

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

Мне то приходится с массивами данных близкими к петабайтным, так что не смеши меня своими матрицами.

Что за данные и что ты с ними делаешь?

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

> Мне то приходится с массивами данных близкими к петабайтным, так что не смеши меня своими матрицами.

И все под виндой? Снимаю шляпу, ты мужик! Кем работаешь? Пол подметаешь в метеоцентре?

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

>Ещё раз: смешивать 32х-разрядный код и 64х-разрядный невозможно в рамках одного процесса.
А кто говорил про один процесс, хоть почитай как COM работает то.

anotheranonymous
()
Ответ на: комментарий от annoynimous

>И все под виндой? Снимаю шляпу, ты мужик! Кем работаешь? Пол подметаешь в метеоцентре?
Как ни странно не под виндой, а под линуксом, но совсем не из-за тех причин.

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

Ещё раз: смешивать 32х-разрядный код и 64х-разрядный невозможно в рамках одного процесса.

А кто говорил про один процесс, хоть почитай как COM работает то.

Тут все кроме тебя про один процесс говорят. Ты тему то почитай. А про то, что RPC можно делать хоть между несовместимыми друг с другом архитектурами процессоров, я и не спорю.

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

>потери на RPC будут просто катастрофическими, как ни крути.
В винде буквально все на COM сделано и ничего, все работает и не тормозит в отличии от :)

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

потери на RPC будут просто катастрофическими, как ни крути.

В винде буквально все на COM сделано и ничего, все работает и не тормозит в отличии от :)

Я всё больше убеждаюсь, что ты не разбираешься в том, о чём говоришь. COM - это не только RPC. COM - это вообще много разных, но связанных друг с другом, «технологий».

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

Еще раз ЧИТАЙ ПРО COM. С помощью нее можно прозрачно для приложения делать вызовы независимо от архитектуры, за тебя все сделает COM и процесс новый создаст и свяжет с ним, тебе об этом заботиться не надо и ты даже и не заметишь этого, как будто выполняется все в одном процессе. А большего тебе и не надо.

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

>COM - это вообще много разных, но связанных друг с другом, «технологий».

Как это расходится с

В винде буквально все на COM сделано и ничего, все работает и не тормозит в отличии от :)


?

Это ты не понимаешь о чем говоришь.

anotheranonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.