What if I invent a new and technically useful process for effecting interprocess memory transfer? That's not a mathematical process. It is a software process. I should be able to obtain a patent to protect it.
> Yes, but the point is: you don't need it to protect your software products.
Yes you do, someone can just reverse-engineer the code to discover the mechanism and use it, unless it was patented. Equally, if your code is leaked (aka Microsoft) then someone can extract the inventive idea.
> Furthermore, how many inventive elements are there in software?
> by the EC? If that isn't a single source of law, I don't know what is.
And it is refined by the ECJ - the EC may set the law, but thec courts refine it.
> Of course they exist NOW. But can they continue to exist after software patenting is legalised?
Software patenting is already legalised. Didn't you see the FFI web page about 30,000 patents?
> You can let a patent lie for a decade before starting to litigate.
Not if it was reasonable that you had knowledge that the patent existed. In the case of closely related products, this likely.
> The technical requirement was added by the Parliament. It was scrapped again by the Commission. The current proposal does not have the technical requirement.
Then I agree that this is wrong.
> No, I did not check. Who the hell could check 30,000 patents? If 30 GNU projects claim they will have patenting problems, that does not mean the rest of them are problem-free. They just didn't check. I mean, if I am a software engineer, I am usually not interested in law and legislation, so why should I spend my valuable time checking up on 30,000 patents when I could spend it writing software?
If they are arguing over how software patents cause problems, there are two approaches (a) present the evidence, (b) present the FUD. Without performing the researhc, they are presenting FUD. Arguments should always be backed up with claims and evidence.
> Software designers are simply not a powerful pressure group, and they are not cool enough to be adored by the public.
Not in general, but arguably every so called "software patent" results from the work of a software designer. If there was really support for no software patents, these designers should take direct action and not support patenting.
Firstly, the EU directive just _harmonises existing case law_ - without the directive, what's going to happen is that different EU states are going to take different approaches and thus it will be a nightmare.
Secondly, the EU directive _actually reduces the degree of software patentability_, because currently after IBM, claims to "programs on a carrier" are allowed, but the directive removes the ability to claim this. This is a good thing.
Thirdly, it's been stated over and over again that there are "multiple software business models" at work in Europe, and there's no specific reason to favour closed model approaches to open model approaches: they all work, and provide revenue and so on.
Fourthly, in terms of "software patents blocking open source", well there's a very small list at GNU when Stallman asked which projects were being affected by patents, and in fact this is how it should work: it's to be expected that some patent owners have developed inventive appraoches that they are holding away from open source - fair enough, it's the perojative. It doesn't seem as though Linux, OpenOffice, mysql and numerous other open source products have been affected anything more than trivially. There's only FUD being suggested that "it might be a problem" in the future.
Fifthly, the EU always maintains more stricter examination than the US: business methods per se are _not_ patentable in the EU, and equally, flakey software patents have a harder time getting through. Stop transposing the failures of USPTO into the EU.
Sixly, for the so called "30,000" illegal software patents issued over the last 30 or so years or whatever, I repeat that the GNU list suggests that less than 0.01% of these are impacting open source. That's amazing! And hardly a justification to pull the system apart.
Finally, the protests in Brussels are are a laugh: against multimillion dollar turnover businesses using patents and contributing to the wellbeing of the EU economy, you have a bunch of jokers with "terrorism is corporate suicide" and other fairly poor and non-objective slogans doing pantomines. Unless the arguments show facts and figures, and more substantive evidence, this is entirely dismissable.
> Is it a nightmare now? No it isn't. Software is protected by copyrights. What more is needed?
You don't understand. The inventive elements within software are not. You can't protect a novel inventive way of reducing interprocess memory transfer by copyright. You can with patents.
> No, it doesn't. Despite the fact that the EPO has granted 30,000 software patents, they are actually forbidden by EU law and thus not legal. The new proposal attempts to legalise them.
Wrong. The law is made not just by the legislature, but through the courts and the boards of appeal. There is no "single source" of the law, it's a refinement process.
> A system where software patents are allowed, in practice kills off all small and medium-sized businesses.
So there are a not large numbers of SME's producing software in Europe? Your theory goes against current fact. It is true that patents are not as useful or relevant to SME's as they are to larger companies though.
> Ah, but that's where you're mistaken. I am dead certain that all open source software violates some of the granted software patents.
Perhaps some of the dodgy patents.
> When one of the big guys desires to kill some open source software package off, they just need to litigate.
It's not this simple: if the product exists for some period of time, the patent owner just can't come along "as they choose" and litigate: they will be barred unless they took action earlier.
> Again, you are mistaken. True, at the moment business methods are not patentable. However, as soon as software patents are allowed, business methods will become patentable. Just write down the method and slap "with a computer" or "over the internet" on it, et voila, you have a viable patent.
Wrong. You don't understand how the EPO works: it (a) always requires a technical effect, and (b) a joint USPTO/EPO/JPO meeting in 2002 agreed that business methods _should not be patentable_. This is their desire.
> That is what you claim. Where did you get that number from? Admit it, you just pulled it out of your %$@#*. Let me pull a number out of my %$@#* too: I think it is more like 99%.
Wrong. That is the fact. The FFI says "30,000" software patents, and the GNU list (did you actually check?) shows less than 30 problems. You should do your research. If there are more problems than this, they don't open source producers bring them to light: that would be a better way to justify the situation.
> But, true, the man-in-the-street won't be roused from 300 people walking with supposedly funny slogans.
We agree: I have no problems with the arguments by the open source movement: but I feel they do a bad job in presenting them in a professional and objective manner. Because of this, I think that decision makers start to dismiss their claims without giving them proper consideration.
> My understanding of what happend is something like:
You are full of shit. I bet you just made that up so you get modded up and present an entirely false argument to readers.
What happened was: * the concept of excluding "computer programs as such" has been refined over time: software patents are allowed _only_ if they should a concrete "technical effect" (in the US, it is different: they only need to be "useful and produce a tangible result") by case law and appeal board hearings; * the EPC (european patent convention) is _entirely separate_ from the EU (european union), and thus the case law is developed on a national basis; * over time, the national courts have adopted subtly different principles; * this is becoming a problem because it impedes the common market when different national states apply different approaches: since the goal of the EU is to provide market harmonisation; * to resolve this, the EU directive is proposed that enforces a common approach across the EU (and, upon any members of the EU that are part of the EPC).
Let me re-iterate: * if this EU directive does not go through, then _software will still be patentable_ -- do not labour under the false impression that this directive is able enabling software patentability: software is _already patentable_, this directive _does not change that_ (in fact, it actually restricts it slightly). * thus, software will remain patentable, but not in a consistent way: this is even worse because some member states may actually take a very relaxed approach and allow patentablity of software.
Thus, by stopping this directive, the situation gets worse.
The EU has done this before on patentability of biotechnology: it in fact restricted what could be patentable, it expressly prohibited patentably of gene sequences, germ like modification, human cloning, etc.
In the same way, the EU does not want "open the floodgates" to unlimited patentability, it actually wants to restrict it and to control it to ensure proper harmonisation.
I bet the majority of people reading this have no idea about these issues, and simply respond to the spectre of "patentable software".
> If data structures are patentable does this make it possible to prevent interoperability?
No! The courts have continually prevented patent owners from enforcing their rights in circumstances that would restrict competition: and interoperability is one of them.
In the UK, the famous British Leyland case found this. It is codified in UK copyright and designs law.
Firstly, the EU directive just _harmonises existing case law_ - without the directive, what's going to happen is that different EU states are going to take different approaches and thus it will be a nightmare.
Secondly, the EU directive _actually reduces the degree of software patentability_, because currently after IBM, claims to "programs on a carrier" are allowed, but the directive removes the ability to claim this.
Thirdly, it's been stated over and over again that there are "multiple software business models" at work in Europe, and there's no specific reason to favour closed model approaches to open model approaches: they all work, and provide revenue and so on.
Fourthly, in terms of "software patents blocking open source", well there's a very small list at GNU, and in fact this is how it should work: it's to be expected that some patent owners have developed inventive appraoches that they are holding away from open source - fair enough, it's the perojative. It doesn't seem as though Linux, OpenOffice, mysql and numerous other open source products have been affected anything more than trivially.
Fifthly, the EU always maintains more stricter examination than the US: business methods per se are _not_ patentable in the EU, and equally, flakey software patents have a harder time getting through. Stop transposing the failures of US into the EU.
Sixly, for the so called "30,000" illegal software patents issued over the last 30 or so years or whatever, I repeat that the GNU list suggests that less than 0.01% of these are impacting open source. That's amazing! And hardly a justification to pull the system apart.
Finally, the protests in Brussels are are a laugh: against multimillion dollar turnover businesses using patents and contributing to the wellbeing of the EU economy, you have a bunch of jokers with "terrorism is corporate suicide" and other fairly poor and non-objective slogans doing pantomines. Unless the arguments show facts and figures, and more substantive evidence, this is entirely dismissable.
> The graphing in Excel is basically the same as it was 15 years ago, for example. The core userbase is Finance people, and it will never expand to Engineering, Academics, etc.
You made my point better than I could. Anyone who says that "Excel is useful for Engineers" either (a) doesn't know anything about Engineering; (b) doesn't actually do any useful Engineering; (b) is quite a power-user of Excel beyond the average competance that a normal Engineer can dedicate to a single application.
> I disagree, excel is the STANDARD for number cunching and for good reason.
You are obviously not an Engineer. Yes, I see project and senior and product management using it all the time. It is the standard for them. It produces pokey, useless and unsophisticated charts. Exactly not what I need as an Engineer.
By the sounds of it, you are also a power user. Well, thats fine for you, but as an Engineer I'm too busy Engineering and I don't have time to learn all of the inns and outs of Excel. I want the tool to allow me to do relatively user-friendly way from go.
Compare to a DTP like Word: without having a power user ability, it's quite easy to start doing fairly sophisticated content organisation, layout, etc. In comparison, Excel remains a lifeless 2D spreedsheet application.
Microsoft had plenty of opportunity to innovate: Excel is an extremely poor tool for doing anything other than basic graphs and calculations. For engineering purposes, it's near useless.
The fact is that piracy levels are there. If updates against these critical security issues are not publically available, then the infected pirated machines are a social nuisance. These people are unlikely to buy a legitimate version anyway.
However, it should stop at critical issues: anything related to bug fixes or performance or reliability issues only available to licensed users.
Look at some of the AV companies: they do provide free disinfectant tools for critical issues: you can download and use these even if you are not the AV customer. However, if you want true AV support, then you do need to buy the product for the licensed updates.
It depends upon a number of issues, though you'd expect that coke's manufacturing process would produce cans with good tolerance levels, and the "radio can" could be quite outside of the tolerance. I would expect them to have covered this by ensuring the radio can comes up to the same weight.
coke needs to be smart and ensure that the can weighs _exactly_ the same as an existing can, otherwise, everyone who works at a shop or distribution channel could weigh the boxes or pallets and discern the differences.
Equally, another way to cheat would be to be use sort of low-tech radar/xray device that can detect different types of solids (for example: cans and liquid are pretty simple, but a radio has a lot of complexity that'll generate signal splatter).
Another way [:-)] would be to see if you can generate radio signals at right frequency to induce resonant effects in the antenna within the can.
This type of low-tech gear wouldn't take more than one or two cluey engineers and weeks work of work.
A lot of this discussion here is either crap, a rehash or was covered in Engineering 101.
Basically, you have some requirements for the product, and you optimise according to those requirements. Performance is just one variable (time to market, scalability, reliability, security, usability, cost, etc - are the many others).
The requirements for a product in a fast moving market entry company are less about performance and more about rollout ASAP.
The requirements for the same product two years later may be to improve performance to achieve scalability requirements.
If you're writing some sort of overnight build or batch application: whether it takes an extra hour or not may not matter, because it has a 12 hour window to run in.
If you're writing an order processing system, then performance and end-to-end turn around to will be vitaly important, but you won't focus on the assembly, you'll focus on the algorithms, design and architecture.
If you're writing a compression or encryption module: you probably will work on the assembly.
All of the above cases, before you optimise anything: you profile and understand how the optimisation is going to pay back in real terms.
In my experience, you cannot prescribe any of this: you need to take it on case by case basis because every product and circumstance is different.
This is probably about right: just remember that even though Longhorn may arrive in 2005/2006, it is likely to have an expected product lifetime of (say) 5-10 years (think Windows NT/2000/XP). This means that the average is planted somewhere midway into the envelope, say 2-3 years. I'm guessing that by 2008, these technology characteristics are properly not too far off base.
I'm sure someone could sit down and do the numbers for us by extrapolating on CPU and hard drive rates and moore's law as it has occurred over the past couple of years.
I mean, design is all about tradeoffs: we don't design in assembler any more because the playing field has moved on. We don't design UI's from scratch, we use UI 'builders'. In the same manner, we don't design for todays technology when we expect our design to work with tomorrows.
If Linux didn't design for MP and scalability now, then it would be hosed by the time MP became "default" for the desktop (well, in fact, with HT, it already is!). Yet, designing for MP now causes some performance and related loss even though the technology is not here.
Who am I trying to lecture Engineering and Economics 101 to the/. masses.
Validity is actually pretty easy to attack. The problem is whether a well-funded and resourced opponent wants to try and drag you through litigation.
The large amount of bad patents allowed through by the USPTO may be on the patent register, but they are as good as invalid because they would never hold up reexamination or counterclaim for invalidity. In this case, you simply go ahead and ignore the patent.
> To get a patent, it doesn't have to be better than anything else, or even "inventive", it just has to be different and "useful" (i.e., it kind of works).
You obviously know nothing about patent law. I suggest you have a read of 35 USC 17, especially ss 101 and 203. Don't forget that there's a difference between the poorly functioning USPTO and the more stringent tests applied in infringements.
Your comments re "vendor lockin" are noted: an interesting proposition, but not workable: market forces are better. There's no need to make special consideration for compatibility: that's why people develop competiting technologies (png, jpg) to (if they can) avoid someone elses patent. If they can't, or they don't have the time/resources, they pay royalties. The issue of compatibility only becomes a problem with monopolies, cartels and so on. In some countries, anti-trust/competition laws already ensure that interoperability considerations can supercede IPR protection; which is how (for example) generic printer ink and generic car spare parts manufacturers can survive.
> Christ, they're trying to patent image compression
Maybe they've developed a new inventive approach. If so, fair enough. If not, then the patent will not be enforceable and they've just burned cash on it.
> No we're not. The patents describe the technologies, not how to implement them.
Umm, you do know that it's a necessary condition of patentability that the invention is sufficiently disclosed so that it can be worked by one skilled in the art. If not, then the patent is declared invalid. Again, they will have justed wasted their money.
> If you can't win in the marketplace......use the courts.
Umm, but this is winning in the marketplace: you invent the technology first, so you gain temporary market monopoly for disclosing your invention through the patent system.
In other words, rather than _never_ seeing the internals of what makes Windows tick (until someone releases the source code...) we're actually seeing the internals now.
Rather than relying on trade secret / obfuscation to protect the ideas/concepts, now they're employing patents.
Of course the system is open to abuse (like any system, such as file transfers on the Internet...).
The standards bodies (W3C, IETF) should continue to act as guardians, and _only_ work on and approve standards that are not encumbered. Of course, just remember that there's no technical dictatorship in the world, so a standards body only has as much market power as its participants: which may not be good enough against a large monopoly like Microsoft: and this is exactly why we have large EU style antitrust rulings that are forcing Microsoft to open up interfaces and so on to competition.
I was looking at DIY something like this (since I am competent in building BSD/Linux systems from scratch):
- 3.5' IDE based HDD - 3.5' or smaller form factor embedded linux/bsd based pc - power supply
There seem to be a number of 3.5' ff embedded pc's, something like no less than 100-200mhz seemed ideal: just needs 16-32mb ram, onboard 100mb NIC and a serial port - anything else is a waste of money. Lots of taiwanese manufacturers making these. Some have inbuild 16mb SDRAM and inbuild CF or at least PCMCIA (for a CF adapter) to put the boot image on. The current drain on these systems I've seen a few quoted at ~4W, average seems to be 5-10W. Low power:-). Mix of ARM, Intel or GEODE processors.
Would be very interesting to hear anyone else who has done something like this, esp. re prices and suppliers, and appropriate CPU type/speed required to service ATA-100/133 + 100MB NIC, and whether 16mb SDRAM suitable.
Something like this I guessed would set me back no more than ~UK120GBP (incl. ~50-60 for 160gb HDD).
It's not overpriced when you consider the total package: buy it and plug it in. We're not just talking hardware and software costs, we're talking cost of warranty, convenience and everything else. It's not aimed at home/consumer use either.
Certainly I'd like one of these in my house, but cannot justify cost.
In fact, I am in the process of converting an old 150mhz notebook into network storage server. If you're wanting to do something at home inexpensively and gain hacker-enjoyment, this is the solution: not only are old notebooks cheap, but they're low power, have built in uninterruptable power supply, are small and compact, and usually with a pcmcia, you can put not only 100mb wired, but wireless 802.11 as well. The only downside is that 2.5' hdd's (if you have to upgrade) are more expensive than 3.5's: I need to replace the old 4gb with at least 80gb.
Previously I ran a website production system for over 12 months on the same notebook. Great value for money, considering it was surplus to my employer and purchased for near-nothing (no one wants to buy old notebooks...).
> Did you just make that up? I googled 'inband compression' and 'in band compression' and got less than 10 hits for each.
No, but it's telephony terminology and I conceed probably not used correctly in this case. I simply mean compression employed transparently within the network (i.e. link level) not at the end of the network (i.e. by the protocol stack / application layer).
> that the data must vary in content.
That's a weak requirement for a competition that allows a large scope of deviation.
It means what it says: the data they are sending is compressible (looking at the tcpdump output) as it consists of repeated alphabetical sequences.
If any of the intervening links employs compression, then the transfer rates are artificial as they represent a function of the data, not a function of the network engineering. This doesn't make for a valid comparison against the other participants.
I looked at the rules and they mention nothing about the type of data, nor about the presumptions of the traffic path.
I conceed there is less likelihood of compression in effect on gigabit network due to compute power required, but it is a question that bears asking.
The assumption could be defeated by a test using (a) packets of entirely same character [i.e. highly compressible], or (b) entirely pseudo-random characters [i.e. not at all compressible].
In fact, the rules don't require that the transfer is validated for this problem, nor to average out any other network effects, i.e. the rules should state that (say) "average of 3 back to back transfers each utilising substantially randomised information".
Slashdot Mirror
What if I invent a new and technically useful process for effecting interprocess memory transfer? That's not a mathematical process. It is a software process. I should be able to obtain a patent to protect it.
It's that simple.
> Yes, but the point is: you don't need it to protect your software products.
...
Yes you do, someone can just reverse-engineer the code to discover the mechanism and use it, unless it was patented. Equally, if your code is leaked (aka Microsoft) then someone can extract the inventive idea.
> Furthermore, how many inventive elements are there in software?
Lots! compression, encryption, memory management, interprocess communication
> by the EC? If that isn't a single source of law, I don't know what is.
And it is refined by the ECJ - the EC may set the law, but thec courts refine it.
> Of course they exist NOW. But can they continue to exist after software patenting is legalised?
Software patenting is already legalised. Didn't you see the FFI web page about 30,000 patents?
> You can let a patent lie for a decade before starting to litigate.
Not if it was reasonable that you had knowledge that the patent existed. In the case of closely related products, this likely.
> The technical requirement was added by the Parliament. It was scrapped again by the Commission. The current proposal does not have the technical requirement.
Then I agree that this is wrong.
> No, I did not check. Who the hell could check 30,000 patents? If 30 GNU projects claim they will have patenting problems, that does not mean the rest of them are problem-free. They just didn't check. I mean, if I am a software engineer, I am usually not interested in law and legislation, so why should I spend my valuable time checking up on 30,000 patents when I could spend it writing software?
If they are arguing over how software patents cause problems, there are two approaches (a) present the evidence, (b) present the FUD. Without performing the researhc, they are presenting FUD. Arguments should always be backed up with claims and evidence.
> Software designers are simply not a powerful pressure group, and they are not cool enough to be adored by the public.
Not in general, but arguably every so called "software patent" results from the work of a software designer. If there was really support for no software patents, these designers should take direct action and not support patenting.
Firstly, the EU directive just _harmonises existing case law_ - without the directive, what's going to happen is that different EU states are going to take different approaches and thus it will be a nightmare.
Secondly, the EU directive _actually reduces the degree of software patentability_, because currently after IBM, claims to "programs on a carrier" are allowed, but the directive removes the ability to claim this. This is a good thing.
Thirdly, it's been stated over and over again that there are "multiple software business models" at work in Europe, and there's no specific reason to favour closed model approaches to open model approaches: they all work, and provide revenue and so on.
Fourthly, in terms of "software patents blocking open source", well there's a very small list at GNU when Stallman asked which projects were being affected by patents, and in fact this is how it should work: it's to be expected that some patent owners have developed inventive appraoches that they are holding away from open source - fair enough, it's the perojative. It doesn't seem as though Linux, OpenOffice, mysql and numerous other open source products have been affected anything more than trivially. There's only FUD being suggested that "it might be a problem" in the future.
Fifthly, the EU always maintains more stricter examination than the US: business methods per se are _not_ patentable in the EU, and equally, flakey software patents have a harder time getting through. Stop transposing the failures of USPTO into the EU.
Sixly, for the so called "30,000" illegal software patents issued over the last 30 or so years or whatever, I repeat that the GNU list suggests that less than 0.01% of these are impacting open source. That's amazing! And hardly a justification to pull the system apart.
Finally, the protests in Brussels are are a laugh: against multimillion dollar turnover businesses using patents and contributing to the wellbeing of the EU economy, you have a bunch of jokers with "terrorism is corporate suicide" and other fairly poor and non-objective slogans doing pantomines. Unless the arguments show facts and figures, and more substantive evidence, this is entirely dismissable.
> Is it a nightmare now? No it isn't. Software is protected by copyrights. What more is needed?
You don't understand. The inventive elements within software are not. You can't protect a novel inventive way of reducing interprocess memory transfer by copyright. You can with patents.
> No, it doesn't. Despite the fact that the EPO has granted 30,000 software patents, they are actually forbidden by EU law and thus not legal. The new proposal attempts to legalise them.
Wrong. The law is made not just by the legislature, but through the courts and the boards of appeal. There is no "single source" of the law, it's a refinement process.
> A system where software patents are allowed, in practice kills off all small and medium-sized businesses.
So there are a not large numbers of SME's producing software in Europe? Your theory goes against current fact. It is true that patents are not as useful or relevant to SME's as they are to larger companies though.
> Ah, but that's where you're mistaken. I am dead certain that all open source software violates some of the granted software patents.
Perhaps some of the dodgy patents.
> When one of the big guys desires to kill some open source software package off, they just need to litigate.
It's not this simple: if the product exists for some period of time, the patent owner just can't come along "as they choose" and litigate: they will be barred unless they took action earlier.
> Again, you are mistaken. True, at the moment business methods are not patentable. However, as soon as software patents are allowed, business methods will become patentable. Just write down the method and slap "with a computer" or "over the internet" on it, et voila, you have a viable patent.
Wrong. You don't understand how the EPO works: it (a) always requires a technical effect, and (b) a joint USPTO/EPO/JPO meeting in 2002 agreed that business methods _should not be patentable_. This is their desire.
> That is what you claim. Where did you get that number from? Admit it, you just pulled it out of your %$@#*. Let me pull a number out of my %$@#* too: I think it is more like 99%.
Wrong. That is the fact. The FFI says "30,000" software patents, and the GNU list (did you actually check?) shows less than 30 problems. You should do your research. If there are more problems than this, they don't open source producers bring them to light: that would be a better way to justify the situation.
> But, true, the man-in-the-street won't be roused from 300 people walking with supposedly funny slogans.
We agree: I have no problems with the arguments by the open source movement: but I feel they do a bad job in presenting them in a professional and objective manner. Because of this, I think that decision makers start to dismiss their claims without giving them proper consideration.
> So, please, before you say someone is "full of shit", please get your facts straight!
I have my facts straighter than the poster: it's one thing to get it wrong on a few minor points, it's another to misrepresent the entire situation.
> My understanding of what happend is something like:
You are full of shit. I bet you just made that up so you get modded up and present an entirely false argument to readers.
What happened was:
* the concept of excluding "computer programs as such" has been refined over time: software patents are allowed _only_ if they should a concrete "technical effect" (in the US, it is different: they only need to be "useful and produce a tangible result") by case law and appeal board hearings;
* the EPC (european patent convention) is _entirely separate_ from the EU (european union), and thus the case law is developed on a national basis;
* over time, the national courts have adopted subtly different principles;
* this is becoming a problem because it impedes the common market when different national states apply different approaches: since the goal of the EU is to provide market harmonisation;
* to resolve this, the EU directive is proposed that enforces a common approach across the EU (and, upon any members of the EU that are part of the EPC).
Let me re-iterate:
* if this EU directive does not go through, then _software will still be patentable_ -- do not labour under the false impression that this directive is able enabling software patentability: software is _already patentable_, this directive _does not change that_ (in fact, it actually restricts it slightly).
* thus, software will remain patentable, but not in a consistent way: this is even worse because some member states may actually take a very relaxed approach and allow patentablity of software.
Thus, by stopping this directive, the situation gets worse.
The EU has done this before on patentability of biotechnology: it in fact restricted what could be patentable, it expressly prohibited patentably of gene sequences, germ like modification, human cloning, etc.
In the same way, the EU does not want "open the floodgates" to unlimited patentability, it actually wants to restrict it and to control it to ensure proper harmonisation.
I bet the majority of people reading this have no idea about these issues, and simply respond to the spectre of "patentable software".
> If data structures are patentable does this make it possible to prevent interoperability?
No! The courts have continually prevented patent owners from enforcing their rights in circumstances that would restrict competition: and interoperability is one of them.
In the UK, the famous British Leyland case found this. It is codified in UK copyright and designs law.
Firstly, the EU directive just _harmonises existing case law_ - without the directive, what's going to happen is that different EU states are going to take different approaches and thus it will be a nightmare.
Secondly, the EU directive _actually reduces the degree of software patentability_, because currently after IBM, claims to "programs on a carrier" are allowed, but the directive removes the ability to claim this.
Thirdly, it's been stated over and over again that there are "multiple software business models" at work in Europe, and there's no specific reason to favour closed model approaches to open model approaches: they all work, and provide revenue and so on.
Fourthly, in terms of "software patents blocking open source", well there's a very small list at GNU, and in fact this is how it should work: it's to be expected that some patent owners have developed inventive appraoches that they are holding away from open source - fair enough, it's the perojative. It doesn't seem as though Linux, OpenOffice, mysql and numerous other open source products have been affected anything more than trivially.
Fifthly, the EU always maintains more stricter examination than the US: business methods per se are _not_ patentable in the EU, and equally, flakey software patents have a harder time getting through. Stop transposing the failures of US into the EU.
Sixly, for the so called "30,000" illegal software patents issued over the last 30 or so years or whatever, I repeat that the GNU list suggests that less than 0.01% of these are impacting open source. That's amazing! And hardly a justification to pull the system apart.
Finally, the protests in Brussels are are a laugh: against multimillion dollar turnover businesses using patents and contributing to the wellbeing of the EU economy, you have a bunch of jokers with "terrorism is corporate suicide" and other fairly poor and non-objective slogans doing pantomines. Unless the arguments show facts and figures, and more substantive evidence, this is entirely dismissable.
> The graphing in Excel is basically the same as it was 15 years ago, for example. The core userbase is Finance people, and it will never expand to Engineering, Academics, etc.
You made my point better than I could. Anyone who says that "Excel is useful for Engineers" either (a) doesn't know anything about Engineering; (b) doesn't actually do any useful Engineering; (b) is quite a power-user of Excel beyond the average competance that a normal Engineer can dedicate to a single application.
> I disagree, excel is the STANDARD for number cunching and for good reason.
You are obviously not an Engineer. Yes, I see project and senior and product management using it all the time. It is the standard for them. It produces pokey, useless and unsophisticated charts. Exactly not what I need as an Engineer.
By the sounds of it, you are also a power user. Well, thats fine for you, but as an Engineer I'm too busy Engineering and I don't have time to learn all of the inns and outs of Excel. I want the tool to allow me to do relatively user-friendly way from go.
Compare to a DTP like Word: without having a power user ability, it's quite easy to start doing fairly sophisticated content organisation, layout, etc. In comparison, Excel remains a lifeless 2D spreedsheet application.
Microsoft had plenty of opportunity to innovate: Excel is an extremely poor tool for doing anything other than basic graphs and calculations. For engineering purposes, it's near useless.
This is a public policy issue.
The fact is that piracy levels are there. If updates against these critical security issues are not publically available, then the infected pirated machines are a social nuisance. These people are unlikely to buy a legitimate version anyway.
However, it should stop at critical issues: anything related to bug fixes or performance or reliability issues only available to licensed users.
Look at some of the AV companies: they do provide free disinfectant tools for critical issues: you can download and use these even if you are not the AV customer. However, if you want true AV support, then you do need to buy the product for the licensed updates.
It depends upon a number of issues, though you'd expect that coke's manufacturing process would produce cans with good tolerance levels, and the "radio can" could be quite outside of the tolerance. I would expect them to have covered this by ensuring the radio can comes up to the same weight.
Like I said, there are other possible approaches.
coke needs to be smart and ensure that the can weighs _exactly_ the same as an existing can, otherwise, everyone who works at a shop or distribution channel could weigh the boxes or pallets and discern the differences.
Equally, another way to cheat would be to be use sort of low-tech radar/xray device that can detect different types of solids (for example: cans and liquid are pretty simple, but a radio has a lot of complexity that'll generate signal splatter).
Another way [:-)] would be to see if you can generate radio signals at right frequency to induce resonant effects in the antenna within the can.
This type of low-tech gear wouldn't take more than one or two cluey engineers and weeks work of work.
Have fun
A lot of this discussion here is either crap, a rehash or was covered in Engineering 101.
Basically, you have some requirements for the product, and you optimise according to those requirements. Performance is just one variable (time to market, scalability, reliability, security, usability, cost, etc - are the many others).
The requirements for a product in a fast moving market entry company are less about performance and more about rollout ASAP.
The requirements for the same product two years later may be to improve performance to achieve scalability requirements.
If you're writing some sort of overnight build or batch application: whether it takes an extra hour or not may not matter, because it has a 12 hour window to run in.
If you're writing an order processing system, then performance and end-to-end turn around to will be vitaly important, but you won't focus on the assembly, you'll focus on the algorithms, design and architecture.
If you're writing a compression or encryption module: you probably will work on the assembly.
All of the above cases, before you optimise anything: you profile and understand how the optimisation is going to pay back in real terms.
In my experience, you cannot prescribe any of this: you need to take it on case by case basis because every product and circumstance is different.
This is probably about right: just remember that even though Longhorn may arrive in 2005/2006, it is likely to have an expected product lifetime of (say) 5-10 years (think Windows NT/2000/XP). This means that the average is planted somewhere midway into the envelope, say 2-3 years. I'm guessing that by 2008, these technology characteristics are properly not too far off base.
I'm sure someone could sit down and do the numbers for us by extrapolating on CPU and hard drive rates and moore's law as it has occurred over the past couple of years.
I mean, design is all about tradeoffs: we don't design in assembler any more because the playing field has moved on. We don't design UI's from scratch, we use UI 'builders'. In the same manner, we don't design for todays technology when we expect our design to work with tomorrows.
If Linux didn't design for MP and scalability now, then it would be hosed by the time MP became "default" for the desktop (well, in fact, with HT, it already is!). Yet, designing for MP now causes some performance and related loss even though the technology is not here.
Who am I trying to lecture Engineering and Economics 101 to the
Validity is actually pretty easy to attack. The problem is whether a well-funded and resourced opponent wants to try and drag you through litigation.
The large amount of bad patents allowed through by the USPTO may be on the patent register, but they are as good as invalid because they would never hold up reexamination or counterclaim for invalidity. In this case, you simply go ahead and ignore the patent.
> To get a patent, it doesn't have to be better than anything else, or even "inventive", it just has to be different and "useful" (i.e., it kind of works).
You obviously know nothing about patent law. I suggest you have a read of 35 USC 17, especially ss 101 and 203. Don't forget that there's a difference between the poorly functioning USPTO and the more stringent tests applied in infringements.
Your comments re "vendor lockin" are noted: an interesting proposition, but not workable: market forces are better. There's no need to make special consideration for compatibility: that's why people develop competiting technologies (png, jpg) to (if they can) avoid someone elses patent. If they can't, or they don't have the time/resources, they pay royalties. The issue of compatibility only becomes a problem with monopolies, cartels and so on. In some countries, anti-trust/competition laws already ensure that interoperability considerations can supercede IPR protection; which is how (for example) generic printer ink and generic car spare parts manufacturers can survive.
> Christ, they're trying to patent image compression
Maybe they've developed a new inventive approach. If so, fair enough. If not, then the patent will not be enforceable and they've just burned cash on it.
> No we're not. The patents describe the technologies, not how to implement them.
Umm, you do know that it's a necessary condition of patentability that the invention is sufficiently disclosed so that it can be worked by one skilled in the art. If not, then the patent is declared invalid. Again, they will have justed wasted their money.
> If you can't win in the marketplace... ...use the courts.
...) we're actually seeing the internals now.
...).
Umm, but this is winning in the marketplace: you invent the technology first, so you gain temporary market monopoly for disclosing your invention through the patent system.
In other words, rather than _never_ seeing the internals of what makes Windows tick (until someone releases the source code
Rather than relying on trade secret / obfuscation to protect the ideas/concepts, now they're employing patents.
Of course the system is open to abuse (like any system, such as file transfers on the Internet
The standards bodies (W3C, IETF) should continue to act as guardians, and _only_ work on and approve standards that are not encumbered. Of course, just remember that there's no technical dictatorship in the world, so a standards body only has as much market power as its participants: which may not be good enough against a large monopoly like Microsoft: and this is exactly why we have large EU style antitrust rulings that are forcing Microsoft to open up interfaces and so on to competition.
I was looking at DIY something like this (since I am competent in building BSD/Linux systems from scratch):
- 3.5' IDE based HDD
- 3.5' or smaller form factor embedded linux/bsd based pc
- power supply
There seem to be a number of 3.5' ff embedded pc's, something like no less than 100-200mhz seemed ideal: just needs 16-32mb ram, onboard 100mb NIC and a serial port - anything else is a waste of money. Lots of taiwanese manufacturers making these. Some have inbuild 16mb SDRAM and inbuild CF or at least PCMCIA (for a CF adapter) to put the boot image on. The current drain on these systems I've seen a few quoted at ~4W, average seems to be 5-10W. Low power
Would be very interesting to hear anyone else who has done something like this, esp. re prices and suppliers, and appropriate CPU type/speed required to service ATA-100/133 + 100MB NIC, and whether 16mb SDRAM suitable.
Something like this I guessed would set me back no more than ~UK120GBP (incl. ~50-60 for 160gb HDD).
It's not overpriced when you consider the total package: buy it and plug it in. We're not just talking hardware and software costs, we're talking cost of warranty, convenience and everything else. It's not aimed at home/consumer use either.
...).
Certainly I'd like one of these in my house, but cannot justify cost.
In fact, I am in the process of converting an old 150mhz notebook into network storage server. If you're wanting to do something at home inexpensively and gain hacker-enjoyment, this is the solution: not only are old notebooks cheap, but they're low power, have built in uninterruptable power supply, are small and compact, and usually with a pcmcia, you can put not only 100mb wired, but wireless 802.11 as well. The only downside is that 2.5' hdd's (if you have to upgrade) are more expensive than 3.5's: I need to replace the old 4gb with at least 80gb.
Previously I ran a website production system for over 12 months on the same notebook. Great value for money, considering it was surplus to my employer and purchased for near-nothing (no one wants to buy old notebooks
Surely someone's seen the "released" Windows code and can now tell whether it is BSD based or not.
> Did you just make that up? I googled 'inband compression' and 'in band compression' and got less than 10 hits for each.
No, but it's telephony terminology and I conceed probably not used correctly in this case. I simply mean compression employed transparently within the network (i.e. link level) not at the end of the network (i.e. by the protocol stack / application layer).
> that the data must vary in content.
That's a weak requirement for a competition that allows a large scope of deviation.
It means what it says: the data they are sending is compressible (looking at the tcpdump output) as it consists of repeated alphabetical sequences.
If any of the intervening links employs compression, then the transfer rates are artificial as they represent a function of the data, not a function of the network engineering. This doesn't make for a valid comparison against the other participants.
I looked at the rules and they mention nothing about the type of data, nor about the presumptions of the traffic path.
I conceed there is less likelihood of compression in effect on gigabit network due to compute power required, but it is a question that bears asking.
The assumption could be defeated by a test using (a) packets of entirely same character [i.e. highly compressible], or (b) entirely pseudo-random characters [i.e. not at all compressible].
In fact, the rules don't require that the transfer is validated for this problem, nor to average out any other network effects, i.e. the rules should state that (say) "average of 3 back to back transfers each utilising substantially randomised information".