Linux за българи: Форуми

Здравейте,

Как се инсталира джава плугин под Убунту 64 бита.

Пробвах какво ли не. Всички jre-та изпонасложих НО плугина липсва. С апт-файл намерих някаква 32 битова джава която го включва но не работи.  

Аз ползвам това icedtea-gcjwebplugin и работи перфектно

Разгледай тези два линка: 1 & 2

Стига сте го карали да гледа глупости apt-get install icedtea-gcjwebplugin

Не ми е любим. Единствено той работи от репозитора. 32 ботовия фф също липсва.

Престанете да използвате x86_64 дистрибуции, файда няма

Не може да я използва един процес, иначе спокойно си се утилизира.

Е кога да почнем да ползваме 64 бита? Говоря за десктоп за сървър от години го ползвам макар че и 64 битовия ми десктоп дръпна доста през годините единствено лаптоп-а ми се още крета на 32

Като му оправят софтуера, мене ми писна да ми крашват някакви неща и със зор да си подкарвам флаш плъгини и т.н. Освен това рам-та ми е по-важна отколкото някаква си там имагинерна подобрена производителност, която субективно така и не мога да оценя за момента

Да ама ако няма потребление няма и производство

Плугина работи чудесно. 10х to trip.

/офф
Недейте да се карате. Разлика има голяма между 64 и 32 вата. Софта си работи перфектно, като изключим тоя плугин. Ако някой някъде има проблем с някой сорс да си провери/смени компилатора. Гейтуей като го кефи да си ползва ако иска и 8 битова ОС.

Мммм между 8 битовите архитектури и 16-битовите има фундаментални разлики - като изключим 64-те килобайта адресно пространство, което още тогава е било недостатъчно (BTW досовските .COM файлове са реликва от това време, те имат същия 64 килобайтов лимит ). 8-битовите I/O операции водят до много огромни ограничения и всякаквото съществуване на примитивна мултимедия и мрежови насочености е живо чудо и благодарение на големи фокуси.

Разликата между 16-битовите и 32-битовите архитектури също е огромна - тогава се въвежда понятието "защитен режим" и дефакто истинска многозадачност с отделни виртуални адресни пространства за всеки процес, така че един процес по грешка да не може да съсипе цялата операционна система. 4-те гигабайта витуална памет, която може да се адресира е прекалено много, дори в днешно време. Главно защото вече имаш многозадачност, могат да се форк-ват други процеси и си има механизми за IPC. Дори сега обаче малко са приложенията, където един процес да ИМА нужда от повече от 4 гб памет. Това което аз се сещам са java приложения, например някакъв application server, където ти трябва повече heap memory и в рамките на java процеса си имаш собствен трединг и собствен мениджър на паметта, garbage collection механизми и т.н.

Обаче разликата между 32-битови и 64-битови архитектури в днешно време където средната десктоп система има не повече от 2-4 гигабайта рам просто е нищо на фона на това което е било допреди.

Когато приложенията почнат лакомо да тъпчат по няколкостотин гигабайта памет ще се замисля.

Но иначе най-доброто преимущество на 64-битовите архитектури е голямото адресно пространство (при съществуването на ALSR) и хардуерния NX бит, което прави старите buffer overflows ужасно сложни за експлойтване и ерго приложенията са по-сигурни от гледна точка на програмистки грешки.

Но аз примерно имам 2 гигабайта РАМ тук вкъщи. Айде сега си направете една елементарна сметка - една програма резервира памет за масив от pointer-и от 100.000 елемента. На 32-битова ОС това ще заеме 400 килобайта, на 64-битова - 800 килобайта. Това е прост пример. При всички положения, 64-битовата ОС ти използва повече памет, отколкото 32-битовата. Еее, аз някак си ще пожертвам сигурността за сметка на това, имам само 2 гигабайта памет, както казах

Доколкото знам проблема с паметта е само при пойнтърите. Aко масива е динамичен едва ли ще има особена разлика в ползваната памет.

Става примерно и с long типовете. Като оставим това, .text секцията винаги е по-голяма, нали искате кодът да ви е оптимизиран да ползва 64-битовия instruction set

А това дали е динамично-заделен (демек е в heap-а) или не, няма никакво значение, пак си взема еднакво много памет.

И отделно имаш стек, в който се държат адресите на които програмата продължава след RET инструкция, той също ще е до 2 пъти по-голям.

*кхъм* хубавата страна е че математически погледнато няма как същите неща да отнемат повече от 2 пъти повече памет

char принципно не е ли 8 битова стойност?

Нямам идея в c++ как стоят нещата де, много съм скаран с ООП езиците  В C принципно sizeof(char) е 1, бях много учуден когато sizeof(int) ми излезе 4 на 64-битова платформа, нещо което не мога да си обясня много добре, има очевидно някаква конвенция по въпроса, но тъй като не съм програмист не задълбавам особено в тия неща. Но за long типа и за указателите със сигурност има разлика.

За C++ пак казвам, не знам. Ако е така както казваш, още по-зле за 64-битовите qt приложения например


Неее, докато не измислят нещо революционно, което да осмисля 64-битовата архитектура и докато паметта не поевтинее доволно много, никаква x86_64 дистрибуция за десктопа, прогресът да си гледа работата

Гарантира се от двата стандарта ако не се лъжа, че char е поне 8 бита, но това не значи, че не може да е по - голям на някои платформи(не на всички платформи един байт е 8бита). За int-a знам, че го има проблема даже четох тази статия по въпроса. Затова и sizeof(char) == 1, но ми е странно колко ти показва CHAR_BIT от <limit.h> - header-a май е от C99

Примерен код

#include <limits.h> #include <stdio.h> int main (int argc, char const* argv[]) {     printf("%d", CHAR_BIT);     return 0; }

P.S. Честит ден на програмиста на всички. Аз не се приемам много, но все пак бира да се лее    

Аз реших че в C++ са решили да правят char по някакъв начин обвързан с unicode и таман щях да излея малко помия по тоя въпрос Може да звучи идиотски, но тъй като не му разбирам и наистина не бих се учудил,  не че не звучи глупаво де

Иначе вади 8, както се очакваше

Просто си попаднал на такава архитектура и много зависи от компилатора   До колкото знам gcc ползва LP64 модела

http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit

Цитат

However, in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide, and even SILP64 where "short" variables are also 64 bits wide[citation needed]. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit. "LL" refers to the "long long" type, which is at least 64 bits on all platforms, including 32-bit environments.

Цитат

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types. Note that a programming model is a choice made on a per-compiler basis, and several can coexist on the same OS. However typically the programming model chosen by the OS API as primary model dominates.

Много повърхностни сравнения с тези c++ bulshits. Изкривяването на темата с тези LLP64, LP64 и всякакви други гадости е безсмилсено. Факт е, че:
- 64 битова архитектура е препоръчително да ползваш, ако имаш над 4Г рам и искаш наистина да я имаш. В Windows на 32 битова архитектура, ако не се лъжа се засичаше около 3.2Г от 4г.
- 64 архитектура има два пъти повече CPU регистри => два пъти повече информация се обработва, преди да достигне кеша на рамта
- в 64 б.а. SSE и SSE2 са включение в core instruction сета
- затворени приложения е трудно да подкараш на 64 битова машина, но не е невъзможно... все още няма 64 битова версия на така респектиращият Flash плъгин... говори се, че 10-та щяла вече да поддържа 64, но знае ли човек... дугият основен проблем е джавата, която има версия за Windows и Соларис, но няма за Linux

В общи линии е това... човек трябва сам да избира

java-та си работи. Просто аплетите не работят . Има разлика между двете, иначе за другото си прав, но тия точки поне на мен не ми докараха особена производителност, а проблемите са на лице.

Gaara, единственото за което си прав е че има доп. регистри. Не че има ами ги ползваш. Водят се Extended (X). За разлика от 32 битовия който ползва само High(H) и Low(L) регистрите. Cpp кодчетата простичко уборват теорията на гейтуей. Флаш разбира се че има и работи. SSE мултимедийни инструкции нямат нищо общо с проблема и работят и се използват и при 32 битови ОС-и.

http://img144.imageshack.us/my.php?image=screenshotrc3.png

Ясно се вижда модела на фф и флаша с който нямам никакви проблеми.

Nikolavp е прав за компилатора. Някъде из 2-рата страница от темата писах ако някой има проблеми със сорсове да си провери компилатора. Гледам че масово почва да се разпространява gcc-4.3 което НЕ Е стабилно и не бива по него да се съди за приложенията.

Като цяло никой не може да успори факта и да ме убеди че 32 бита и 64 бита са едни и същи.

Факт също е че всичко работи чудесно и на 2 гъби рам. Не виждам нито едно приложение да "точи" повече памет отколкото при 32 бит.

Нищо лично към никой и нека някой администратор заключи темата че се пълни с безсмислици.

triplek, недей така.... 64 битов флаш няма, няма как да пуснеш повече от 4Г рам, разликата на gcc 4.3 е в хедъра на самият код, който се компилира... премахват се разни неща, с цел по-бързо компилиране и всякакви такива тъпотии, като резултата е, че warning-те преминават  в errors... за SSE-то прочети малко повечко и ще ме разбереш

Ето и малко теория, че цигарата ми се услади и ако правилно си я спомням... когато  LMA  (long mode active) не е активен (фен съм на АМД и затова говоря само за него), процесора оперира в стандартен x86 режим и може да работи с 32 битови приложения. Когато LMA  е активиран,  64-bit допълнения ще бъдат включени. От своя страна long mode-а се разделя и на два под режима: 64-битов и съвместим. Тези два режима се контролират от D и L битовете от code segment регистъра. Причината да споменвам тези тъпотии е, че LM ти позволява да използваш 64-битовите feature-и и в същото време ти предалага и съвместимият режим за да пускаш 32-битови приложения. Този режим ти позволява:
- Допълнителни 8 регистъра
- Виртуално 64-bit адресиране
- Допълнителни 8 регистъра за SIMD (XMM регистри)
- Flat адресиращ режим и т.н.

Доплънителните регистри за SIMD операциите прави общият брой на multimedia регистри на 16, което е една от слабостите на х86, т.е. малкият брой регистри.

Идеята ми от тези глупости е, че като идея х86-64 е много добрa, но все още не е готово за употреба. Факт е, че едва 15 процента от сваляните iso-та на Дебиан, са 64 битови... във федора май бяха с 5 % повече, което води до по-малко потребление => по-малко или по-бавно развитие

Дразните ме и само заради вас сега ще си подкарам една x86_64 виртуална машина, ще компилирам едно и също приложение и ще я видиме тая работа