Odi's astoundingly incomplete notes
New entriesCode
back | nextrenice a tty
Quickly renice all processes of a tty:
ps -t pts/1 | awk 'NR>1 { print $1; }' | xargs renice 10 -pAdd comment
add bridge failed: Package not installed
$ brctl addbr br0 add bridge failed: Package not installed $ gunzip < /proc/config.gz | grep BRIDGE # CONFIG_BRIDGE is not setSo that's the most silly way to say: you forgot to compile in bridge support into your kernel. "package not installed" tsk!
Add support bridge from kernel:
it option have to be enable "802.1d Ethernet Bridging"
it option have to be enable "802.1d Ethernet Bridging"
Thank's for the information, it was helpful :)
Thanks! That was very useful! It also shows up when you upgrade the kernel and forget to reboot (the module doesn't load and this surprising message appears).
Thanks a bunch!
Helped me too - cheers!
Thanks! :)
Thanks dude!
This option have to be enabled "802.1d Ethernet Bridging" => Thanks !
I had this error after loading a development module and doing a depmod -a and then crashing right away. A repeat of depmod -a cleaned up the symbol xref files and everything was happy again.
I am getting the same issue. Not sure how to fix it. Any ideas?
DataOutputStream 64KB limit
Did you know that you can not serialize Strings >64KB through a DataOutputStream?
if (utflen > 65535)
throw new UTFDataFormatException(
"encoded string too long: " + utflen + " bytes");perf docs
A sign of over-engineering...
... when an interface has only a single implementation.
When you discover them it is worth rethinking if that interface is really worth it and whether that apparent flexibility is really desired or necessary.
When you discover them it is worth rethinking if that interface is really worth it and whether that apparent flexibility is really desired or necessary.
NTLM support in HttpClient merged
After years of legal uncertainity it is now finally possible to include NTLM implementations in Apache software. Also the Http Components and formerly HttpClient had continuously refused to include any (more) NTLM code, or the LGPL jcifs library. Today Oleg has finally merged a patch that supports NTLM v1, v2 and NTLM 2 as authentication mechanisms. This looks like a big milestone for people that rely on NTLM as their primary authentication mechanism.
line wrapping with xconsole
I am using xconsole to display the syslog. I was annoyed that long lines from iptables went offscreen because they are very long. Now fortunately xconsole is an old-school X11 program. According to its man page it uses the Athena Widget Set. X11 programs accept so called Xresources, which to an X11 GUI are nothing more than what CSS is to HTML.
The Xresources file is in your home directory:
There is another old-school program
Taking a look at the Athena documentation on page 95 we quickly find that the only 3 values are
So firing up vim and putting the following line into our .Xresources file will do the word wrapping trick:
The Xresources file is in your home directory:
~/.XresourcesThere is another old-school program
editres to graphically inspect and edit Xresources. Using that it's easy to find out that the resource we want to modify isxconsole.text.wrap. However this doesn't tell us what kind of values this resource acccepts.Taking a look at the Athena documentation on page 95 we quickly find that the only 3 values are
never, word and line and what they do.So firing up vim and putting the following line into our .Xresources file will do the word wrapping trick:
xconsole.text.wrap: line xconsole*font: fixedSometimes it's worth not to forget the old school...
bluez pairing with Apple wireless keyboard
The new-style bluez utilities are a bit different than the old ones. Here is how to pair an Apple Wireless Keyboard with the command line utilities only:
Remove and reinsert the batteries from the keyboard. Turn the keyboard on. The light should be flashing.
In a root shell do:
Remove and reinsert the batteries from the keyboard. Turn the keyboard on. The light should be flashing.
In a root shell do:
hcitool scan
Scanning ...
11:22:33:44:55:66 Apple Wireless Keyboard
simple-agent hci0 11:22:33:44:55:66
Type a PIN (any four numbers) followed by Enter on the keyboard. Enter the PIN into the simple-agent shell when prompted. The keyboard is paired now. Now trust and connect the device:bluez-test-device trusted 11:22:33:44:55:66 yes
bluez-test-input connect 11:22:33:44:55:66
Why you never develop on a branch
I always tell my fellow coders: never develop new features on a branch.
By branch I mean a stable release CVS branch. That is usually a bit "old". Trunk is quite volatile. New concepts are introduced, old ones removed. Refactoring occurs on the trunk.
So if you start to build something on the old branch and then port it to trunk, your code may be based on old/deprecated concepts and will fail to support new features correctly.
Another factor is human errors: forgetting to port a patch between branches. If you develop on the branch, your customer is happy. But in the next release he will be unhappy when he notices that a change has been lost. If you develop on the trunk you get immediate feedback from a customer when you forget to backport a change.
In general it's easier to write the code for trunk and then backport it to the branch world. Also the backport should happen gradually and not as a big bang.
By branch I mean a stable release CVS branch. That is usually a bit "old". Trunk is quite volatile. New concepts are introduced, old ones removed. Refactoring occurs on the trunk.
So if you start to build something on the old branch and then port it to trunk, your code may be based on old/deprecated concepts and will fail to support new features correctly.
Another factor is human errors: forgetting to port a patch between branches. If you develop on the branch, your customer is happy. But in the next release he will be unhappy when he notices that a change has been lost. If you develop on the trunk you get immediate feedback from a customer when you forget to backport a change.
In general it's easier to write the code for trunk and then backport it to the branch world. Also the backport should happen gradually and not as a big bang.
WS implementors
Next time you implement a webservice framework, please:
back
|
next
- make it difficult to produce invalid SOAP messages. Your generated SOAP messages should conform to the schema and mapping in the WSDL.
- make sure you escape XML correctly. Use an XML infrastructure, not string operations.
- support all features of XML schema, not just a subset
- make sure you handle namespaces correctly
- make sure you handle nil, empty elements and optional elements correctly and in a simple way for the user
- certain attributes in schema definitions have standardized defaults. Make sure you use them in the absence of these attributes.
- make sure you handle timezones in dates/times correctly
- generate code from WSDL. Never generate WSDL.
- issue useful error messages from your utilities instead of just crashing
- make the generated code look nice.
- use the documentation from the WSDL as API doc.
- make the generated code useful for a programmer
- don't try to hide something behind a mapping infrastructure. Someone will have to go down and do the dirty work one way or another. A mapping file is not better than code.
- give the programmer also access to the raw SOAP message. Preferably both as string and parse tree
- make message logging simple and let the programmer choose to log it in any other way
- east shit, poo gold
- if you fail to do that, don't call your product WS-capable. You can just as well use a proprietary binary protocol because your broken WS implementation will never be able interact with the real world.