Do szyfrowania partycji w systemach Linuksowych można wykorzystać dm-crypt - jest to już od dłuższego czasu w jądrze, potrzebny jest jeszcze tylko pakiet cryptsetup. W konfiguracji jądra należy włączyć szyfry (np. AES, Blowfish) i dm-crypt dla "Device mapper".
Teraz pokażę jak utworzyć szyfrowaną partycję, ja wykorzystuję LVM, ale nic nie stoi na przeszkodzie wykorzystać dowolną inną partycję.
Tworzymy partycję:
# lvcreate -n encrypted -L 2G vg Logical volume "encrypted" created
Tworzymy mapowanie szyfrujące:
# cryptsetup -v --cipher aes-cbc-plain -y create decrypted /dev/vg/encrypted Enter passphrase: Verify passphrase:
Tworzymy system plików:
# mkfs.ext3 /dev/mapper/decrypted
mke2fs 1.40.6 (09-Feb-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=536870912
16 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Teraz już możemy zamontować naszą zaszyfrowaną partycję:
# mount /dev/mapper/decrypted /mnt/crypt
Utworzone mapowanie będzie istniało aż do wyłączenia systemu lub ręcznego usunięcia (przez cryptsetup remove). W Gentoo automatyczne tworzenie mapowań realizuje dodatek dmcrypt do baselayout, polecam przeczytać plik /etc/conf.d/dmcrypt.
Ważne: błędnie podane hasło nie jest sygnalizowane przez cryptsetup - dopiero nieudana próba zamontowania odszyfrowanej partycji może świadczyć o błędnym haśle.
Dużą zaletą dm-crypt w porównaniu z szyfrowaniem pojedynczych plików jest ukrywanie nie tylko zawartości plików ale również informacji o nich: szyfrowany jest cały system plików - uniemożliwia to nie tylko odczytanie danych z plików, ale również zorientowanie się co właściwie jest na takiej partycji. Drugą ważną zaletą jest przeźroczystość rozwiązania - odszyfrowaną partycję montujemy jak każdą inną, więc można ją wykorzystać do dowolnego celu - trzymanie tajnej poczty, szyfrowanie plików baz danych w /var/lib/postgresql, ogólnie: można z taką partycją dokładnie to samo co z normalną (niezaszyfrowaną) partycją (w odróżnieniu od encfs). Wadą jest wymaganie praw administratora do utworzenia mapowania i zamontowania partycji w odróżnieniu od wspomnianego już encfs, który działa jako moduł FUSE.
dm-crypt umożliwia również wczytywanie klucza z pliku zamiast hasła z klawiatury, daje to ciekawe możliwości:
- szyfrowanie partycji wymiany (swap) losowym kluczem z /dev/urandom - innym przy każdym starcie
- szyfrowanie partycji kluczem zapisanym na zewnętrznym nośniku: pendrive, karta SD, telefon z włączonym Bluetooth, etc...
Więcej o dm-crypt można poczytać na stronie domowej dm-crypt.
Druga część testu kompresorów, tym razem uwzględniony został dodatkowo zip i wszystkie możliwe stopnie kompresji dla gzip, bzip2 i lzma. Testy obejmowały również czas kompresji.
Zmienił się plik testowy: tym razem to archiwum zawierające zdjęcia JPEG, dokumenty (OpenOffice.org, PDF) oraz drzewko portage. Plik wejściowy ma rozmiar 281 MB (294420480 bajtów).
Wyniki testów:
lzma wypadł najlepiej pod względem wynikowego rozmiaru pliku, najgorzej pod względem czasu kompresji. Ale jak zaznaczyłem w poprzednim odcinku: dla mnie w tym przypadku nie liczy się czas kompresji. Ciekawie wypada porównanie bzip2-9 i lzma-2: lzma-2 jest lepszy zarówno pod względem czasu jak i rozmiaru pliku.
Zrobiłem dzisiaj mały test różnych metod kompresji plików. W konkursie udział brały trzy programy:
- gzip
- bzip2
- lzma
Plikiem który był archiwizowany jest md.tar - archiwum zawierające moją skrzynkę pocztową. Plik ma rozmiar 547 MB (573378560 bajtów). Ważny warunek: nie liczy się czas kompresji, najważniejszy jest jak najmniejszy rozmiar pliku wynikowego.
Wyniki wyglądają następująco (posortowane według finalnego rozmiaru pliku, im mniej tym lepiej):
| Metoda kompresji | Rozmiar pliku (MB) | Rozmiar pliku (bajty) |
| lzma -9 | 207 | 216402095 |
| lzma -7 | 223 | 233372691 |
| bzip2 -9 | 270 | 282651378 |
| bzip2 -7 | 271 | 284121394 |
| gzip -9 | 278 | 291419283 |
| gzip -7 | 279 | 291837325 |
| bzip2 -1 | 280 | 293459891 |
| lzma -1 | 282 | 295213626 |
| gzip -1 | 295 | 308516514 |
Lub w formie wykresu:
lzma wypada zaskakująco dobrze nawet przy -7 (domyślne ustawienie kompresji). Krótko podsumowując: jeśli nie liczy się czas kompresji to lzma jest najlepszym wyjściem.
Since my commit 301 to my overlay we have preliminary support for packaging Java web applications in Gentoo. First real application that uses it is blojsom - A Java-based, full-featured, multi-blog, multi-user software package, it has been added as commit 304.
Big fat warning: this is first release of this eclass, so strange things may happen - you've been warned.
jabberd2 has been split from net-im/jabberd to it's own package: net-im/jabberd2. It's currently package.mask'ed for testing - if you'd like to help please take a look at bug #178055.
Pytanie: jakie przyśpieszenie daje włączenie RC_PARALLEL_STARTUP?
RC_PARALLEL_STARTUP="no"
RC_PARALLEL_STARTUP="yes"
5 sekund różnicy :)
Pracuję nad pracą magisterską i miałem dwa problemy:
- "Bookmarks" - czyli spis treści dokumentu w Acrobat Reader
- PDF Security - czyli jak zabezpieczyć dokument PDF
Rozwiązanie pierwszego problemu jest proste:
\RequirePackage[dvipdfm]{hyperref}
\hypersetup{
bookmarks=true,
bookmarksnumbered=true,
citebordercolor={0.8 0.8 1},
linkbordercolor={0.8 0.8 1},
pdfauthor={Krzysztof Pawlik},
pdfstartview=FitH,
pdfsubject={...}
pdftitle={...},
urlbordercolor={0.8 0.8 1},
}
Więcej opcji jest opisane w dokumentacji hyperref.
Drugi problem wymagał wykorzystania innego programu: PDFBox. A oto jak go wykorzystać:
pdfencrypt -O hasło -canAssemble false -canExtractContent false -canExtractForAccessibility false -canFillInForm false -canModify false -canModifyAnnotations false -canPrint false -canPrintDegraded false -keyLength 40 plik.pdf
I teraz:
mail() w PHP jest ciekawą funkcją: najczęściej nadużywaną, najmniej zabezpieczoną (żadnego logowania, ograniczeń - NIC). W sieci pojawiła się łatka, która ma to poprawić (tylko logowanie ;)), niestety ma parę wad. Poprawiona wersja dla PHP 5.2.2 znajduje się w bug 182187. Liczę, że w 5.2.4 znajdzie się już to w waniliowym PHP.
Co daje ta łatka? Możliwość logowania użycia funkcji mail(): logowana jest data, nazwa pliku PHP i odbiorca - akurat tyle ile potrzeba, żeby stwierdzić kogo powiesić ]:->
Jak korzystać z dobrodziejstwa Web services w Gentoo? Oto mały poradnik dotyczący JAXB.
Zaczynamy od zainstalowania JAXB:
# emerge -av jaxb-tools
Teraz potrzebujemy katalog projektu:
$ mkdir -p projekt/{bin,src,lib}
Nasz przykładowy plik XML (sample.xml):
<?xml version="1.0" encoding="UTF-8"?>
<dane>
<osoba imie="Jan" nazwisko="Kowalski">
<id pesel="00000000000"/>
</osoba>
<osoba imie="Janina" nazwisko="Kowalska">
<id pesel="00000000001" dowod="AAA00000"/>
</osoba>
</dane>
Tworzymy dla niego plik XML Schema (sample.xsd):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd">
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="dane">
<xs:complexType>
<xs:choice maxOccurs="unbounded" minOccurs="1">
<xs:element name="osoba" type="typeOsoba"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:complexType name="typeOsoba">
<xs:all minOccurs="1" maxOccurs="1">
<xs:element name="id" type="typeId"/>
</xs:all>
<xs:attribute name="imie" type="xs:string" use="required"/>
<xs:attribute name="nazwisko" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="typeId">
<xs:attribute name="pesel" type="xs:string" use="required"/>
<xs:attribute name="dowod" type="xs:string" use="optional"/>
</xs:complexType>
</xs:schema>
Sprawdzamy jeszcze poprawność XML Schema i przykładowego pliku XML:
$ xmllint --valid --noout sample.xsd $ xmllint --noout --schema sample.xsd sample.xml
Teraz już jesteśmy gotowi do wykorzystania XJC - kompilatora XML Schema, da on nam w rezultacie gotowe klasy Javy:
$ xjc-2 -d src/ -p net.nelchael.jaxb.generated sample.xsd
Wygenerowane pliki:
- net.nelchael.jaxb.generated.Dane
- net.nelchael.jaxb.generated.ObjectFactory
- net.nelchael.jaxb.generated.TypeId
- net.nelchael.jaxb.generated.TypeOsoba
Potrzebujemy jeszcze paru bibliotek:
$ ln -s /usr/share/codemodel-2/lib/codemodel.jar lib/ $ ln -s /usr/share/istack-commons-runtime/lib/istack-commons-runtime.jar lib/ $ ln -s /usr/share/jaxb-2/lib/jaxb-api.jar lib/ $ ln -s /usr/share/jaxb-2/lib/jaxb-impl.jar lib/ $ ln -s /usr/share/jaxb-tools-2/lib/jaxb-tools.jar lib/ $ ln -s /usr/share/jsr173/lib/jsr173.jar lib/ $ ln -s /usr/share/relaxng-datatype/lib/relaxngDatatype.jar lib/ $ ln -s /usr/share/rngom/lib/rngom.jar lib/ $ ln -s /usr/share/sun-jaf/lib/activation.jar lib/ $ ln -s /usr/share/xerces-2/lib/xercesImpl.jar lib/ $ ln -s /usr/share/xsom/lib/xsom.jar lib/
Teraz już jesteśmy gotowi do napisania klasy korzystającej z danych (src/net/nelchael/jaxb/Projekt.java):
package net.nelchael.jaxb;
import java.io.File;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import net.nelchael.jaxb.generated.Dane;
import net.nelchael.jaxb.generated.ObjectFactory;
import net.nelchael.jaxb.generated.TypeId;
import net.nelchael.jaxb.generated.TypeOsoba;
public class Projekt {
public static void main(String[] args) {
try {
JAXBContext context = JAXBContext.newInstance(ObjectFactory.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
Dane dane = (Dane)unmarshaller.unmarshal(new File("sample.xml"));
for (TypeOsoba osoba : dane.getOsoba()) {
System.out.println("Osoba: " + osoba.getNazwisko() + ", " + osoba.getImie());
TypeId id = osoba.getId();
System.out.print(" Pesel: " + id.getPesel());
if (id.getDowod() != null)
System.out.print(", dowód osobisty: " + id.getDowod());
System.out.println();
}
} catch (JAXBException e) {
e.printStackTrace();
}
}
}
Na tym etapie przyda się już plik build.xml dla Ant:
<?xml version="1.0"?>
<project name="jaxb" default="compile">
<path id="globalClassPath">
<fileset dir="lib/" includes="*.jar"/>
<pathelement path="bin/"/>
</path>
<taskdef name="xjc" classname="com.sun.tools.xjc.XJC2Task" classpathref="globalClassPath"/>
<target name="xjc">
<xjc schema="sample.xsd" package="net.nelchael.jaxb.generated" destdir="src/"/>
</target>
<target name="compile">
<javac target="1.5" source="1.5" srcdir="src" destdir="bin/" encoding="UTF-8" classpathref="globalClassPath"/>
</target>
<target name="clean">
<delete verbose="true" dir="bin/net"/>
</target>
<target name="run">
<java classpathref="globalClassPath" classname="net.nelchael.jaxb.Projekt"/>
</target>
</project>
Wszystko gotowe, więc uruchamiamy XJC, ...
$ ant xjc
... kompilujemy projekt, ...
$ ant compile
... w końcu uruchamiamy:
$ ant run
Spodziewany wynik:
$ ant run
Buildfile: build.xml
run:
[java] Osoba: Kowalski, Jan
[java] Pesel: 00000000000
[java] Osoba: Kowalska, Janina
[java] Pesel: 00000000001, dowód osobisty: AAA00000
BUILD SUCCESSFUL
Total time: 2 seconds
$
Jak widać korzystanie z JAXB w Gentoo jest dość proste - wszystkie potrzebne biblioteki są już w portage, wystarczy zainstalować ;) Bardzo dobry tutorial dotyczący Web services jest na stronie Sun'a.
Niedługo postaram się umieścić podobny tutorial, ale dotyczący JiBX.
Zieeeeeeeeeeeeeef ... JWSDP w wersji OpenSource dodane do portage :)
Taki mały feature request - ciekawe czy wejdzie do SVN :)
W acpi4asus już jest obsługa A3E, ale... no właśnie - zawsze jest jakieś "ale". Włączanie i wyłączanie RF kill switch'a dalej nie działa - plik /proc/acpi/asus/wled jest bezużyteczny. Kombinacja Fn + F2 tylko wyłącza WiFi, więc też pożytku z tego nie ma. Wczoraj przez przypadek właśnie wyłączyłem sobie WiFi... a Windows nie mam. Jedyne wyjście to dłubanie w kodzie.
W kodzie acpi4asus nic ciekawego nie znalazłem, więc została jedna opcja: /proc/acpi/dsdt - po paru godzinach czytania tego, sprawdzania co po co i dlaczego udało mi się to poprawić. Łatka dla dsdt.dsl jest wręcz trywialna - ot Asusowi nie chciało się zaimplementować jednej funkcjonalności... smutne, ale prawdziwe.
Łatkę można znaleźć na mojej stronie d.g.o, dokładny opis na stronie Genoo on Asus A3E-5018. Amen - działa :)
Od kawałka czasu rozwija się taki mały projekt... mod_npy - troszkę inne podejście do Pythona i dynamicznych stron.
Tak może wyglądać przykładowa strona:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>t1001.pyml</title>
</head>
<body>
<p><b>Test 1001:</b></p>
<p>This test uses Python to display simple <i>Hello World!</i> message:</p>
<p style="color: green; font-size: xx-large; font-weight: bold;">
<?py
import response
response.out("Hello World!")
?>
</p>
</body>
</html>
No właśnie - stack trace wygląda w Javie bardzo ładnie... a w C++ nie. Można sobie napisać coś takiego, ale nie jest to ładne - wymaga dodatkowej linijki w każdej metodzie/funkcji ;)
Zaczynamy od jle.h:
#ifndef __jle_h__
#define __jle_h__
#include <exception>
#include <QStack>
#include <QString>
extern void stackPush(QString);
extern QStack<QString> getStack(void);
/**
* Base class for other exceptions.
*
* @author Krzysiek Pawlik
*/
class Exception: public std::exception {
protected:
QString message;
public:
Exception(QString m) throw(): exception(), message(m) {}
Exception(const Exception &e) throw(): exception(), message(e.message) {}
virtual ~Exception() throw() {}
QString getMessage() {
return message;
}
void printStackTrace(void) {
QStack<QString> q = getStack();
if (q.isEmpty())
return;
fprintf(stderr, "%s\n", q.pop().toStdString().c_str());
while (!q.isEmpty())
fprintf(stderr, " from %s\n", q.pop().toStdString().c_str());
fflush(stderr);
}
};
#ifdef EBUG
#define TRACE { stackPush(QString("%1 [%2]").arg(__PRETTY_FUNCTION__).arg(__FILE__)); }
#else
#define TRACE
#endif
#endif
Następnie jle.cpp:
#include <QStack>
#include <QString>
static QStack<QString> stack;
void stackPush(QString aFunc) { stack.push(aFunc); }
QStack<QString> getStack(void) { return stack; }
Teraz wystarczy mały test:
#include <jle.h>
class TestClass {
public:
static void d(QString a) { TRACE throw Exception(a); }
};
namespace tttt {
void c(int) { TRACE TestClass::d("AAA"); }
}
void b() { TRACE tttt::c(1); }
void a() { TRACE b(); }
int main(void) {
TRACE
try {
a();
} catch (Exception e) {
e.printStackTrace();
}
return 0;
}
Kompilować oczywiście należy toto z -DEBUG. Wynik jest taki:
static void TestClass::d(QString) [test.cxx] from void tttt::c(int) [test.cxx] from void b() [test.cxx] from void a() [test.cxx] from int main() [test.cxx]
Jedyna wada: makro TRACE.
Żeby to było można wykorzystać w projektach trzeba zrobić zdejmowanie ze stosu, hint: zmienne lokalne.
*ncpufreqd-2.2 (23 Nov 2006) 23 Nov 2006; Krzysiek Pawlik <nelchael_AT_gentoo.org> +ncpufreqd-2.2.ebuild: Version bump.
Zapraszam do testowania net-im/jabberd-2.0.11-r1. Lista zmian jest dość spora. Najlepiej porównać ebuildy dla wersji 2.0.11-r1 z 2.0.11. Z ważniejszych zmian: nowy plik jabberd w /etc/init.d/ - nie ma już problemów z uruchamianiem i zatrzymywaniem serwera.
Proszę osoby używające net-im/jabberd-1.4* o testowanie wersji net-im/jabberd-1.4.4-r3. Wersja ta jest aktualnie zamaskowana właśnie w celu lepszego przetestowania. Wprowadza szereg zmian:
- lepsze skrypty startowe - nie występuje już błąd kiedy jabberd zwracał błąd a skrypt oznajmiał sukces
- poprawiony błąd związany z OpenSSL 0.9.8 - poprzednie wersje (<1.4.4-r3) nie działają z włączonym SSL
- zmiana nazwy pliku konfiguracyjnego - jabberd.xml
- poprawiony błąd, kiedy serwer dostawał SIGSEGV lub SIGABRT podczas łączenia się użytkownika
- usunięcie xdb_ldap - martwy upstream
- ebuild jest gotowy na nadejście jabberd-1.5.0
- usunięta zależność od net-im/aim-transport - aim-transport nie kompiluje się dla GCC4, nie jest już rozwijany
- posprzątane flagi USE
Nowe błędy należy zgłaszać tak aby blokowały błąd 149358.
Yesterday (9 September, 20:00 CEST, 14:00 EST), the Java team held a meeting, The agenda for the meeting is available at http://overlays.gentoo.org/proj/java/wiki/September_2006_Meeting_Outline. This summary follows the format of the agenda.
- Personel updates
First task was to aquire information about active developers who work with Java related ebuilds, it produced following list:
- betelgeuse (Petteri Räty)
- caster (Vlastimil Babka)
- gurligebis (Bjarke Istrup Pedersen)
- nelchael (Krzysiek Pawlik)
- nichoj (Joshua Nichols)
- sanchan (Sandro Bonazzola)
- wltjr (William Thomson)
More details about areas of responsibility are available in meeting notes.
Missing developers:
- compnerd (Saleem Abdulrasool)
- karltk (Karl Trygve Kalleberg)
- zx (Chris Aniszczyk)
Second task was to establish a list of developers along with architectures with which they can work:
- alpha - no support for Java
- amd64 - nichoj, sanchan
- arm - no support for Java
- hppa - no support for Java
- ia64 - nichoj
- m68k - no support for Java
- mips - no support for Java
- ppc - nelchael, nichoj
- ppc-macos - no support for Java
- ppc64 - nichoj
- s390 - no support for Java
- sh - no support for Java
- sparc - no support for Java
- x86 - all Java team developers
- x86-fbsd - gurligebis
It was decided to drop support for dev-java/compaq-jdk and dev-java/compaq-jre on alpha - those two packages don't work as expected and are not supported by upstream. Sparc and alpha wait for fully working free Java JDK/JRE (kaffe, gcj and gnu-classpath for example).
- Migration to the new Java system
It was decided that no new features will be added to 'core' Java packages to allow proper testing and bug fixing. We are targeting 14 October for stabilizing core packages, list of core packages is available at Java Upgrade Guide under "Code Listing 2.1: package.keywords". There was also talk about what features are planned to make their way into java-config before feature freeze, for example --tools option to get location for tools.jar from currently selected VM.
Current status of migration (list of not migrated ebuilds, progress graph) is available at status page along with 'current' state at not-migrated-current.
- Feature requests
Only one point made it's way into "Feature requests": virtuals for several Java packages: javamail, jaf and others. To better understand the problem lets take a look at packages that could provide virtual/javamail:
- dev-java/sun-javamail-bin
- dev-java/gnu-javamail
- dev-java/sun-javamail (currently in Java overlay)
Same situation is with JAF (JavaBeans Activation Framework). Decision about virtuals was postponed as minor issue, since it can wait until after the new Java system is stablized.
- Documentation
It was decided that the Java Upgrade Guide needs to be updated and it needs to list possible upgrade paths. Additionally following documents need work:
Following documents need to be created:
- How to be a good downstream - document decribing best practices about handling Java
- Guide to using maven in ebuilds - this document is currently blocked by not complete maven ebuilds (see 'Future plans')
We are also looking for articles that cover Java support on Gentoo.
- QA / static analysis tools
Using die after eant in ebuilds has been deprecated: eant dies on it's own, so:
eant ... || die "eant failed"
should be changed just to:
eant ...
New checks for usage of old eclasses and other QA issued are pending inclusion in repoman. Additionaly pcheck will probably be implemented as repoman modules after repoman gains ability to use such modules, not as separate tool. Eclipse plugin for writing ebuilds (and performing QA checks) was started by zx, but is currently unreleased. Gentoo user benny^work was also interested in such plugin, but current state of this effort is unknown. Developer wltjr suggested making such plugin also for Netbeans. One possible way of creating such plugin (aside from implementing syntax highlighting) is to use Jython to use checks from repoman.
- Future plans
One controversial step, split of dev-java into more smaller categories, was postponed for now. It will be reconsidered after stabilizing new Java build system.
Additional third quiz will be required for new developers that want to join Java team due to specifics of Java builds. Such quiz would have few general questions about Java, handling classpath and ant builds.
State of maven on Gentoo was given by nelchael, and is available in attached log. We are currently waiting for 2.0.5 release of maven to build it from source and allow ebuilds to use it to build other software. For now it is required to use `mvn ant:ant` to obtain build.xml file for ant, which can be used in ebuilds.
Last two points of agenda: Java 1.6 and Java 1.7 were discussed. There was talk about how to prepare for upcoming release of Java 1.6 in October (that date is not fixed - it may change), troubles with JDBC drivers as Java 1.6 introduces new functions, which breaks compilation of current JDBC3 drivers. Testing of Java 1.7 has been postponed until 1.6 comes out.
- Not on agenda
Following topics were mentioned that were not on agenda:
- Estimated EOL (end of life) for generation 1: until all ebuilds are migrated to generation 2 and stabilized we have to keep generation 1 alive in tree
- packages that break due to generation 2:
- dev-java/jarjar
- dev-libs/cyrus-sasl
- kde-base/kdejava
- kde-base/qtjava
- app-accessibility/gnome-speech
- contacting David Herron (Sun employee, who helped to bring DLJ licensed Sun JDK to potage) about packaging and distribution of other Sun Java packages, for example Sun JWSDP, JAF, Javamail
Tym razem wygrał błąd numer 146298 - Please add block between gtk and qt ;)
Jest taki fajny programik speed.c autorstwa Andrew Tridgell (większość osób powinna go kojarzyć z dwoma faktami: Samba i rezygnacja z BitKeepera).
Wyniki z Power Macintosh G4 400MHz, 256MB RAM:
nelchael@g4 ~$ gcc -w speed.c -o speed -lm nelchael@g4 ~$ ./speed Floating point - sin() - 1.79562 MOPS Floating point - log() - 1.42438 MOPS Memcpy - 1kB - 677.235 Mb/S Memcpy - 100kB - 382.534 Mb/S Memcpy - 1MB - 123.622 Mb/S Memcpy - 10MB - 111.976 Mb/S Adding integers - 24.6707 MOPS Adding floats (size 4) - 20.7374 MOPS Adding doubles (size 8) - 20.755 MOPS nelchael@g4 ~$
Teraz z Asus A3E Pentium M 1.73GHz, 1024MB RAM:
nelchael@nelchael tmp$ gcc -w speed.c -o speed -lm nelchael@nelchael tmp$ ./speed Floating point - sin() - 10.2722 MOPS Floating point - log() - 8.93336 MOPS Memcpy - 1kB - 3726.31 Mb/S Memcpy - 100kB - 4333.27 Mb/S Memcpy - 1MB - 371.949 Mb/S Memcpy - 10MB - 185.921 Mb/S Adding integers - 77.4397 MOPS Adding floats (size 4) - 75.1869 MOPS Adding doubles (size 8) - 77.0696 MOPS nelchael@nelchael tmp$
Jak widać laptop wypada dużo lepiej. Zabawa mimo wszystko zaczyna się jak dodamy odpowiednie CFLAGS:
nelchael@g4 ~$ gcc -w -O2 -mcpu=G4 -mtune=G4 -mabi=altivec speed.c -o speed -lm nelchael@g4 ~$ ./speed Floating point - sin() - 1.92864 MOPS Floating point - log() - 1.52982 MOPS Memcpy - 1kB - 685.179 Mb/S Memcpy - 100kB - 362.496 Mb/S Memcpy - 1MB - 123.328 Mb/S Memcpy - 10MB - 112.338 Mb/S Adding integers - 131.704 MOPS Adding floats (size 4) - 131.005 MOPS Adding doubles (size 8) - 131.648 MOPS nelchael@g4 ~$
oraz:
nelchael@nelchael tmp$ gcc -w -O2 -march=pentium-m speed.c -o speed -lm nelchael@nelchael tmp$ ./speed Floating point - sin() - 10.7608 MOPS Floating point - log() - 10.01 MOPS Memcpy - 1kB - 4544.19 Mb/S Memcpy - 100kB - 4457.39 Mb/S Memcpy - 1MB - 1526.44 Mb/S Memcpy - 10MB - 458.888 Mb/S Adding integers - 816.131 MOPS Adding floats (size 4) - 197.516 MOPS Adding doubles (size 8) - 212.36 MOPS
Jak widać operacje na liczbach zmiennoprzecinkowych na PPC wypadają lepiej :) Argh... źle były CFLAGS (pentium4 zamiast pentium-m) :]
Brakowało mi wygodnego i ładnego informowania o głośności jak ją reguluję klawiszami na laptopie... więc już jest - nazywa się sound-status. Jak to wygląda?
Jeśli ktoś chce się pobawić (narazie brak dokumentacji) to zapraszam: Nelchael's Dev Overlay.
Czarne/szare tło jest z mojej tapety :]
Wow... liniowy spadek:
;)
Dzięki tuzi'emu mam teraz tak:
tuzi... dzięki :)
Zainteresowanych odsyłam do Nelchael's Dev Overlay.
Hm... podobno lepsze... tia...
Po pierwsze - ikony...
Czy coś jest nie tak, czy tylko mi się wydaje? Ech...
Po drugie - Bluecurve - screenshot ten sam co powyżej - dlaczego to nie wygląda tak samo jak w Fedora Core? Powinno wyglądać to tak - polecam szczególnie zwrócić uwagę na progress bar. U mnie jest on gradnientowy, o taki:
Ech... ktoś wie?
PS. Mam zainstalowane:
nelchael@nelchael ~$ emerge -p gtk+ redhat-artwork These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/gtk+-2.10.0 [ebuild R ] x11-themes/redhat-artwork-0.243-r1 Total size of downloads: 0 kB nelchael@nelchael ~$
Mały "cosik" dla osób pracujących na Gentoo w Eclipse ;)
Dodawanie do projektu pojedyńczych plików JAR może być upierdliwe (a conajmniej uciążliwe). Można to zautomatyzować korzystając z User Libraries. Jednak znowu pojawia się problem ręcznego dodawania plików JAR. A gdyby tak mieć to zautomatyzowane i tworzyć po jednej "user library" na pakiet w Gentoo? Oto jak to zrobić:
- pobieramy generate-userlibraries.sh
- uruchamiamy:
generate-userlibraries.sh > tmp.userlibraries
- importujemy ten plik w Eclipse w
Window -> Preferences -> Java -> Build Path -> User Libraries -> Import
Update: Opera i Konqueror mają to samo - wychodzi na to, że "it's a feature, not bug." - whatever ;)
Yay!
:) Migracja do Generation 2 zakończona :) Teraz pozostało przenieść ebuily, które są dalej dla generation 1 do 2 ;) A troszkę tego jest :]