Tuesday, December 27, 2005
I was one of those about 4 years ago. I thought that i could write an MMO on my own with only minor input from an artist friend of mine. I was very wrong. One man teams can have great ideas and can implement small wonders, but they cannot finish "grand projects". It's just not possible.
The reason you can't do it on your own is to do with the size of the project. A bit obvious you may say, but no. The size of the project has more to do with the different aspects that appear, not the workload. For example, as a single man team, you will often omit to do any of the following:
document your work
use version control
follow a schedule
look at old modules and refactor them
These are incredibly important things to do if you are working on a large scale project. If they are not done, you end up losing a lot of your time to dead ends and laziness.
Thats what happened to my MMO, I got as far as a vast world with a skinned character in it, and then couldn't bring myself to write the design for a network module, so i just coded it, and that was the end of that. You can't just write a network module.
This "one man team" is a problem even in the workplace, because some people think that they can do almost all the work, to the point where they don't trust anyone enough to be able to do what they are asking of themselves. This can destroy a multi-person project just as well as it destroys a single man project.
All projects should be considered to be multi-person projects, if not, you get sloppy, lazy, and you start to get protective of the code.
Thursday, December 22, 2005
I know its not quite what it was intended for, but hey.
Thirst thought to drop in:
why do all of us assume that busy means productive?
example, two people:
1. Someone doing their job, seemingly always busy, but producing less useful output than:
2. Someone who seems to just breeze through their day, taking obvious breaks and generally seeming less busy.
In a work place where quantity of work done is not easily mesaured, the busy worker will be valued higher than the efficient one.
This is a problem that applies to many work places, and many job types. It is a problem of inept managment though, and because of that, there is little that can be done about it.
Next Question: How do you train your boss?
Friday, August 12, 2005
Tuesday, June 14, 2005
Your IQ score is 140!Your IQ score is significantly above average. Congratulations! You have a wide range of exceptional skills which are much stronger than those of the average population. You are also skilled at answering the types of questions that are asked in a classic IQ test. The test analyses your strengths and weaknesses based on your mathematical, linguistic, visual-spatial and logical skills. Even though you have high scores in all of those areas, we are able to analyse your results to discover the areas in which you have the strongest abilities.
Your mind's strengths allow you to think ahead of the game -- to imagine or anticipate what should come next in just about any situation. Because you're equally skilled in the numerical and verbal universes of the brain, you can draw from multiple sources of information to come up with great ideas. The timelessness of your vision and the balance between your various skills are what make you a Visionary Philosopher.
In addition to your strengths in maths and linguistics, you have a knack for matching and anticipating patterns. These skills and your uncanny ability to detect the underlying blueprint of most of life's situations add to your visionary philosopher mind. Two philosophers who share the same combination of skills you possess are Plato and Benedict Spinoza.
Wednesday, June 01, 2005
F = 1/R
I = E x F
E = I / F
F = A / V
And now the great bit... how to work out the flow in parallel circuits:
Rt = 1 / ( 1 / R1 ) + ( 1 / R2 )
Ft = F1 + F2
Problem is, resistence in series now just got a whole lot harder...
Rt = R1 + R2
Ft = 1 / ( 1 / F1 ) + ( 1 / F2 )
Oh well, swings and roundabouts.
Monday, May 30, 2005
So, if you haven't got any killer apps, and you aren't 100% compatible with existing apps of some sort, then you've got a great big steep hill to climb. You aren't gonna be able to catch up with the leaders that without a boost, as the leaders are still climbing. This problem is insurmountable (heh), so don't try.
Ok, given these theories, why has Linux been reasonably successful? Two reasons, it has killer apps, and it was born of the original operating system, so there were thousands of people already trained for the OS.
Killer apps? what killer apps?
Linux is based on server code, so you can say that Linux's killer apps are things like SMTP hosting daemons, generally better http servers, and remember at the beginning, who was it hosting all the web content? unix machines, not windows machines. Unix machine users (typically the geeky and the admins of websites and ISPs), were very quick to adopt the ludicrously cheap Linux, because they knew what they were getting. Other people who had started to hate Microsoft started to move away from Windows, towards Linux, but the difference was normally to great, so they sprang back after initially dipping their toes in the *nix waters. I'm afraid I'm one of these cowards. I stick with windows because its what i know, not because its good. I know myself that if anything goes wrong with a windows machine, i can usually fix it. Its easy to fix because its a simple system. *nix is more complex in appearance to me, so i don't trust myself to be able to fix my machine in times of trouble. That's why i don't move. There two apps I love that are entrenched in Windows (or Mac): Microsoft Visual Studio .NET, and Adobe Photoshop. Obviously, games on Linux are also a little limited in comparison, but I am a software developer, so .NET is actually more important to me.
Anyway, basically, Linux is creeping in because it can't be got rid of, not without losing quite a considerable amount of productivity amongst network "people".
So, as long as "Some" people can't live without your OS, you can get enough of a foothold to start creeping in. If you have overlapping killer apps, then there shouldn't be a problem with migration, and if you actually have some killer features, you should be able to "clean up", even if you're incompatible with other OSs.
So, can my ideas "clean up"? I shall run down the list of things that make up my OS.
Are my ideas windows or Linux compatible? No for windows, they could be for Linux. I haven't the foggiest how long it would take to write a windows compatible version of my OS, but i know it would take a very long time. To make my OS Linux compatible would be a lot simpler, and for most of the ideas, the OS would be possible to implement IN Linux. A mate told me that it might be possible to rewrite the filesystem, the kernel, and a window manager of Linux, so it behaved exactly the way I want it to. I hope it is true.
Are my feature ideas "killer"? They may be killer in fact, but i don't think they appear to be killer, the idea for a user interface i have might be killer though, and that might also be enough to interest a migration ready crowd. The database filesystem idea is bandied about too much to be taken seriously, and file instance applications sounds strange, not brilliant. Document centric editing could be a good start, but that is not the OS, but the way the Apps are written.
Does my OS deliver a necessity? No, obvious really, but unless the apps are built to complement my OS, even the basic needs will not be met. If some basic applications are built, Text editor, Image viewer, Compiler, and a Media station (WMP/WinAMP), then it could build from that, from them. Maybe given some time we could develop the killer apps necessary. These killer apps would probably be impossible to build outside the OS, and all the better for it.
This need to bring things together to save the user from having to think has already been addressed by memory managers. Virtual memory was seamlessly integrated into real ram meaning the computer user never had to wonder about how much ram they had left. Does anyone remember trying to make DOS boot disks to play games?
So, applications are instanced in ram. Right? Why?
If applications were instanced in files (just like they would be in a system with very limited ram ;) ), then any operating system crashes would be more survivable. Consider if you will the possibiltiy of having lots of important documents open... unsaved. Then, the system hangs, hangs bad... Have you lost all your work? on a normal system, yeah. But if all applications were literally instanced as files, then only the crashed application(s) would not revive with restart. There is a problem with crashing programs running after restart, but that is a seperate but not incredibly difficult problem to solve (just check for app death by running virtual machines? maybe).
To do this with win32, the operating system has to explicitly allocate a file for each application instance, has to guarantee that DLLs (windows dynamic libraries) arrive in the same location every boot, that the kernel has the same open file handles etc...etc...etc... This is quite a large task (the number of different things to look out for), and only gets more complicated when applications start working outside the box (apps that "investigate" other apps, or apps that twiddle things in the OS so things can happen / not happen).
So basically windows is incompatible with a proper file based application instance mechanism.
Maybe adding that will make the next OS worth having though eh?
Sunday, May 15, 2005
Imagine if you can, a blank document (a blank word document is a good start). Instead of modifying the document in word though, you add word elements to the document and use those elements to create normal word document content. Applications work on these documents by either adding elements to the document, or just working on the atoms already in the document (bitmap docs). Add a Quark xPress element to the document, and gain the ability to make really good image boxes and stuff. At the very least make layout easier.
In this system, there are only a few types of file, so any application should be designed to work with at least one of them. The types i can think of are: finite page (A4 / web), 2D infinite page (line art), 3D infinite page (normal 3D package), 2D bitmap (obvious), 3D bitmap (voxels). Other pages might be looping pages (auto tiling), cell based (spreadsheets 2d/3d, even 4d), and database (tables).
So all applications are designed to work with these data formats. All designed to work as tools upon this clay.
Sounds good to me. (and i think i sounded good to Steve Jobs (or whatever that Apple guy was called) too... i think there was something called OpenDoc that was similar, but more like OLE.
Saturday, May 14, 2005
All operating systems still operate via root/directory*/file hierarchical, apart from add-on systems that interface with the old system to provide a database front end. There is one at least that i know of that can override KDE? file dialogs.
Database filesystems seem to be a great idea, but thats not all that is wrong with computer operating systems.
Programs are either running, or not running... sometimes when i am debugging 2 or more apps at the same time, i want to seperate my tasks off into different sessions (like user logins under *nix), but that is quite a cumbersome technique that dissallows any crossover / moving of one app to another schema.
So the initial assumption may need to be bent a little to encompass applications as well. What is similar between these two problems?
both consist of human interface representing all the things of one type a computer has... (all files versus all open applications).
most of the time the user is looking for one of the items (looking for a file, or looking for an application)
the assumption that you might look for more than one file (e.g. find a picture collection), probably wont apply to applications (looking for internet apps? nah, rather look for internet app executables to run (which are files)). But is a multiple file selection any different than a single file selection? Lets look at what normally makes up a multiple file selection.
People normally look for multiple files as part of collections. Collections are collections for a reason, and therefore have something in common. This commonality is rather well defined in database operating systems (and we are assuming here that a "better" OS will be running a database filesystem), and searches can be quit before a singular result is found (e.g. the result of the file finding operation was a set rather than a singular).
Does this mean that all file searches may as well be multiple file searches? I think so, because even a singular result is normally selected from a refined set.
So, both running applications and files are sets of items that the use wants to work with. With this assumption, can we then join the two? *nix has a process directory in its /dev directory, (/dev/proc i think), and because of this, a non databased hierarchical filesystem already has access to applications (in a wierd way)... how useful would it be to search for apps by the same system as searching for files? This is more of a selection system than a search system, so what have we assumed here? Users want to be able to quickly "select" things? I think so, therefore a new operating system (and associated applications) should be designed to work on the idea of selecting and reselecting any resources the computer has available.
how about some ideas of selection searches?
i copied some files from my camera recently, and i want one of the pictures, i know its a big one... so here goes:
select all (root select)
refine by action: was copied to local harddisk.
refine action by time: after last tuesday
refine selection by filetype: is an image (drops all non images from selection)
refine by action: was copied from camera (drops ones loaded from CD)
selection should be rather small now...
refine by file attribute: size larger than 640x480
refine by file attribute: colordepth higher than 16bit
now quite a refined selection, the viewable list should be small enough to select by hand. (tab through? or use arrowkeys :) )
how about getting an app, a currently running calculator
select all (root again)
refine by type: is running
refine by attrib: is utilty
refine by attrib: is maths
at which point we have a short list of apps, one calculus app, and two simple calculator apps, use arrow keys to select them.
At this stage, an idea comes to mind that the calculators will be exaclty the same as each other at this stage, so how can we tell any difference? The simple answer would be to add the same kind of labels to running applications as there are to files.
This leads to thinking about how to label applications. In my opinion, applications should be able to label themselves (such as an art package labelling itself with sizes of all its current open documents (but maybe not, i shall speak more on my ideas regarding documents later). Applications should also be able to labelled by the user (calculator one might be labelled as "simple maths", whereas the second would be labelled as "current account", and maybe a third as "coder debug helper". With these labels, the different applications could be quickly differentiated from each other.
I think this same system is good enough to help search for anything...
But thats just my opinion.
Maybe, just maybe, application instances ARE files... but again, more on that another time...
(next installment, documents / files rethought)