[72662 views]

[]

[toggle ads]

Odi's astoundingly incomplete notes

New Entries

Do not use Xerces, Xalan any more!

For years Java developers were used to require Apache Xerces and Xalan for their XML stuff. But those times are over. All this stuff is no longer necessary in modern JDKs (since at least 1.6 basically) and it does more harm than good to have these jars in your classpath or endorsed libs!

The problem is that the Internet is littered with references to Xerces and that even their Website is totally misleading. If you read that stuff you would believe that this is actually usefull code. But it isn't any more!

The first sentence on the website is "Welcome to the future!". But that's from at least 2010! The classes in xml-apis.jar are from 2009! All the code is build for JDK 1.3! Come on! Anybody who is still running 1.3 already has a lot of problems with the memory model / thread synchronization, let alone security issues! xml-apis contains ancient versions of JDK standard classes. For instance XMLStreamException doesn't even initialize the Exception's cause field, getting you nothing but incomplete stack traces.

I really wonder why this project can't get around to admit that it is effectively dead. They should really put a big fat warning on their website:

DO NOT USE THIS CODE ON MODERN JDKs. THIS IS FOR ANCIENT OR EXOTIC PLATFORMS ONLY,  BASICALLY UNMAINTANED AND SUBJECT TO BITROT.

But no! All that 20 year old documentation still tells people to put that crap into the endorsed folder of the JDK where it will turn a perfectly good XML infrastructure into a jurassic version of itself.

These people don't realize how much worldwide developer time they are wasting by keeping this outdated website up!

Please also note that Xerces has security issues when exposed unconfigured to the Internet (webservices!), whereas JDK's built-in JAXP has sane defaults.

If your project still has Xerces, you should migrate away from it now. Chances are that you hard-coded some stuff on top of Xerces (like validation, feature strings, parser options, etc.). Use the modern JAXP equivalents!
posted on 2015-03-09 11:55 CET in Code | 0 comments | permalink

git: Dangerous default settings in Eclipse

When Eclipse imports a GIT repository, it sets some defaults that I can only describe as outright dangerous:

This setting means that each pull operation will fetch changes for all remote branches and merge them. This is totally unintuitive: it modifies stuff outside of the currently check-out branch. And it is the oposite of the command line git behaviour: you need explicitly specify if you wanted to fetch different branches (git fetch origin somebranch:somebranch)

If you happen to work with many work directories (one for each branch) that are based on the same git repository (git-new-workdir), that one click can get you into a lot of trouble if you are not ready to pull everywhere.

posted on 2015-03-03 19:00 CET in Code | 0 comments | permalink

Recent Gentoo is safe from GHOST

I ain't afraid of no GHOST.

According to Heise the GHOST vulnerability only affects glibc before 2.18. Uptodate Gentoo installations run 2.19 and are not affected.
# equery l glibc
 * Searching for glibc ...
[IP-] [  ] sys-libs/glibc-2.19-r1:2.2

posted on 2015-01-28 14:09 CET in Code | 0 comments | permalink

Gentoo to require initramfs

A Portage news item announces today that Gentoo is about to upgrade to udev-217. This upgrade will eliminate the userspace firmware loader. The change requires not only a kernel config change (CONFIG_FW_LOADER_USER_HELPER=N). It also may require an initramfs, if the kernel has drivers built-in that want to load firmware before the root filesystem is mounted. Examples of such drivers are: iwlwifi (Intel WiFi chips) or bnx2 (Broadcom NetXtreme II). Without userspace fw loading these drivers will fail to load their firmware. The standard solution to this problem is to use an initramfs.

A module-less initramfs is sufficient for that case (modules are built-in already), and it can easily be shared among different kernels.


posted on 2014-11-10 10:30 CET in Code | 0 comments | permalink

interactive diff merge on the console

To quickly compare and merge files ver1 and ver2 and save the result as merged:
sdiff -s -o merged ver1 ver2
It's the command that Gentoo's etc-update uses.
posted on 2014-09-18 18:20 CEST in Code | 0 comments | permalink

Gentoo fails to build dev-libs/boost-1.52.0-r7

If you get this:
ln -f -s 'libboost_wave.so.1.52.0' 'stage/lib/libboost_wave.so'

...failed updating 1 target... 

Then put this into your /etc/portage/package.use:
# boost 1.52 is broken with current icu
<dev-libs/boost-1.53 -icu

posted on 2014-08-02 12:31 CEST in Code | 1 comments | permalink
Just to ser how it is done. Nice work.

iOS and hostapd

If you want iOS devices to connect to your hostapd AP, then you must not configure SHA256. Unbelievable, Apple! You get offered a choice between two options and you just decide to fail?!?

#wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256
wpa_key_mgmt=WPA-PSK


posted on 2014-07-30 22:35 CEST in Code | 0 comments | permalink

How not to design an API

Reading up on how to remotely connect to a JMX port, I wonder how one can possibly design such a horrible API. According to that document you need to create an URI string and pass that to the API. The URI string looks like this:
service:jmx:rmi:///jndi/rmi://hostName:portNum/jmxrmi
Utterly unintuitive, error prone and unreadable. And why assemble an URI string, pass it through an underpowered API and then parse that apart in the implementation again? Like somebody deliberately wanted to piss people off.

It could have been as simple as this:
JMXConnectorFactory.connect(host, port);
Because that's all people normally do! Yes, there may be one person in the Universe that wants to exchange the RMI transport with something else. But the API makes everybody pay with that:
MXServiceURL u = new JMXServiceURL(
  "service:jmx:rmi:///jndi/rmi://" + hostName + ":" + portNum +  "/jmxrmi");
  JMXConnector c = JMXConnectorFactory.connect(u);

posted on 2014-07-14 09:59 CEST in Code | 0 comments | permalink

Preventing systemd on Gentoo

With the latest upower upgrade portage may pull in systemd. If you are like me and think that systemd has grown beyond what it should do and you don't want it, do this:

/etc/portage/package.mask:
sys-apps/systemd
Then replace upower with the compatibility layer:
emerge -C sys-power/upower
emerge -1 sys-power/upower-pm-utils

posted on 2014-06-03 13:25 CEST in Code | 1 comments | permalink
Thank you! I really don't like systemd and the attitude of its developers. It just seems horrible all around, so thanks for helping me not install it on Gentoo!

bnx2 firmware and PXE bootable kernel

I am building a Linux kernel that is booted via the network with PXE. The machine that runs it has a Broadcom network card that uses the bnx2 driver. That card needs firmware to function, which is normally loaded into the card by udev.

As the kernel boots it obtains an IP via DHCP and mounts its root file system over NFS. For that it needs a working network card and hence the firmware. Of course the firmware can not be on NFS and there is no udev to load it yet. Hence the kernel must load it. If you don't want an initramfs (because it's a PITA to build), you need to build the firmware into the kernel.

The kernel has config options to build firmware blobs into the kernel. They are found under:
 Device Drivers
   Generic Driver Options
     [*] Include in-kernel firmware blobs in kernel binary
     () External firmware blobs to build into the kernel binary
     (/lib/firmware) Firmware blobs root directory
and they map to the .config variables FIRMWARE_IN_KERNEL, EXTRA_FIRMWARE and EXTRA_FIRMWARE_DIR.

EXTRA_FIRMWARE is a space separated list of file names of the firmeware blobs.
EXTRA_FIRMWARE_DIR is a slash terminated directory where those files are.

Now you first need to know which versions of these files are requested by the driver:
# cd drivers/net/ethernet/broadcom/
# grep \\.fw bnx2.c
#define FW_MIPS_FILE_06         "bnx2/bnx2-mips-06-6.2.3.fw"
#define FW_RV2P_FILE_06         "bnx2/bnx2-rv2p-06-6.0.15.fw"
#define FW_MIPS_FILE_09         "bnx2/bnx2-mips-09-6.2.1b.fw"
#define FW_RV2P_FILE_09_Ax      "bnx2/bnx2-rv2p-09ax-6.0.17.fw"
#define FW_RV2P_FILE_09         "bnx2/bnx2-rv2p-09-6.0.17.fw"
So you should list exactly these names in EXTRA_FIRMWARE. To make it extra difficult the kernel itself doesn't even contain these versions:
# ls firmware/bnx2
bnx2-mips-06-6.2.1.fw.ihex   bnx2-rv2p-06-6.0.15.fw.ihex  bnx2-rv2p-09ax-6.0.17.fw.ihex
bnx2-mips-09-6.2.1a.fw.ihex  bnx2-rv2p-09-6.0.17.fw.ihex
But fortunately the firmware is distributed separately and should already be in /lib/firmware. On Gentoo these files are installed by the ebuild sys-kernel/linux-firmware.
# ls /lib/firmware/bnx2
bnx2-mips-06-4.6.16.fw     bnx2-mips-09-5.0.0.j3.fw  bnx2-rv2p-06-6.0.15.fw
bnx2-mips-06-5.0.0.j3.fw   bnx2-mips-09-5.0.0.j9.fw  bnx2-rv2p-09-4.6.15.fw
bnx2-mips-06-5.0.0.j6.fw   bnx2-mips-09-6.0.17.fw    bnx2-rv2p-09-5.0.0.j10.fw
bnx2-mips-06-6.0.15.fw     bnx2-mips-09-6.2.1a.fw    bnx2-rv2p-09-5.0.0.j3.fw
bnx2-mips-06-6.2.1.fw      bnx2-mips-09-6.2.1b.fw    bnx2-rv2p-09-6.0.17.fw
bnx2-mips-06-6.2.3.fw      bnx2-mips-09-6.2.1.fw     bnx2-rv2p-09ax-5.0.0.j10.fw
bnx2-mips-09-4.6.17.fw     bnx2-rv2p-06-4.6.16.fw    bnx2-rv2p-09ax-5.0.0.j3.fw
bnx2-mips-09-5.0.0.j15.fw  bnx2-rv2p-06-5.0.0.j3.fw  bnx2-rv2p-09ax-6.0.17.fw
So you must set EXTRA_FIRMWARE_DIR = /lib/firmware/.

With these options correctly set, such a kernel boots perfectly over PXE.


posted on 2014-05-02 16:56 CEST in Code | 1 comments | permalink
merci Odi