You said: "Another solution: Allow the patents, but make it absolutely clear that no patent can be infringed on by writing, publishing, downloading or using software on a normal computer."
What's a normal computer?
My PC? What makes it different from my PDA? So is my PDA a normal computer? What makes it different from the dash computer embedded in my car? And what makes that different from the computer that controls the car brakes?
To forestall one obvious answer: if you work on the basis of the number of funtions it performs then you have to define the limits of a function. So my car brake computer stops the car. It also stops skids. Is that a different funtion. Working towards larger functionality: My media-centre records TV, but it also gives me web access. Is that a normal computer?
So what about using the number of tasks/processes/some-other-thing as the measure? Again, where are the boundaries? DOS was a single-process system, but you'd almost certainly say it was a normal computer.
This approach doesn't work because the boundaries are arbitrary if it's not 1 unit-of-distinction. And 1 unit includes what you'd call normal.
However. If you can embody your business process in software, with real physical effects, then you can probably patent that version of the process. There's a grey area; some EU countries have allowed software patents and inventions where software is the key part more than others.
Advantages: - it's fast and it's not constrained by column length. If you want a table with 16,000 columns, go right ahead. - it's very portable. Runs on just about every operating system that has more than 100 users.
The disadvantages: - last time I looked (admittedly) about 4 years ago, their SQL integration could have been better. - it's not a high-level database. To work most effectively with it, you need to know about the way that your data is stored.
If I advertised in LBN, I would be seriously pissed at having my products linked to this sort of gutter journalism. http://www.sybase.com/linuxpromo>Sybase & Linux Networx are you listening?
Do click those links folks, the traffic at least should start them wondering what's up.
Sybase and Linux Networx, when you read this: I hope that the exposure that you've had as a result of these links more than makes up for the traffic you would miss from LBN. Please pull your advertising from LBN.
IBM, I'm guessing you don't have a choice about advertising Websphere on the LBN site, since it's through Google but don't you think it's kind of ironic to be subsidising Ms O'Gara's salary?
I think I remember the Indy site suggesting that perhaps it's a bad idea to post to/. because server-side Indy shuts up shop and goes home if the traffic gets too heavy.
So what's the first thing that someone does?
I suggest: if this interests you, imagine you are Ethernet. You've just had a collision. Put a todo item in your list, with a random-ish number of days until you do it, then try again. That should spread the load.
How many people want this? And how much would you be prepared to pay? And how many disks do you want to clean each day?
I'm imagining, you pull the disk from the box, slip it into a caddy. Slide the caddy into the cleaner, press a button. When a light goes green, that disk has been cleaned to a particular standard.
If there's enough indication of demand, we'll build them. Send me an email - cleaner at tanasity dottt com, letting me know the answers to the questions above. Any mail I receive will be used for this purpose alone.
Toontalk http://www.toontalk.com/ is still one of the most interesting visual languages out there.
You program by controlling a character who can move around a landscape with his or her tool set. Using the tools, you teach robots (an analog of a subroutine) how to do something.
It's couched as a game for kids, but in fact it's a complete language with strong semantics. (If you have kids you should try it out on them. If you don't, you should try it out on yourself.)
Ken Kahn really deserves huge appreciation for the brilliance of the ideas in his software; I'd like to see him receive the Turing Award for this work; I think it will prove to be incredibly influential. I am absolutely serious. Don't be mislead by the cartoon style that it employs.
[There are no doubt numerous errors and ommissions in the text below. Please mod any corrections and additions up.]
A primer for those of you that aren't in Europe and also for those of you who are in Europe who find the whole thing confusing...
Europe is a place to the East of the USA, across the big bit of ocean.:-) Europe is made up of lots of countries, two of which, simply for example, are the United Kingdom (aka Britain) and Germany. We've banded together under the banner of the European Union (EU), each as sovereign nations, delegating some roles and responsibilities to the EU where it is in our interests to co-operate. One such example is monetary union - a number of EU countries abolished their currencies and now share the same currency.
One of the chief issues that the central bodies take care of is 'harmonisation'. Harmonisation is about creating a level playing field across Europe, chiefly in legal and economic senses. A main tool for this is the Directive. The central body consults, then draws up a Directive which outlines a part of law, then the Directive is implemented as law in each of the EU countries, and thus the laws in each country come to some sort of standard.
The current argument concerns a draft Directive.
To understand how a Directive is agreed, you need to know who the players are...
The EU has 5 central bodies of which 3 are of immediate concern with respect to the Directive. The Commission, the Council and the Parliament. The Commission is chiefly to manage things European. The leaders of the Commission (Commissioners) are nominated by national governments and have portfolios. The Parliament is directly elected by the people of Europe in a using a proportional representation system (is this true across all of Europe? It is in the UK.) The role of Parliament is to scrutinise legislation. The Council is composed of representatives of the national governments, and as the Council web page says, this is the main decision-making body, and where the power lies - in national governments making decisions together.
So what's the process involved in agreeing a Directive and where are we in the process?
There are numerous arcane rules concerning the process by which Directives comes into being, and it depends on what the legislation covers. For the Computer Implemented Inventions Directive, a draft directive was prepared by the Commission and ratified by the Council (someone - is this right?) and then put before the various committees of the Parliament for comment and voting. Then it went before a Parliamentary plenary sitting, who voted for numerous changes of the original Council version. The legislation then went before the Council once more. They decided to ignore the Parliamentary ammendments and the requests of various parliaments of various countries to restart the whole process, and have decided to send the original Directive (with minor changes?) back to Parliament for the next stage in the process. Parliament has yet to vote.
The rules for the first and second plenary vote of Parliament are different. The second round has a much higher barrier to introducing changes - an absolute majority is required (someone?) - and if the barrier is not passed then Parliament is assumed to have no objection to the legislation, and it will become a Directive.
Understand from all of the above that it is the national governments that are driving this legislation forward.
Is there a need for a Directive at all?
The need for harmonisation has arisen because different European countries have different standards for judging the allowability of patents involving software, which means that the same patent has been allowed in some countries and not in others. Often the figure of 30,000 European software patents is quoted. (Does anyone know were this comes from?)
It's easy to see some examples of the sort of thing that has been granted - the European patent office is on
"Even if your memory used is nowhere near what your physical memory is, you will notice two things: 1. Your system still consistently uses the paging file 2. Every time your system uses the paging file, your disk queue length spikes"
Yes, you are right.
Microsoft Research have tried this experiment: they bought a lot of RAM, and made a build of Windows with virtual memory turned off to see what happened. They expected it to go much faster. But it doesn't work. The problem is that lots of developers don't trust the integrity of physical memory, and deliberately, continuously write stuff to disk. Consequently you get slow down anyway, with the disadvantage of occasional errors from untested situations.
The interesting part is that virtual memory was needed because RAM was expensive so there wasn't much of it. And now it's not. So there's no need for virtual memory any more.
Expect future operating systems to dispense with VM.
There are two classes of application that web browsers are very bad at: rich UI interaction - for example graphics editing - and interactive data apps.
There are workarounds and bodges that can help, but they depend on Javascript and you can't be sure that everyone will be running Javascript, let alone that there is consistency at the DOM level.
There are two things that web applications are very good at: rollout and global availablity. Wouldn't it be great if we could have it all. XForms is a step towards that, targeted at data manipulation applications.
For this sort of application, you very often need to update the information presented, at a field level. So for instance, on a desktop application, you might have a field where you can enter a name, and as you type, another control presents a list of possibilities which dynamically changes. Typing 'S' would show you 'Smith' and 'South' and 'Smart'. Adding 'm' would reduce the list to 'Smith' and 'Smart'. And so on.
To do this properly, you need to be able to have sub-page queries of the web server/web service/database/whatever, or you need to download the whole index and filter at the client (yech). And you don't want the whole page to refresh. So it's not something that HTML as it stands can do, without workarounds.
From the XForms FAQ, here's a list of some of the things that can be done with XForms that aren't possible in HTML:
* Check data values while the user is typing them in.
* Indicate that certain fields are required, and that the form cannot be submitted without them.
* Submit forms data as XML.
* Integrate with Web services, for instance by using SOAP and XML RPC.
* Submit the same form to different servers (for instance a search string to different search engines).
* Save and restore values to and from a file.
* Use the result of a submit as input to a further form.
* Get the initial data for a form from an external document.
* Calculate submitted values from other values.
* Constrain values in certain ways, such as requiring them to be in a certain range.
* Build 'shopping basket' and 'wizard' style forms without needing to resort to scripting.
If you are interested in XForms, it's also worth knowing about Web Hypertext Application Technology Working Group (WhatWG) - http://www.whatwg.org/ who are working on specifying an extensions to HTML to allow richer applications. One of the projects is Web Forms 2.0 which aims to specify form extensions for HTML and XHTML.
Both of these are excellent initiatives which could make the life of web app developers Better.
Mozilla starting work on XForms is terrific. The competition may spur Microsoft on... MS are not very keen on anything that reduces the dependence of users on desktop apps. For them, this is a very sensible strategic position because their income stream depends on continued need for their OS, and that in turn is because applications are bound to their platform. Consequently they haven't been especially fast to embrace (or extend) standards which would make it easier to deliver rich web applications.
Don't bother to weigh in with MS-bashing. You are wasting your time and this is not what the para above is about.
The problem is with the "advertisement clause"....snip.... It doesn't mean that every copyright holder must be mentioned in ADVERTISEMENT for the software.
Here's what XFree say:
The modifications to the base license are motivated by the Project's desire to strengthen its stated policy of "You can do what you like with the code except claim you wrote it ".
That's pretty clear.
Here's the two clauses that are contraversial:
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution, and in the same place and form as other copyright, license and disclaimer information.
The 'above copyright notice' is "Copyright (C) 1994-2004 The XFree86 Project, Inc. All rights reserved."
and
3.The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by The XFree86 Project, Inc (http://www.xfree86.org/) and its contributors", in the same place and form as other third-party acknowledgments. Alternately, this acknowledgment may appear in the software itself, in the same form and location as other such third-party acknowledgments.
Nowhere does that say any thing about including them in advertising.
It does say that you should acknowledge them.
It's a form of payment. In just the same way as you the GPL requires you to pay by returning derivative work to the GPL pool, one of the XFree items for payment is inclusion in credits. There is nothing morally wrong with requiring to be included in credits as a cost for use of a work. It's wrong to deny someone credit for their work. So the solution is to sort out a mechanism where there is no burden to bear for crediting.
I reiterate...
The point of my original comment is that it needn't be a burden to any of this if only there was a sensible automatic mechanism for gathering the information.
The basic problem is that there is no convention for listing contributors. You would think that it was not beyond the intellect of FOSS developers to come up with something suitable.
For instance: If the standard was that the flag -contrib listed contributors, and dedications, together with the name of the program, then it would be simple to gather a list. And the work of gathering a list is what teh complaint is about.
Once you have the list, it's not difficult to display it on request or put it in a file.
It might also be a good idea to have a standard comments format (easily parseable) at the top each source file with the same info. You might need to define a format per language. I'd imagine something like
#<attribution> #Joe Soap - cleansing #Alice Soap - project management #<dedication> #To all the good people of the world. We hope you find this useful. #</dedication> #</attribution>
I've used an XML style above, but don't get hung up on that - it's a detail that doesn't matter right now. It could be.ini format, or whatever.
And guess what.. if you have the list in the source in a standard format, you can easily create the code for the contrib flag.
Really it's plain old good fashioned courtesy. If someone creates something that you are using then you should be acknowledging it.
And now for a political subtext... The whole issue with the naming GNU/Linux vs Linux is about attribution. To my mind it's unreasonable on the one hand to campaign for recognition in this way, and on the other to have a GPL that is incompatible with giving credit where it is due. It seems to me that there is a strong streak of not-invented-here at work.
If you believe in Open Source or Free Software then you should believe in copyright. If you find a GPL code in use in a closed project, then you should report it to FSF. If you find Windows code in the wild then you should report it to Microsoft. It's their code and consequently they should and do control who gets to see the code.
That said, I would desperately like MS to release the code under an open-source, but closed-project style licence; that is, the code belongs to them, and for any derivative code MS is automatically granted a licence to to sublicence and do whatever they wish. It should not be permissible for the code to be included in another product without the explicit say so from MS. Microsoft could protect theselves financially by being the only source for binaries. BillG are you listening? Win2K, with open source could be sooooo good, and you would still make a stack of money. Plus you'd have a huge team looking at improving the software, for nothing.
It's worth a shot if the code has escaped. At worst you'll get a second product line.
I want to say first that it depends upon the culture of your company. You also don't say at what sort of level you work in the company, so I'm assuming at least several levels down from the management.
If you are peopled by weasels (is that possible?) then the best advice is always to watch your back.
If your company is hugely political then politics is valued and it's best to approach it like that.
On the other hand, the fact that your management is meeting you at all suggests that you are working in a well-balanced company. If that's the case you should speak the truth when asked, without dumping anyone in the muck; that's a good way to make enemies. You should be polite and only discuss major points.
Your management has a different view on the company from you. They have to take the whole company into account, and you are naturally most interested in your corner. Having a bitch about the cubicles in the IT area won't win bonus points, but if you talk about how the sales people don't have good enough kit for their jobs you will. So - focus on what are problems for other people, and how to solve them.
Don't expect your management to do everything you suggest - and don't get despondent if they don't do the things that you think are most important. They have to prioritise across the whole company and should be giving weight to those areas that will bring the biggest benefit to the whole company. This doesn't mean that they didn't hear what you said, and didn't want to do anything. It may simply mean that there are higher priorities at the moment.
Do talk to your management as if they are people and not uber-gods. Try to avoid geek-speak. Do dress smartly - even if you wouldn't normally - it will reinforce your point of view. Don't drink much - you don't think as well - even though you are convinced that you do.
For you geographically challenged people. Africa is a whole continent. Like North America, South America and Australia.
South Africa is a country. It's at the tip of Africa. You'll never guess where it is in Africa.
It was a British Colony, but gained independence about 55 or so years ago, and promptly began to institutionalise pernicious racially-based discrimination. It was called Apartheid. After a long struggle (40 years) the white people agreed to share power and democratic elections took place. Nelson Mandela (you may have heard of him) was elected president.
The economy of South Africa is split - there's a strong first world component, and a large third world component. The first world component rivals the economies of Europe and the USA in sophistication - though it's much smaller. The third world component - i.e. subsistence farming, and subsistence trading - involves many more people. Unemployment rate is high - a few years ago it was 40%. Not sure what it is now. HIV/Aids rate is probably the highest in the world - hitting around 10% of population. Some places have rates as high as 40%. The current government until recently has ignored the problem.
Eskom is a world-class power utility. They have existing nuclear reactors, which were learning grounds for the Apartheid state in their quest for nuclear weapons. (Ten or so years ago South Africa admitted that they had nukes, and then destroyed them. Thank you Nelson Mandela and South Africa for making the world a safer place.)
It's questionable whether South Africa needs more nuclear power plants but Eskom has traditionally had a strong technocratic streak. (I was an employee a long time ago.) SA is rich in coal and natural gas.
I personally think that the money could be better spent given South Africa's problems - the only justification would be to export the technology. And maybe greater access to nuclear expertise is not what the world needs.
The situation is somewhat more complex than presented in the blurb.
Patentability of hardware is a well accepted principal. But what if the hardware contains software? For instance when it's a cellphone. Should the hardware still be patentable? What if the phone is only special because of functionality implemented in the software portion? For instance if it can talk to a Jabber server. Should it then be patentable because of the special features?
Now what if it's not Jabber, but some other IM server and the intelligence is in the server. Should the system of phone plus IM server be patentable? If not why not? If yes, then aren't you allowing patenting of software on general purpose hardware?
So that's the background.
Having organised a couple of meetings on the issue in Cambridge, I'm of the opinion that the case that the directive is damaging is overstated. The author of the language of the amendments introduced in JURI says that by the nature of the EU system the language can't be very tight, but that a key feature is that patentability can now be reviewed by the courts, and that JURI has made its wishes clear in the Recital, which courts use as a guide to the intention.
There is still a crucial issue of how Free and Open Source software authors are protected. The directive is inadequate in this regard, but then the situation as it stands is inadequate. We need to take a social decision that protects authors of Free and Open software because they make the efforts of their labours available without charge and that's to the benefit of society.
An interesting side effect of such a settlement would most likely be a decrease in software patenting in favour of the use of trade secret. This isn't necessarily a god thing; patents were invented to make it possible to expose trade secrets in return for a limited monopoly on their use. An example - if you invent the ultimate search algorithm but kept as a trade secret it might never enter the public domain.
A second serious problem is the length of a patent - around 20 years. For software, which typically has a life span of 5 to 8 years, this is ludicrous. On the other hand it typically takes around 2 to 4 years for a patent to be granted. But software intro cycles are around 12 to 18 months. So unless you have a spectacularly good invention, or some indirect need, it may very well not be worthwhile patenting. (The number of patents involving software suggest that this isn't generally true - numbers of 15,000 to 30,000 in Europe are commonly reported.)
The way to solve the problem of software falling under the same banner as hardware is to alter the European Patent Convention to vary the rules for software. This won't be easy, but it's probably possible.
Power grids are much like a tower built of cards... They have to be maintained in a delicate equilibrium. Both too much power flowing in or out and too little power flowing in or out are bad things. At the same time grids are evolved - bits are connected to other bits when it becomes possible, so they aren't regularly structured.
(There's a really interesting problem of determining a fair/best representation of the state of the whole system from incomplete and possibly faulty data from many sources. I once had the pleasure of working on such a system.)
Because there's such inter-dependency between portions, and because too much and too little is bad, there are automated isolation switches at many points in the system. They respond either to local conditions or according to a centralised control room. Most often they respond to local conditions because the control room doesn't have a fully real-time picture of the whole network. (And even if they do, it's possible for it to be incorrect.)
So, if you have a little accident in the wrong place, a fault can propogate through the system, triggering automated shutdowns. In fact it's probably not possible to design a network with local decision for these safety valves where this can't happen. I think that this has been shown theoretically, but I'm not sure - it's been a few years.
There can be HUGE difficulty in bringing the system up again. It's not something that you can easily test your disaster plan against, and the sequencing of supply and demand is important in order to avoid automatic trip states.
It's entirely feasible that it may take weeks before the network is restored to a similar state. The worst scenario state could involve months.
That's the technical aspects.
But there are underlying reasons that may have contributed to this happening.
1. Competition. Competition is a two edged sword. Because electricity is a commodity, the primary way you can judge companies is on price. The cheaper it is for you, the better. That's good for consumers. So a large force, in a market economy for electricity is towards cutting costs.
But when you don't have enough money, spending it on averting possible disasters is harder. You switch to risk management techniques instead of risk removal. Especially since the cost of failure is bourn more by your customer than you.
2. Insufficient planning. Most networks aren't homogeneous. They are owned by more than one company who co-operate. Sometimes laws stop companies co-operating on areas where they should.
I think that the US should take this as a great big cluestick. I wonder how much this cost? It turns out that unregulated or markets with low amounts of regulation sometimes create failure. Sure, they are cheaper, but sometimes they are disasterous. It's important to get the balance right, and it differs for different products so ideologically driven decisions are likely to produce bad effects sometimes.
Secondly, if you are aiming to change things from a known safe state to a new unknown state, a carefully controlled, slower, planned change can have a lot of advantage. It may cost more, and be non-optimal in terms of time, but time is more easily measured than safety margin.
As well as technical things like powere grids, I'm thinking of regulated to less-regulated markets. Of non-GM food to GM-food. Of world trade policies and intellectual property right expansion. Of privatisation. And more.
Apparently the Pentagon sees no compelling reason for an alternative to GPS. Oops, that would be before they checked their GPS units round about now. Oh wait, I forgot, they have their fingers on the buttons, perhaps that why they can't see a compelling reason.
On the other hand, to be fair, the US could have just degraded the signal without announcing it. At least now ships and planes probably won't be piloted into rocks.
BUT, history shows that it is almost impossible to go up against an incumbent pervasive technology with a similar technology. The new tech has to offer a great deal more for people adopt it in large numbers. This is not to say that there won't always be unusual keyboard variations - but it's likely that these will be marginal.
And now an advert: I know about One Bamboo because they are members of the Cambridge Hi-tech Association of Small Enterprises. Anyone reading this near Cambridge, UK could be interested. http://www.chase.org.uk/ Two meetings a month - the next is a pubmeet at the Free Press on Tuesday 18th - 8pm.
I think it was Buzz Aldrin who tells this story as an explanation for the moonshots and the drought: one day he was watching this small dog out his window. And a car came driving passed and the small dog barked wildly and ran off after the car. And a little way up the road the car parked so the dog caught up with it. The dog was surprised for a moment, then he peed on the wheel and came back, looking pleased with himself.
The same as with almost any product - games fail for a range of reasons. Some obvious ones:
1. No customers. Design for hardware that people do have. Not the hardware that they might have. I bought 3dfx kit when I last built a PC. I might buy a GeForce card now, but it's unlikely that I will buy a card to play a game that I can't testride without a GeForce. Doh!
2. No coherency. If you don't meet the minimum requirements in terms of plot, gameplay, programming, visuals, price, then you are doomed. You can trade off one for another, but if you fall below the minimum acceptable standard on any of the important metrics then you've got a dud, regardless of how good the other metrics are.
3. Lack of marketing. If the public don't know about the game then they won't buy it. Technical prowess is not enough to bring masses of customers. (That may be quite surprising to all us technerds, but it's true.) It's a surprising but true fact that a crap product can be rescued by good marketing, but a good product is amazingly unlikely to succeed without marketing. (If you develop then learn to love those people who want to gush to the world about how your product is 'REVOLUTIONARY!!!!!') Marketing is often more expensive than the cost of development.
4. No channel. If you can't get the game into the hands of your customers, then you don't have a product. Building a channel is usually more expensive than building the game.
5. Bad management. It's the job of management to make sure that all the bits of the puzzle fit together. Forget just one and the game can fail. So you'd better be able to juggle well, love people, find technical problems fun, enjoy budgeting and project planning.
Products succeed because:
1. They address the needs of those that play them. They mix the plot, gameplay, programming quality, visuals, price elements so that there is a very attractive package. The more attractive, the more likely that they will be bought. Perhaps the gameplay is brilliant despite the visuals, perhaps the gameplay is quite dull really (first person shooters) but amazingly interactive. It helps to have one or two people who share a vision to bring this one off. It also helps if they can adjust their ideas in the light of circumstances. And committees don't work too well at making fun things.
2. They address the needs of a diverse audience. Your audience is more than just the buyers. Frinstance, you need the press on your side too. You need to be able to give marketing people hooks. You may need to address parents' concerns if they are likely to provide the money. Omit a key target audience and you'll likely fail. The needs of the different audiences are different. A journalist might not play your game at all, but might write about it - they need interest factors in an easily digestable way. If a journalist does play then they may only play for 5 minutes, so those minutes had better be well thought out, easy and exciting. If three of them are dull then you've lost your chance. And the needs of different sorts are journalists are different - for instance a good TV report needs some stunning visual elements.
2. They are the right thing at the right time (and luck). Because the bar on plot, gameplay, programming, visuals, price are constantly rising, you'd better meet the demands at the time you publish, and not at the time you start developing. It's tough, but you can make a brilliant game that's at the wrong time too. Games that have elements that involve crashing planes could come in for massive knock in the aftermath of a real plane crash. Perhaps a much bigger competitor releases a brilliant title 2 weeks before your game goes on sale - you'll probably take a hit because you can't afford the level of marketing they can. Or perhaps you make a shooter just as the shooter market tanks.
Most the ones that fail are the ones that don't understand that they work inside a larger world and plan accordingly.
Now, did you notice that I didn't even use the word 'engine' in here. That's because it doesn't matter. Gasp! The greatest engine in the world makes stuff all difference if the other elements aren't in place.
Yes, blue is the colour that they have the most problem with - it's the most unstable. In the labs they have blue up to 1000's of hours lifetime. But to compete with consumer goods like TV's and monitors they need much better performance.
Imagine your TV is on for 4 hours a day, and you keep it for 10 years. That's 14600 hours, with no margin of error.
It is quite likely that they will overcome the problem with blue...at the moment there isn't a full theoretical model for why Light Emitting Polymers work, and progress is through empirical testing.
No, you probably can't make a fibre. The pixel addressing would be a huge issue, but that's not necessary providing you have a flexible substrate material.
Jeff Veit www.tanasity.com and www.tangledtime.com
In September we (Cambridge Hi-Tech Association of Small Enterprises) had CDT talk to us. (CHASE is a club for people interested in technology and business and is based in Cambridge, UK. Come and visit the site, but not all at once.)
The head of technology and strategic planning spoke. Despite the hype-ticle on CNN, it was clear from what he said that you shouldn't expect flexible displays any time soon - probably not inside 10 years. I don't get a T-shirt with space invaders on it any time soon. You can expect conformable displays within a few years - i.e. rigid, shaped screens. However it's likely that you will see other companies building these; CDT is an IP company. They hold fundamental patents on light emmiting polymers. They aren't just a holding company; they do develop technology, but their basic strategy is to licence to others. They will have bought Opsys to strengthen their patent portfolio.
If you are currently building hardware that needs small mono screens you should definitely check out CDT. Their displays have superb characteristics - an almost 180 degree viewing angle, bright even in sunlight, and very low power requirements. The examples of the technology that he showed were very 'version 1.0', but show brilliant promise.
Next CHASE meeting - 12 Nov - Invisible Networks are building community broadband networks in rural villages around Cambridge. Currently using 802.11.
Jeff Veit
www.tanasity.com and www.tangledtime.com
There is enough bitching about the music industry here to make me want to puke.
Get over it. It's a business. Their job is to maximise profits. It's worked pretty well so far. Screwing the artists has obviously paid well. But there is an need for record companies; they front the money to make albums and they promote music.
(Please note I do not say that there is a need for them to earn the profits they have historically. But that's probably got more to do with the lack of competition. And the lack of competition is traceable back to the lack of substitutability of the product; if I think that a song by one artists is great, but too expensive I am not going to buy a record of another artist singing it instead.)
Action speaks louder than words. If you don't like the situation, then do something about it.
So my question: Who is doing things to change the market?
I can imagine: - Web sites that allow bands to post music for download in return for payment. - Web sites that allow music trading in return for payment to the band - Web sites that help bands to auction themselves to labels allowing competitive bidding. - Micropayment services. - Services that promote bands by letting people find music that they are likely to like. - Distribution licences on music allowing you to further distribute in return for payment.
So who are the people and companies that are already doing this?
(Remember that not many of the buggy manufacturers became car manufacturers. Not many of the cold typesetters turned into desktop publishers. And it's likely that not many of the large record companies will be the ones who are our primary source of music in the near future.)
Slashdot Mirror
You said: "Another solution: Allow the patents, but make it absolutely clear that no patent can be infringed on by writing, publishing, downloading or using software on a normal computer."
What's a normal computer?
My PC? What makes it different from my PDA? So is my PDA a normal computer? What makes it different from the dash computer embedded in my car? And what makes that different from the computer that controls the car brakes?
To forestall one obvious answer: if you work on the basis of the number of funtions it performs then you have to define the limits of a function. So my car brake computer stops the car. It also stops skids. Is that a different funtion. Working towards larger functionality: My media-centre records TV, but it also gives me web access. Is that a normal computer?
So what about using the number of tasks/processes/some-other-thing as the measure? Again, where are the boundaries? DOS was a single-process system, but you'd almost certainly say it was a normal computer.
This approach doesn't work because the boundaries are arbitrary if it's not 1 unit-of-distinction. And 1 unit includes what you'd call normal.
Business processes are not patentable here.
However. If you can embody your business process in software, with real physical effects, then you can probably patent that version of the process. There's a grey area; some EU countries have allowed software patents and inventions where software is the key part more than others.
Faircom CTree-Plus might.
Advantages:
- it's fast and it's not constrained by column length. If you want a table with 16,000 columns, go right ahead.
- it's very portable. Runs on just about every operating system that has more than 100 users.
The disadvantages:
- last time I looked (admittedly) about 4 years ago, their SQL integration could have been better.
- it's not a high-level database. To work most effectively with it, you need to know about the way that your data is stored.
I'm sure it's improved a great deal since then.
If I advertised in LBN, I would be seriously pissed at having my products linked to this sort of gutter journalism. http://www.sybase.com/linuxpromo>Sybase & Linux Networx are you listening?
Do click those links folks, the traffic at least should start them wondering what's up.
Sybase and Linux Networx, when you read this: I hope that the exposure that you've had as a result of these links more than makes up for the traffic you would miss from LBN. Please pull your advertising from LBN.
IBM, I'm guessing you don't have a choice about advertising Websphere on the LBN site, since it's through Google but don't you think it's kind of ironic to be subsidising Ms O'Gara's salary?
I think I remember the Indy site suggesting that perhaps it's a bad idea to post to /. because server-side Indy shuts up shop and goes home if the traffic gets too heavy.
So what's the first thing that someone does?
I suggest: if this interests you, imagine you are Ethernet. You've just had a collision. Put a todo item in your list, with a random-ish number of days until you do it, then try again. That should spread the load.
How many people want this? And how much would you be prepared to pay? And how many disks do you want to clean each day?
I'm imagining, you pull the disk from the box, slip it into a caddy. Slide the caddy into the cleaner, press a button. When a light goes green, that disk has been cleaned to a particular standard.
If there's enough indication of demand, we'll build them. Send me an email - cleaner at tanasity dottt com, letting me know the answers to the questions above. Any mail I receive will be used for this purpose alone.
Jeff Veit
Toontalk http://www.toontalk.com/ is still one of the most interesting visual languages out there.
You program by controlling a character who can move around a landscape with his or her tool set. Using the tools, you teach robots (an analog of a subroutine) how to do something.
It's couched as a game for kids, but in fact it's a complete language with strong semantics. (If you have kids you should try it out on them. If you don't, you should try it out on yourself.)
Ken Kahn really deserves huge appreciation for the brilliance of the ideas in his software; I'd like to see him receive the Turing Award for this work; I think it will prove to be incredibly influential. I am absolutely serious. Don't be mislead by the cartoon style that it employs.
Jeff
[There are no doubt numerous errors and ommissions in the text below. Please mod any corrections and additions up.]
:-) Europe is made up of lots of countries, two of which, simply for example, are the United Kingdom (aka Britain) and Germany. We've banded together under the banner of the European Union (EU), each as sovereign nations, delegating some roles and responsibilities to the EU where it is in our interests to co-operate. One such example is monetary union - a number of EU countries abolished their currencies and now share the same currency.
A primer for those of you that aren't in Europe and also for those of you who are in Europe who find the whole thing confusing...
Europe is a place to the East of the USA, across the big bit of ocean.
One of the chief issues that the central bodies take care of is 'harmonisation'. Harmonisation is about creating a level playing field across Europe, chiefly in legal and economic senses. A main tool for this is the Directive. The central body consults, then draws up a Directive which outlines a part of law, then the Directive is implemented as law in each of the EU countries, and thus the laws in each country come to some sort of standard.
The current argument concerns a draft Directive.
To understand how a Directive is agreed, you need to know who the players are...
The EU has 5 central bodies of which 3 are of immediate concern with respect to the Directive. The Commission, the Council and the Parliament. The Commission is chiefly to manage things European. The leaders of the Commission (Commissioners) are nominated by national governments and have portfolios. The Parliament is directly elected by the people of Europe in a using a proportional representation system (is this true across all of Europe? It is in the UK.) The role of Parliament is to scrutinise legislation. The Council is composed of representatives of the national governments, and as the Council web page says, this is the main decision-making body, and where the power lies - in national governments making decisions together.
So what's the process involved in agreeing a Directive and where are we in the process?
There are numerous arcane rules concerning the process by which Directives comes into being, and it depends on what the legislation covers. For the Computer Implemented Inventions Directive, a draft directive was prepared by the Commission and ratified by the Council (someone - is this right?) and then put before the various committees of the Parliament for comment and voting. Then it went before a Parliamentary plenary sitting, who voted for numerous changes of the original Council version. The legislation then went before the Council once more. They decided to ignore the Parliamentary ammendments and the requests of various parliaments of various countries to restart the whole process, and have decided to send the original Directive (with minor changes?) back to Parliament for the next stage in the process. Parliament has yet to vote.
The rules for the first and second plenary vote of Parliament are different. The second round has a much higher barrier to introducing changes - an absolute majority is required (someone?) - and if the barrier is not passed then Parliament is assumed to have no objection to the legislation, and it will become a Directive.
Understand from all of the above that it is the national governments that are driving this legislation forward.
Is there a need for a Directive at all?
The need for harmonisation has arisen because different European countries have different standards for judging the allowability of patents involving software, which means that the same patent has been allowed in some countries and not in others. Often the figure of 30,000 European software patents is quoted. (Does anyone know were this comes from?)
It's easy to see some examples of the sort of thing that has been granted - the European patent office is on
"Even if your memory used is nowhere near what your physical memory is, you will notice two things:
1. Your system still consistently uses the paging file
2. Every time your system uses the paging file, your disk queue length spikes"
Yes, you are right.
Microsoft Research have tried this experiment: they bought a lot of RAM, and made a build of Windows with virtual memory turned off to see what happened. They expected it to go much faster. But it doesn't work. The problem is that lots of developers don't trust the integrity of physical memory, and deliberately, continuously write stuff to disk. Consequently you get slow down anyway, with the disadvantage of occasional errors from untested situations.
The interesting part is that virtual memory was needed because RAM was expensive so there wasn't much of it. And now it's not. So there's no need for virtual memory any more.
Expect future operating systems to dispense with VM.
There are two classes of application that web browsers are very bad at: rich UI interaction - for example graphics editing - and interactive data apps.
There are workarounds and bodges that can help, but they depend on Javascript and you can't be sure that everyone will be running Javascript, let alone that there is consistency at the DOM level.
There are two things that web applications are very good at: rollout and global availablity. Wouldn't it be great if we could have it all. XForms is a step towards that, targeted at data manipulation applications.
For this sort of application, you very often need to update the information presented, at a field level. So for instance, on a desktop application, you might have a field where you can enter a name, and as you type, another control presents a list of possibilities which dynamically changes. Typing 'S' would show you 'Smith' and 'South' and 'Smart'. Adding 'm' would reduce the list to 'Smith' and 'Smart'. And so on.
To do this properly, you need to be able to have sub-page queries of the web server/web service/database/whatever, or you need to download the whole index and filter at the client (yech). And you don't want the whole page to refresh. So it's not something that HTML as it stands can do, without workarounds.
From the XForms FAQ, here's a list of some of the things that can be done with XForms that aren't possible in HTML:
* Check data values while the user is typing them in.
* Indicate that certain fields are required, and that the form cannot be submitted without them.
* Submit forms data as XML.
* Integrate with Web services, for instance by using SOAP and XML RPC.
* Submit the same form to different servers (for instance a search string to different search engines).
* Save and restore values to and from a file.
* Use the result of a submit as input to a further form.
* Get the initial data for a form from an external document.
* Calculate submitted values from other values.
* Constrain values in certain ways, such as requiring them to be in a certain range.
* Build 'shopping basket' and 'wizard' style forms without needing to resort to scripting.
If you are interested in XForms, it's also worth knowing about Web Hypertext Application Technology Working Group (WhatWG) - http://www.whatwg.org/ who are working on specifying an extensions to HTML to allow richer applications. One of the projects is Web Forms 2.0 which aims to specify form extensions for HTML and XHTML.
Both of these are excellent initiatives which could make the life of web app developers Better.
Mozilla starting work on XForms is terrific. The competition may spur Microsoft on... MS are not very keen on anything that reduces the dependence of users on desktop apps. For them, this is a very sensible strategic position because their income stream depends on continued need for their OS, and that in turn is because applications are bound to their platform. Consequently they haven't been especially fast to embrace (or extend) standards which would make it easier to deliver rich web applications.
Don't bother to weigh in with MS-bashing. You are wasting your time and this is not what the para above is about.
Jeff Veit
Here's what XFree say:
That's pretty clear.
Here's the two clauses that are contraversial:
The 'above copyright notice' is "Copyright (C) 1994-2004 The XFree86 Project, Inc. All rights reserved."
and
Nowhere does that say any thing about including them in advertising.
It does say that you should acknowledge them.
It's a form of payment. In just the same way as you the GPL requires you to pay by returning derivative work to the GPL pool, one of the XFree items for payment is inclusion in credits. There is nothing morally wrong with requiring to be included in credits as a cost for use of a work. It's wrong to deny someone credit for their work. So the solution is to sort out a mechanism where there is no burden to bear for crediting.
I reiterate...
The point of my original comment is that it needn't be a burden to any of this if only there was a sensible automatic mechanism for gathering the information.
The basic problem is that there is no convention for listing contributors. You would think that it was not beyond the intellect of FOSS developers to come up with something suitable.
For instance:
If the standard was that the flag -contrib listed contributors, and dedications, together with the name of the program, then it would be simple to gather a list. And the work of gathering a list is what teh complaint is about.
Once you have the list, it's not difficult to display it on request or put it in a file.
It might also be a good idea to have a standard comments format (easily parseable) at the top each source file with the same info. You might need to define a format per language. I'd imagine something like
I've used an XML style above, but don't get hung up on that - it's a detail that doesn't matter right now. It could be
And guess what.. if you have the list in the source in a standard format, you can easily create the code for the contrib flag.
Really it's plain old good fashioned courtesy. If someone creates something that you are using then you should be acknowledging it.
And now for a political subtext... The whole issue with the naming GNU/Linux vs Linux is about attribution. To my mind it's unreasonable on the one hand to campaign for recognition in this way, and on the other to have a GPL that is incompatible with giving credit where it is due. It seems to me that there is a strong streak of not-invented-here at work.
Bozo.
If you believe in Open Source or Free Software then you should believe in copyright. If you find a GPL code in use in a closed project, then you should report it to FSF. If you find Windows code in the wild then you should report it to Microsoft. It's their code and consequently they should and do control who gets to see the code.
That said, I would desperately like MS to release the code under an open-source, but closed-project style licence; that is, the code belongs to them, and for any derivative code MS is automatically granted a licence to to sublicence and do whatever they wish. It should not be permissible for the code to be included in another product without the explicit say so from MS. Microsoft could protect theselves financially by being the only source for binaries. BillG are you listening? Win2K, with open source could be sooooo good, and you would still make a stack of money. Plus you'd have a huge team looking at improving the software, for nothing.
It's worth a shot if the code has escaped. At worst you'll get a second product line.
I want to say first that it depends upon the culture of your company. You also don't say at what sort of level you work in the company, so I'm assuming at least several levels down from the management.
If you are peopled by weasels (is that possible?) then the best advice is always to watch your back.
If your company is hugely political then politics is valued and it's best to approach it like that.
On the other hand, the fact that your management is meeting you at all suggests that you are working in a well-balanced company. If that's the case you should speak the truth when asked, without dumping anyone in the muck; that's a good way to make enemies. You should be polite and only discuss major points.
Your management has a different view on the company from you. They have to take the whole company into account, and you are naturally most interested in your corner. Having a bitch about the cubicles in the IT area won't win bonus points, but if you talk about how the sales people don't have good enough kit for their jobs you will. So - focus on what are problems for other people, and how to solve them.
Don't expect your management to do everything you suggest - and don't get despondent if they don't do the things that you think are most important. They have to prioritise across the whole company and should be giving weight to those areas that will bring the biggest benefit to the whole company. This doesn't mean that they didn't hear what you said, and didn't want to do anything. It may simply mean that there are higher priorities at the moment.
Do talk to your management as if they are people and not uber-gods. Try to avoid geek-speak. Do dress smartly - even if you wouldn't normally - it will reinforce your point of view. Don't drink much - you don't think as well - even though you are convinced that you do.
Hope that's some help.
Jeff
For you geographically challenged people. Africa is a whole continent. Like North America, South America and Australia.
South Africa is a country. It's at the tip of Africa. You'll never guess where it is in Africa.
It was a British Colony, but gained independence about 55 or so years ago, and promptly began to institutionalise pernicious racially-based discrimination. It was called Apartheid. After a long struggle (40 years) the white people agreed to share power and democratic elections took place. Nelson Mandela (you may have heard of him) was elected president.
The economy of South Africa is split - there's a strong first world component, and a large third world component. The first world component rivals the economies of Europe and the USA in sophistication - though it's much smaller. The third world component - i.e. subsistence farming, and subsistence trading - involves many more people. Unemployment rate is high - a few years ago it was 40%. Not sure what it is now. HIV/Aids rate is probably the highest in the world - hitting around 10% of population. Some places have rates as high as 40%. The current government until recently has ignored the problem.
Eskom is a world-class power utility. They have existing nuclear reactors, which were learning grounds for the Apartheid state in their quest for nuclear weapons. (Ten or so years ago South Africa admitted that they had nukes, and then destroyed them. Thank you Nelson Mandela and South Africa for making the world a safer place.)
It's questionable whether South Africa needs more nuclear power plants but Eskom has traditionally had a strong technocratic streak. (I was an employee a long time ago.) SA is rich in coal and natural gas.
I personally think that the money could be better spent given South Africa's problems - the only justification would be to export the technology. And maybe greater access to nuclear expertise is not what the world needs.
Jeff Veit
The situation is somewhat more complex than presented in the blurb.
Patentability of hardware is a well accepted principal. But what if the hardware contains software? For instance when it's a cellphone. Should the hardware still be patentable? What if the phone is only special because of functionality implemented in the software portion? For instance if it can talk to a Jabber server. Should it then be patentable because of the special features?
Now what if it's not Jabber, but some other IM server and the intelligence is in the server. Should the system of phone plus IM server be patentable? If not why not? If yes, then aren't you allowing patenting of software on general purpose hardware?
So that's the background.
Having organised a couple of meetings on the issue in Cambridge, I'm of the opinion that the case that the directive is damaging is overstated. The author of the language of the amendments introduced in JURI says that by the nature of the EU system the language can't be very tight, but that a key feature is that patentability can now be reviewed by the courts, and that JURI has made its wishes clear in the Recital, which courts use as a guide to the intention.
There is still a crucial issue of how Free and Open Source software authors are protected. The directive is inadequate in this regard, but then the situation as it stands is inadequate. We need to take a social decision that protects authors of Free and Open software because they make the efforts of their labours available without charge and that's to the benefit of society.
An interesting side effect of such a settlement would most likely be a decrease in software patenting in favour of the use of trade secret. This isn't necessarily a god thing; patents were invented to make it possible to expose trade secrets in return for a limited monopoly on their use. An example - if you invent the ultimate search algorithm but kept as a trade secret it might never enter the public domain.
A second serious problem is the length of a patent - around 20 years. For software, which typically has a life span of 5 to 8 years, this is ludicrous. On the other hand it typically takes around 2 to 4 years for a patent to be granted. But software intro cycles are around 12 to 18 months. So unless you have a spectacularly good invention, or some indirect need, it may very well not be worthwhile patenting. (The number of patents involving software suggest that this isn't generally true - numbers of 15,000 to 30,000 in Europe are commonly reported.)
The way to solve the problem of software falling under the same banner as hardware is to alter the European Patent Convention to vary the rules for software. This won't be easy, but it's probably possible.
Jeff Veit
Power grids are much like a tower built of cards... They have to be maintained in a delicate equilibrium. Both too much power flowing in or out and too little power flowing in or out are bad things. At the same time grids are evolved - bits are connected to other bits when it becomes possible, so they aren't regularly structured.
(There's a really interesting problem of determining a fair/best representation of the state of the whole system from incomplete and possibly faulty data from many sources. I once had the pleasure of working on such a system.)
Because there's such inter-dependency between portions, and because too much and too little is bad, there are automated isolation switches at many points in the system. They respond either to local conditions or according to a centralised control room. Most often they respond to local conditions because the control room doesn't have a fully real-time picture of the whole network. (And even if they do, it's possible for it to be incorrect.)
So, if you have a little accident in the wrong place, a fault can propogate through the system, triggering automated shutdowns. In fact it's probably not possible to design a network with local decision for these safety valves where this can't happen. I think that this has been shown theoretically, but I'm not sure - it's been a few years.
There can be HUGE difficulty in bringing the system up again. It's not something that you can easily test your disaster plan against, and the sequencing of supply and demand is important in order to avoid automatic trip states.
It's entirely feasible that it may take weeks before the network is restored to a similar state. The worst scenario state could involve months.
That's the technical aspects.
But there are underlying reasons that may have contributed to this happening.
1. Competition. Competition is a two edged sword. Because electricity is a commodity, the primary way you can judge companies is on price. The cheaper it is for you, the better. That's good for consumers. So a large force, in a market economy for electricity is towards cutting costs.
But when you don't have enough money, spending it on averting possible disasters is harder. You switch to risk management techniques instead of risk removal. Especially since the cost of failure is bourn more by your customer than you.
2. Insufficient planning. Most networks aren't homogeneous. They are owned by more than one company who co-operate. Sometimes laws stop companies co-operating on areas where they should.
I think that the US should take this as a great big cluestick. I wonder how much this cost? It turns out that unregulated or markets with low amounts of regulation sometimes create failure. Sure, they are cheaper, but sometimes they are disasterous. It's important to get the balance right, and it differs for different products so ideologically driven decisions are likely to produce bad effects sometimes.
Secondly, if you are aiming to change things from a known safe state to a new unknown state, a carefully controlled, slower, planned change can have a lot of advantage. It may cost more, and be non-optimal in terms of time, but time is more easily measured than safety margin.
As well as technical things like powere grids, I'm thinking of regulated to less-regulated markets. Of non-GM food to GM-food. Of world trade policies and intellectual property right expansion. Of privatisation. And more.
Apparently the Pentagon sees no compelling reason for an alternative to GPS. Oops, that would be before they checked their GPS units round about now. Oh wait, I forgot, they have their fingers on the buttons, perhaps that why they can't see a compelling reason.
Oops look; those pesky photons might interfere with each other
On the other hand, to be fair, the US could have just degraded the signal without announcing it. At least now ships and planes probably won't be piloted into rocks.
Here's one - http://www.onebamboo.net/ .
BUT, history shows that it is almost impossible to go up against an incumbent pervasive technology with a similar technology. The new tech has to offer a great deal more for people adopt it in large numbers. This is not to say that there won't always be unusual keyboard variations - but it's likely that these will be marginal.
And now an advert: I know about One Bamboo because they are members of the Cambridge Hi-tech Association of Small Enterprises. Anyone reading this near Cambridge, UK could be interested. http://www.chase.org.uk/ Two meetings a month - the next is a pubmeet at the Free Press on Tuesday 18th - 8pm.
Jeff
I think it was Buzz Aldrin who tells this story as an explanation for the moonshots and the drought: one day he was watching this small dog out his window. And a car came driving passed and the small dog barked wildly and ran off after the car. And a little way up the road the car parked so the dog caught up with it. The dog was surprised for a moment, then he peed on the wheel and came back, looking pleased with himself.
It's economics, dummy.
The same as with almost any product - games fail for a range of reasons. Some obvious ones:
1. No customers. Design for hardware that people do have. Not the hardware that they might have. I bought 3dfx kit when I last built a PC. I might buy a GeForce card now, but it's unlikely that I will buy a card to play a game that I can't testride without a GeForce. Doh!
2. No coherency. If you don't meet the minimum requirements in terms of plot, gameplay, programming, visuals, price, then you are doomed. You can trade off one for another, but if you fall below the minimum acceptable standard on any of the important metrics then you've got a dud, regardless of how good the other metrics are.
3. Lack of marketing. If the public don't know about the game then they won't buy it. Technical prowess is not enough to bring masses of customers. (That may be quite surprising to all us technerds, but it's true.) It's a surprising but true fact that a crap product can be rescued by good marketing, but a good product is amazingly unlikely to succeed without marketing. (If you develop then learn to love those people who want to gush to the world about how your product is 'REVOLUTIONARY!!!!!') Marketing is often more expensive than the cost of development.
4. No channel. If you can't get the game into the hands of your customers, then you don't have a product. Building a channel is usually more expensive than building the game.
5. Bad management. It's the job of management to make sure that all the bits of the puzzle fit together. Forget just one and the game can fail. So you'd better be able to juggle well, love people, find technical problems fun, enjoy budgeting and project planning.
Products succeed because:
1. They address the needs of those that play them. They mix the plot, gameplay, programming quality, visuals, price elements so that there is a very attractive package. The more attractive, the more likely that they will be bought. Perhaps the gameplay is brilliant despite the visuals, perhaps the gameplay is quite dull really (first person shooters) but amazingly interactive. It helps to have one or two people who share a vision to bring this one off. It also helps if they can adjust their ideas in the light of circumstances. And committees don't work too well at making fun things.
2. They address the needs of a diverse audience. Your audience is more than just the buyers. Frinstance, you need the press on your side too. You need to be able to give marketing people hooks. You may need to address parents' concerns if they are likely to provide the money. Omit a key target audience and you'll likely fail. The needs of the different audiences are different. A journalist might not play your game at all, but might write about it - they need interest factors in an easily digestable way. If a journalist does play then they may only play for 5 minutes, so those minutes had better be well thought out, easy and exciting. If three of them are dull then you've lost your chance. And the needs of different sorts are journalists are different - for instance a good TV report needs some stunning visual elements.
2. They are the right thing at the right time (and luck). Because the bar on plot, gameplay, programming, visuals, price are constantly rising, you'd better meet the demands at the time you publish, and not at the time you start developing. It's tough, but you can make a brilliant game that's at the wrong time too. Games that have elements that involve crashing planes could come in for massive knock in the aftermath of a real plane crash. Perhaps a much bigger competitor releases a brilliant title 2 weeks before your game goes on sale - you'll probably take a hit because you can't afford the level of marketing they can. Or perhaps you make a shooter just as the shooter market tanks.
Most the ones that fail are the ones that don't understand that they work inside a larger world and plan accordingly.
Now, did you notice that I didn't even use the word 'engine' in here. That's because it doesn't matter. Gasp! The greatest engine in the world makes stuff all difference if the other elements aren't in place.
That's enough - back to programming...
Yes, blue is the colour that they have the most problem with - it's the most unstable. In the labs they have blue up to 1000's of hours lifetime. But to compete with consumer goods like TV's and monitors they need much better performance.
Imagine your TV is on for 4 hours a day, and you keep it for 10 years. That's 14600 hours, with no margin of error.
It is quite likely that they will overcome the problem with blue...at the moment there isn't a full theoretical model for why Light Emitting Polymers work, and progress is through empirical testing.
No, you probably can't make a fibre. The pixel addressing would be a huge issue, but that's not necessary providing you have a flexible substrate material.
Jeff Veit
www.tanasity.com and www.tangledtime.com
The head of technology and strategic planning spoke. Despite the hype-ticle on CNN, it was clear from what he said that you shouldn't expect flexible displays any time soon - probably not inside 10 years. I don't get a T-shirt with space invaders on it any time soon. You can expect conformable displays within a few years - i.e. rigid, shaped screens. However it's likely that you will see other companies building these; CDT is an IP company. They hold fundamental patents on light emmiting polymers. They aren't just a holding company; they do develop technology, but their basic strategy is to licence to others. They will have bought Opsys to strengthen their patent portfolio.
If you are currently building hardware that needs small mono screens you should definitely check out CDT. Their displays have superb characteristics - an almost 180 degree viewing angle, bright even in sunlight, and very low power requirements. The examples of the technology that he showed were very 'version 1.0', but show brilliant promise.
Next CHASE meeting - 12 Nov - Invisible Networks are building community broadband networks in rural villages around Cambridge. Currently using 802.11.
Jeff Veit
www.tanasity.com and www.tangledtime.com
There is enough bitching about the music industry here to make me want to puke.
Get over it. It's a business. Their job is to maximise profits. It's worked pretty well so far. Screwing the artists has obviously paid well. But there is an need for record companies; they front the money to make albums and they promote music.
(Please note I do not say that there is a need for them to earn the profits they have historically. But that's probably got more to do with the lack of competition. And the lack of competition is traceable back to the lack of substitutability of the product; if I think that a song by one artists is great, but too expensive I am not going to buy a record of another artist singing it instead.)
Action speaks louder than words. If you don't like the situation, then do something about it.
So my question:
Who is doing things to change the market?
I can imagine:
- Web sites that allow bands to post music for download in return for payment.
- Web sites that allow music trading in return for payment to the band
- Web sites that help bands to auction themselves to labels allowing competitive bidding.
- Micropayment services.
- Services that promote bands by letting people find music that they are likely to like.
- Distribution licences on music allowing you to further distribute in return for payment.
So who are the people and companies that are already doing this?
(Remember that not many of the buggy manufacturers became car manufacturers. Not many of the cold typesetters turned into desktop publishers. And it's likely that not many of the large record companies will be the ones who are our primary source of music in the near future.)
Jeff Veit