Kid Koala Live @ Maida Vale For 6 Music
Turntable master at his best, enjoy…
|
Shoko's Spot | Tales of a starbug penguin techdrifting the net
|
|
|
Turntable master at his best, enjoy…
SchemaSpy is one of these tools that most sysadmins seldom use, it is mostly used by developers or DB admins. A quote from the site will explain the goal of this tool clearly: “Do you hate starting on a new project and having to try to figure out someone else’s idea of a database? “. One should remember that with the rapid development that usually happen at startups, your own project can look like someone else’s after a couple of weeks, documentation is not the goal, and rightly so. After some fiddling with the installation (it is java) and one run you’ll have a nice ERD of your database with some other goodies. Now you have the option of running it whenever you want or you can be really nice to the developers and do automatic nightly runs, it might pay off in ways you never dreamed of.
Few months ago AWS published a new reserved instances proposition. While there’s a lot of data on their web site it escapes me why would they leave out an important piece of information: When do the reserved instance deals become cheaper than standard allocation? Below is a graph for the yearly costs of all instance types, comparing standard and reserved costs. The simple answer is that reserved instances will become cheaper after 4.5 months of usage for the yearly reservation (constant or variable usage), and 7 months for the three year deal. Reserving machines, for constant usage, will save you 44% on costs for one year and 56% for three years making TCO even cheaper, as expected from the cloud computing industry.

Notes:
1. Open files in Vi are stored in buffers.
2. Unless the buffer is explicitly deleted (:bdelete, :bwipeout), or Vi is exited, the buffer will remain in memory and available.
Example:
1. Start editing file1.txt – # vi file1.txt




For more buffer commands type :help buffer

Rackspace, in its cloud servers service, generously gives hosted machines unallocated CPU cycles, above the guaranteed levels (reference). In a study I’m conducting these days, comparing performance of the biggest IAAS providers, this innocent feature revealed itself very clearly. Comparing the smallest instances of both EC2 and Rackspace CPU benchmarks, and normalizing to benchmark points per one cent, I discovered that the Rackspace offering is better by more than 3500%!!! Even if the two 2G memory instances from EC2 and Rackspace are compared, the difference is still more than 430% in RackSapce favor. It’s important to note that these numbers do not carry to the largest packages where the difference is about 380% in EC2 favor.
My benchmarks also revealed that there is no real difference in the CPU benchmark scores through all of Rackspace instance packages, while EC2 and GoGrid scaled more reasonably. My eyebrow went up at this point.
Here is a reasonable assumption that can explain these strange findings. Buying Slicehost proves that Rackspace want in on the Cloud hype. They want in, and they want to do it fast, being a relatively late comer. A lot of servers were probably allocated to this project. Prices go down very fast with large numbers. It’s safe to assume that these servers are mostly undeployed for the time being, waiting for the hordes of clients to come and host their servers at Rackspace. Along these lines, it’s a safe bet that Rackspace CPU benchmark numbers will go down eventually, and equlize with all the other IAAS providers.
For some, this might sound like a dream come true. If CPU bound transient resources is the requirement, Rackspace is the place to host these jobs, for now at least. If you plan to jump on that moving wagon, don’t do any long terms planning on the numbers you get. On the other hand, building a system for the long term on infrastructure that includes resources that will one day simply disapear is unsound. It can still be done, but special care should be put on the ongoing changes in service.
A truly beautiful piece by Venetian Snares. Not for the aggressive D&B or Underground intolerant.
Spending many of my days in front of computer interfaces makes me wonder how things has sunken so low. The whole concept is wrong. Computer interfaces are just too damn far from what they should and can be. I’m including here just about every possible interface I encounter. It’s true that some of the programs I use do have reasonable interfaces, VI for instance. But these are usually highly professional programs. It seems like the software market never stopped and thought about all the common people that need to use this magnificent piece of hardware called a computer, they just gashed along with the increasing demand for more and more programs and through it, more interfaces.
The process, in a concise way, usually happens as follows. A programmer has a wonderful idea to make all our life simpler or maybe more enjoyable. The idea starts to take form, there might be some quick drawings on a napkin. Here is where taking care of the visual aspect stops. Next, in this way or another, a feature list emerges and scope, target and some sort of a plan are all defined. The feature list, rightly so, is considered as the core of the software. Programmers start to work on the project and it takes some time until the user interface is reached. By then the programmatic skeleton of the software is well defined and well known by anyone that had any saying regarding the project. Through the whole process, all the members, from the programmers, through the product manager and even the QA or beta testing people, are getting used to think about the software according to the feature list, and the way it was accomplished by the software programming design. Inevitably, the interface reflect that fixation instead of reflecting the client usage of the programmer. This is the reason why user interfaces looks like the way the programmer solved the programming problem more than anything else.
The reason that things might look less grim than I describe them is that this has been going for a very, very long time. By now, most people got used to the idea that it will take some time to learn any new software (including web application) they want to use and healthy intuition can not really help them with that. All graphic operating systems share the same exact elements, since MS Windows 3.11. There was little or no progress. The use of the personal computer grows exponentially, and we are still stuck with an interface from more than 15 years ago. Sure, we have much more features, and many more tools, but at some point there was a change not in the usage quantity but in its essence. A change that only for a limited time can be answered by the new MS Office toolbar, a shiny new interface in Windows Vista or 3D effect on X-windows with Compiz. These are all nice, but give only the facade of progress.
Lets say I want to contact john doe, just to ask wasuuup?!? see if his knee is getting better after a white shark disappeared with it into to abyss in one of his recent adventure trip to west Australia. That is a simple, human need. I don’t want to start to think if I want to use email, messenger, ICQ or IRC (to those who remember) and then to check for his email, the correct one, or on which IM he’s available right now. It doesn’t matter! I just want to communicate, pick his name from a list, write the message and maybe hit a ’send’ button. If he’s online and we can continue to chat, great, If we both want to switch to a voice chat, even better. If he’s offline, no harm, he can read my message later.
Another example is documents, any kind. And make it a proper one with tables (and formulas) and images and charts and references to offline and online material. This will require a familiarity with 3 programmers in the least and a fare amount of time to a knowledgeable person. Try to estimate the time it will take to the unskilled. I later want to send it to a friend for review and might even consider publishing it online on a web site.
Seems like the motto behind computer interfaces is “Hey! it’s a highly sophisticated tool, adapt or get lost!” even when the task at hand is very simple. Sadly, for lack of creativity there are no real options at the moment. It will eventually change.
A simple feature chart of Amazon EC2, GoGrid and Rackspace virtual servers (A, G and R in the chart, respectively). The BogoScore at the end is just the count of supported features, it doesn’t mean much but I just had to do it. Black squares are supported, white are not and grey are partly supported.
| A | R | G | ||||
| Backups | Image snapshots | |||||
| Image snapshots – Scheduled | ||||||
| File backup | ||||||
| Storage | Attached storage | |||||
| Attached storage – Snapshots | ||||||
| Object storage | ||||||
| Object storage – CDN | ||||||
| Resource Allocation | CPU bursts | |||||
| Local disk raid | ||||||
| Instance persistence (over shutdown) | ||||||
| On-line Resizing | ||||||
| API / Management | Web interface | |||||
| Command line | ||||||
| PHP | ||||||
| Python | ||||||
| Java | ||||||
| Ruby | ||||||
| .NET | ||||||
| REST / SOAP | ||||||
| Instance web console | ||||||
| OS Images | User created | |||||
| Instance snapshot based | ||||||
| Windows (2003/2008) | ||||||
| Linux – Redhat | ||||||
| Linux – Debian | ||||||
| Linux – CentOS | ||||||
| Linux – Suse | ||||||
| Linux – Other distros | ||||||
| Network | Multiple local NICs | |||||
| Routable IP on local NIC | ||||||
| Multiple routable IP addresses | ||||||
| Client supplied IP addresses | ||||||
| Other | Multiple locations | |||||
| Firewall (layer 4) | ||||||
| Firewall (layer 7) | ||||||
| Load-Balancer (layer 4) | ||||||
| Load-Balancer (layer 7) | ||||||
| System usage graphs | ||||||
| No annoying pop-ups on web site | ||||||
| BogoScore | 25 | 18 | 14 | |||