Parolski.com

Oracle recently made a set of presentations which outlined what their strategy was in terms of hardware, software, markets etc.. Each speaker had a slide show to accompany their talks, and each of the slideshows was quite extensive.

Well, all but one. Larry’s!

His slideshow has one slide; a picture of a racing yacht with Oracle and Sun logos on it! This for me sums up his character. Hes got a ton of energy and sees his company more like something that he needs to guide and be successful with, and at the same time looks good whilst doing it!

In this respect, Oracle have made it very clear what they want to do with the portfolio they have acquired from Sun, and this does include investing heavily in SPARC processors. Given the kind of performance we saw with the T1000 on Heanets review, I’m personally looking forward to the day when Oracle manage to further commoditise this cool hardware

This little box seems to be quite far ahead of its time. I can imagine that there must be so many futurologist out there just waiting to see their ideas come into the mainstream, and then jump for joy when it finally does!

It has been announced today that approval has finally been given for Oracle to merge with Sun Microsystems. The process began in September 2009 which means that its been long enough for plenty of rumours to go around about whats going to happen both internally with head count cuts, and of course with the product line itself. Most importantly, the people with power to make decisions in these two structures now actually have the opportunity to go ahead and make those decisions.

If Larry is true to his word about what he sees for the future of the Sun product line, I for one would certainly say that the future is going to be fairly bright.

Mr Ellisons (CEO of Oracle) own words:

“We are keeping everything. We are keeping tape, we are keeping storage, we are keeping x86 technology, we’re keeping SPARC technology, we’re going to increase the investment in it…”

“…we are NOT going to spin anything off.”

The discussions about improving data center power consumption efficiency and increasing demand for online services place the T-series equipment very well for those who know just how good they are. Coupled with the fact that Sun had famously invested early in the R+D for this kind of technology, theres also a great opportunity to get OpenSolaris beefed up in terms of packages and installers, and deployed in these environments.

I’m looking forward to seeing how its all going to pan out!

Python comes with an HTTP server built in, making sharing directories on your *nix machines as easy as:

anton@opensolaris:~/mess/test$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 …
localhost – - [26/Sep/2009 00:23:47] “GET / HTTP/1.0″ 200 -
localhost – - [26/Sep/2009 00:24:24] “GET / HTTP/1.1″ 200 -

So now when we go to localhost:8000 , we get the directory!:

anton@opensolaris:~/mess$ lynx -dump localhost:8000
Directory listing for /
__________________________________________________________________

* [1]lalala
__________________________________________________________________

References

1. http://localhost:8000/lalala

…or…

anton@opensolaris:~$ lynx -source localhost:8000
<title>Directory listing for /</title>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href=”lalala”>lalala</a>
</ul>
<hr>

…for those of you that want to see the source it produced! A very quick short term solution if you don’t want to go about setting up apache or change your apache settings!

Ten days ago we had a look at Java’s ability to deal with numbers which had alot of decimal places. Liam pointed out that having to loop through a variety of operations is longer than performing a more efficient operation once.

With Liams magical formula, we get the following Java, with no loop:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import java.math.BigDecimal;
 
public class The_proper_half {
 
    public static Integer times_to_loop;
 
    /**
     * @param args the number of times you want to run the loop
     */
    public static void main(String[] args) {
        calculate(Integer.valueOf(args[0]));
 
    }
 
    public static void calculate(int times_to_loop) {
        //The Number we want to half
        BigDecimal number_to_half = new BigDecimal("10");
        //The result of doing the half
        BigDecimal the_half = new BigDecimal("0");
        //The number we want to divide by
        BigDecimal divider = new BigDecimal("2");
 
        the_half = (number_to_half.divide(divider.pow(times_to_loop)));
 
        System.out.println("The last number has " +
                ((Integer) number_to_half.subtract(the_half).toString().length()
                - 2) + " decimal places: ");
 
        System.out.println(number_to_half.subtract(the_half));
    }
}

As you can see, we only perform the opertation once (line 23), but admitadly, to get the correct number at the end, we still do the subtraction at the end!

Regarding optimisation, there are huge benefits. It turns out that the old way if hugely costly for thousands of iterations. These are the results for 10000 iterations, the old way:

anton@anton-laptop classes $ time java Half_of_a_half 10000 > /dev/null

real    5m22.714s
user    5m21.320s
sys    0m1.052s

The results for the new way are much better:

anton@anton-laptop classes $ time java The_proper_half 10000 > /dev/null

real    0m1.019s
user    0m1.248s
sys    0m0.052s

So it went from over five minutes, down to just a second. That was just by changing from a loop a single statement. Thats pretty cool stuff!

I have to admit here, the difficult bit is probably not the code. Its the abillity to see how a problem may be translated from one way of expressing it to another. Its that bit of genius thats really done the work here. Credit to Liam for the genius!

This is a common riddle, so if you’ve heard it, don’t shout out the answer (people might think your strange for shouting at the internet….)

Take a number. Then, half that number. Then half that half and add it to the first half. Before that gives people a headache, lets do a little example:

Lets use 10 . Then half of ten gives us 5. Then, half five (2.5) and add it to the first half, 5. This gives us 7.5

Continue to half the last half, adding it to the sum of the previous halves. Phew, I hope thats explained properly.i.e. half two point five, and add it the the 7.5 we already have, which give us 8.25

Okay, so the question is this. If we keeping adding on the halves, will we ever reach 10 again? Well, I like Java, so lets get all geeky and model the problem. For this, the double and float data types won’t give us enough decimal places. For this, we’ll need: math.BigDecimal . The Big Decimal. Sounds ominous!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import java.math.BigDecimal;
public class Half_of_a_half {
 
    public static Integer times_to_loop;
 
    /**
     * @param args the number of times you want to run the loop
     */
    public static void main(String[] args) {
        calculate(Integer.valueOf(args[0]));
    }
 
    public static void calculate(int times_to_loop) {
        //The Number we want to half
        BigDecimal number_to_half = new BigDecimal("10");
        //The result of doing the half
        BigDecimal the_half = new BigDecimal("0");
        //The number we want to divide by
        BigDecimal divider = new BigDecimal("2");
 
        for (int i = 0; i < times_to_loop; i++) {
 
            number_to_half = number_to_half.divide(divider);
            the_half = the_half.add(number_to_half);
 
            System.out.println(the_half);
        }
        System.out.println("The last number has " +
                ((Integer) the_half.toString().length() - 2) + " decimal places");
    }
}

This code takes a single parameter on the command line: the number of times to half by

e.g.

anton@anton-laptop classes $ java Half_of_a_half 10
5
7.5
8.75
9.375
9.6875
9.84375
9.921875
9.9609375
9.98046875
9.990234375
The last number has 9 decimal places

So as we can see, the decimal places just get long and longer. The additions are never big enough to get us close enough to the original number. Problem solved!

The fun bit is realising the significance of the calculation, or rather, the speed with which it was done. Performing 1000 divisions and additions takes less that 0.2 of a second! Maybe thats not so fast by todays computing ability, but by human standards thats pretty extreme.

anton@anton-laptop classes $ time java Half_of_a_half 1000 > /dev/null


real    0m1.387s
user    0m1.916s
sys    0m0.036s


This post has long code segments in it, so I’ll explain what it all does at the top. Then at the end, just copy paste into your favourite editor/IDE to play with it.

So the title kind of gives it away, but the concept behind it was quite interesting. Imagine you have some kind of resource, like a network connection, a file etc, which is needs to be accessed by many threads, but only one thread at a time. Using synchronized methods achieves this. Its especially handy where you might have hundreds of threads which need to modify the same resource, but should do it, one at a time. This code can do that (although its not perfect by far)

In this example, we have a padlock, which we can open , and close. Of course, we can’t open it whilst its being closed, and vica versa. You could just run the openLock and closeLock methods one after the other, but using threads gives us some bonus features. For example, we might want to open the padlock, get half way through, and then realise we want to pause, leaving the rest of the work for later. Or maybe we want to get halfway through closing the padlock, and then change our mind and open it (i.e. without fully closing it)

So heres the code, enjoy!
The padlock:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

package workingWithSynchronizedThreads;
 
import java.util.logging.Level;
import java.util.logging.Logger;
 
/**
 * This class represents a simple padlock. You know, like the kind you use to
 * lock up your bike. I use it as an example of how we can make fields in
 * java , then try and access them through different threads. Using syncronised
 * methods, we will prevent the lock from being opened whilst were still trying
 * to close it.
 * @author anton
 */
public class padlock {
 
    /**
     * Constructor object to make a new padlock
     * @param isThePadlockOpen Whether the padlock is open or closed
     */
    public padlock(boolean isThePadlockOpen) {
        this.isThePadlockOpen = isThePadlockOpen;
    }
    /**
     * This field tells us whether or not the lock is open or closed (true for
     * open, false for locked)
     */
    public boolean isThePadlockOpen;
 
    /**
     * This method simply sets the padlock to be closed by setting isOpen to false
     * Closing the lock takes two seconds (hence the sleep statements) ).
     */
    public synchronized void closeLock() {
        try {
            Thread.sleep(1000);
            isThePadlockOpen = false;
            System.out.println("I'm closing the lock");
            Thread.sleep(1000);
            tellMeIfThisLockIsOpen();
        } catch (InterruptedException ex) {
            System.out.println("I couldn't close the lock");
            Logger.getLogger(padlock.class.getName()).log(Level.SEVERE, null, ex);
        }
 
    }
 
    /**
     * This method simply sets the padlock to be open by setting isOpen to true.
     * Opening a lock takes two seconds (hence the sleep statements ).
     */
    public synchronized void openLock() {
        try {
            Thread.sleep(1000);
            isThePadlockOpen = true;
            System.out.println("I'm opening the lock");
            Thread.sleep(1000);
            tellMeIfThisLockIsOpen();
        } catch (InterruptedException ex) {
            System.out.println("I couldn't open the lock");
            Logger.getLogger(padlock.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
 
    /**
     * Lets us know if our padlock object is open or closed
     */
    public void tellMeIfThisLockIsOpen() {
        if (isThePadlockOpen == true) {
            System.out.println("The lock is open!");
        } else if (isThePadlockOpen == false) {
            System.out.println("The lock is closed!");
        } else {
            System.out.println("Something is seriously wrong!");
        }
    }
}

The closeLockThread:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package workingWithSynchronizedThreads;
 
/**
 *
 * @author anton
 */
public class closeLockThread extends Thread {
 
    public padlock padlock;
 
    public closeLockThread(Object padlock) {
        this.padlock = (padlock) padlock;
    }
 
    @Override
    public void run() {
        padlock.closeLock();
    }
}

The openLockThread:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package workingWithSynchronizedThreads;
 
/**
 *
 * @author anton
 */
public class openLockThread extends Thread {
 
    public padlock padlock;
 
    public openLockThread(Object padlock) {
        this.padlock = (padlock) padlock;
    }
 
    @Override
    public void run() {
        padlock.openLock();
 
    }
}

Okay, less mess with some threads!!!:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package workingWithSynchronizedThreads;
 
/**
 *
 * @author anton
 */
public class messAroundWithSomePadlocks {
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        padlock myLock = new padlock(true);
        closeLockThread iWannaCloseTheLock = new closeLockThread(myLock);
        openLockThread iWannaOpenTheLock = new openLockThread(myLock);
        iWannaCloseTheLock.start();
        iWannaOpenTheLock.start();
    }
}

The things that need attention are:

1. Do we need to do that casting from padlock to padlock in the openLock and closeLock thread classes?
2. Is it ok/understandable to make a field a question? (public boolean isThePadlockOpen;) ?

The inspiration for this work came from looking at some code were working on in my department, but the learning was really done looking at the Java Tutorials, which are ace!

You can find XMMS in the ports collection, which is great. XMMS will even play you wav files out of the box. To get mp3s to play, you’ll need to do a little bit more work and also install:

xmms-mad

which you can find in /usr/ports/audio (presuming thats where you put your ports files)

In unix pretty much everything is a file (some people don’t like this), including audio devices. So if you fancy listening to some white noise, just cat a file to /dev/sound

Its got to be said, the documentation from the bsd guys is very thorough. Its not good enough for them that they get your mp3s playing. They tell you that wav and au files use little-endian byte ordering and signed linear quantization. You could figure this out by reading the header with hexdump(1). Reading the hex of your audio files, wow, thats a bit hardcore! Having said that, if you cared a little bit more and read up what that meant, you might be a better person. Or maybe a little more bitter….or maybe neither. Who knows! Either way, enjoy the audible goodness!

Search, advertising, email, android,

Now its Chrome , Google’s browser to be. Its promising to be good, with some quite smart ideas

Theres a little comic strip explaining all the juicy details. Its all comes down to:

• Separate process for each tab
• New javascript engine (It compiles it into a machine code for a virtual machine)
• Their huge test suite (they can run loads of rendering tests on the own web page index. Nice)
• Being able to close tabs which have hung
• Gears- transferable features between browsers. Need something from another browser which isn’t a plugin? Just use a gear!

Lets hope they deliver! Even if they didn’t its a good contribution to the open source mind share.

Ok, so people who know me, will know that I think RAM is pretty cool stuff, and that you cant really have enough. OK, so you can have enough, but it is very handy stuff.

A register article today was talking about how MetaRAM can now get 288GB of RAM in a single machine. As someone quickly pointed out in the comments, Sun Microsystems have a machine out for almost 2 years now which supports 256GB of RAM. Its an x86 machine called the x4600. Sun also sell a SPARC machine called the M9000. It supports 2TB of RAM. Thats 2000GB of RAM. Oh, and its got 64 processors.

People should really not be surprised that the limit of how much RAM they have, is not to do with their choice of hardware, but rather choice of Operating System. At this time of writing, thew most advanced version of Windows Server 2003 (Datacenter Edition) CAN address up to 2TB of RAM. But because its written for the x86 architecture, you’ll struggle to run it anywhere to address it all. I should imagine that its partly to do with market demand; you can be sure that if customers were crying out for high capacity x86 equipment, the manufacturers would be making it. Maybe Microsoft should make a port of Windows to run on SPARC?

I find that on the whole this is quite typical of Sun. Their hardware can cost more, but it comes out earlier, and its better than kit in the same class. Sort of like Volkswagen or BMW. Higher cost, but higher quality, and more innovation.