Slashdot Mirror
Why Don't Companies Release Specs?
Mhrmnhrm asks: "With the recent activism by the OpenBSD crew focusing on release of documentation from the likes of Adaptec, Intel, and others, I'm left to wonder: why do companies insist on believing that by denying access to the specs, they somehow gain an advantage? It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?"
Because it would cost them money to (1) write coherent and complete documentation and (2) review that documentation to make it safe and legal for public consumption. Why would they spend all the extra time and money to do that when it doesn't bring them any more profit?
Companies exist to make money, not to be good samaritans.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Hardware Co. Rep.: That's right, Bill--figured it would be hard to go wrong increasing our potential market, at no cost to us. It's not like they can use the interface specs to build a card.
Bill: That's nice. You know, it'd be a real shame if your driver couldn't be WHQL certified, and users had to see a warning box when they ran with your card. Or worse, if there were mysterious blue screens . . .
Harware Co. Rep.: OK, I get your point, Bill. We'll cancel the release of the specs.
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
why do companies insist on believing that by denying access to the specs, they somehow gain an advantage?
The reason is that the ones with pointy hair are running the show and they don't really understand.
sudo eat my shorts
Greed, Uncertainty and Doubt.
Nough said!
... the more common problem is that the hardware people paid to have their drivers and stuff written for them and that a great deal of their product's functionality is, in fact, within the driver rather than within the device or firmware. These drivers are then restricted by the agreement between the driver-writing entity and the hardware maker... or so they claim. ATI apparantly has this difficulty which is why we can't get really good drivers for Linux just yet.
they dont want the world to see how crappy their design is...
Broadcom is also a big fan of not releasing much in the way of specs, even to its customers. My company has used some of their demodulator chips for years and had to beg to get some detailed specs on how to interacts with a chip in ways that it was not explicitly advertised as capable of doing (even though they admitted it was fully capable of what we wanted it to do for us)... later, when that chip became obsolete, they released a drop in replacement for it... a drop in replacement provided you were using the advertised features, things we were using, but plenty more things too suddenly went into limbo. The documentation on the new chip is ~ 1/4th the size of that of the original, so quite often we go back and forth between them, trying things that worked in the old one, hoping they still work in the new one.
Oh yes, demodulators are hella fun!
Help Brendan pay off his student loans
1. sometimes the companies don't even have documentation because they've never bothered to write it themselves
2. the company has gotten itself locked up into some NDA bullshit
3. the hardware sucks so bad they don't want people to have documentation proving how shitty it is (as is the case with Adaptec)
vodka, straight up, thank you!
Because they don't want people to buy their products!
Now try a harder question.
When they do publish datasheets, why do they omit important parameters, and get the dimensions wrong?
Sent from my ASR33 using ASCII
The IP that they are trying to protect is 1) largely in the driver software and 2) any driver that doesn't use the technique is likely to suck. So, either these companies give up trade secret protection (not likely), they provide closed source drivers (nvidia), or the flip OSS the bird.
It's not like this is some great mystery it's just people trying to what they *THINK* is best for themselves.
You might argue that they're wrong about the conclusion but it's no great mystery as to how they arrived at the conclusion.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
It's because of fear of lawsuits, not a desire to hide their chip interfaces. There are just as many bad hardware patents as bad software ones. By controlling spec release with an NDA they stop the law firms from searching for violations of these bogus patents.
The damage from keeping hardware specs out of open source hands is tiny compared to getting a $400M judgement for patent violation.
Trade secret laws prevent law firms from forcing spec releases without pretty good proof of a patent violation.
Yes, only understand, for access into low level specs to write the driver, it requires a lot of work reverse-engineering, which is sometimes very difficult/almost impossible for more complicated cards (eg graphics cards).
I'd tell you, but then I'd have to kill you.
Liberals call everyone Nazis yet they are the closest thing to it.
I have often wondered about this myself, back in the day of the Apple IIs and TRS-80s there were almost always hardware specs available because that was what you used to program your application with. There were no drivers or OS abstraction layers, there wasn't enough memory or speed to do that so your program just talked directly to the hardware.
The first time I realized there was a problem was back in the 90s when my brother was trying to load up Linux on one of his machines and complaining that his video card wasn't supported because the people who made it (Diamond Multimedia?) wouldn't release any specs and people were having to reverse engineer how it worked. That seemed crazy to me. Back then it wasn't just a Windows world either, OS/2 was still around and DOS apps were huge. It boggled my mind that anyone would hold back information like that because releasing programming specs would encourage third party application development that made use of their hardware and ultimately boost their sales!
Sadly these days no one seems to care as long as the vendor has a Microsoft Windows XP(TM) driver available, even if the driver is half-assed and crashes some times.
Does anyone seriously doubt that they DO?
Andy Grove (ex CEO of INTEL) described how MS prevented INTEL from including certain features in H/W. Andy's reaction was life is too short to spend it fighting MS. This was INTEL not some much smaller niche player.
<rant>
With that said, we actually do get decent specs on individual chips or chipsets, they are always in just paper of PDF form. Even the most complex devices (UARTs, ethernet controllers, etc.) simply come with a Rosetta stone of diagrams. Then we start the regular cycle: I take the diagrams, decode them, build up a low layer of software to talk to the thing, add more stuff to exercise the features we want, test it, and finally integrate it into a WinCE/Linux/Tornado/whatever driver that does what we're using. All this despite the fact that they ship development kits with binaries (usually Windows or DOS programs) that already talk to the stupid things.
On several occasions I have told the sales guys at hardware vendors that providing source code to some chunk of software that simply does some basic communication with the part would give it big brownie points in the selection process - save us a month of programmer time and you bet we'll think hard about your chip. When I ask if they could part with some of the stuff to help us skip steps 1-3 above, they always give a uniform NO. It doesn't matter what NDA we've signed or a if we are willing to take the code stripped of features and with no warranty. Sometimes I'll get sympathy from application engineers instead of sales droids, but whenever they try to get approval up the food chain they get shut down.
I understand that source code is an incredibly valuable asset (heck, I write the stuff), but why don't hardware/chip vendors realize that handing out or (or selling it cheap) helps sell chips? After all, the stuff's worthless unless you actually get your hardware out there to be used!
</rant>
Whew! That feels better. Anyone from the hardware manufacturing end want to chime in?
"Prepare for the worst - hope for the best."
You're telling me that they don't have internal documentation anyway?
Internal documentation is written for people who already have secret clearance within the company, not for publication. It would take a lot of effort by highly paid lawyers and technical writers to clean up a secret document for public consumption.
With wider compatability, they allow their marketability to improve.
More than likely, the lost profits from not reaching the <10 percent of the market willing to pay only for devices with public documentation are less than the lost profits from incurring the expense of cleaning up internal documents.
I have experience with a few different companies that make chips for PCs. I've found that the most common reason for keeping specs proprietary is patent liability. Areas like computer graphics are minefields with thousands and thousands of patents held by unfriendly entities. If you publicly release a detailed spec for your graphics chip you are inviting these unfriendly patent holders to look for potential litigation.
It's not like nVidia and ATI are looking for reasons to sue each other, it's more about some no-name holding company looking to litigate something like Cadtrak's XOR Cursor patent.
This might also be a competitive thing for Microsoft since they own a big pile of 3D graphics patents from SGI. Microsoft might take legal action against a chip supplier that publishes a spec for a 3D graphics chip that violates one of the old SGI patents.
In my experience most tech companies are now pretty hip about linux and free software, but the potential downside holds them back from releasing specs to the community.
jeff
The ISA (Instruction Set Architecture) is the specification that is needed before writing an OS, compiler or any other low-level software for a given CPU. It's no secret, especially for a very widely used architecture like x86.
In fact, there's this.
I'm not writing documentation, but seldom help with some technical details and help with translations.
Guys, just to understand the problem you have try first write something. Writing good documentation would require someone who can think straight and clearly. And as you can imaging if company got such guy/girl - s/he will be busy doing product itself, rather than documentation. That's first.
Second. On PC market change of technologies occurs every half of year or something like that. Writing documentation, getting thru all bureaucracy for confidential document to be released will be precisely about this half of year. In other words, when documentation is ready - it is already outdated. You can btw notice that industries with longer release cycles normally end-up with decent documentation - they have time and money. Having no money you cannot afford longer release cycle. Telcos are good example of that. Industrial automation is another one.
So PC industry is sort of its own worst enemy. Tight competition force producers to save where possible - e.g. optional component such as documentation. If you have some bright heads, producer can manage to update product line more often - edging against competitors - but again bright heads will be busy with product release, rather than its documentation.
Having dedicated personnel to handle documentation is just expensive.
P.S. One more problem is when product is partially based on some licensed third party development. Most small producers have to license things, since they cannot develop everything in house. Than it happens that documentation ends up with hell a lot of copy'n'pasting from third party one. To release that you have to get a permission from third party: but in most situations you will find out that third party has licensed some parts itself. In the end no-one just want to risk releasing the documentation, especially in litigious U.S.: most companies when finding their parts in someone's else released products may start asking for fees. With all consequences. Hiring experienced attorney for going thru all this licensing mess - and getting clearance from all involved parties - will cost a lot money, most producers just not able to afford.
All hope abandon ye who enter here.
It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?
Granted things like video cards and ethernet cards and stuff are significantly more complicated than say, guitar stombox effects and amplifiers, but electronics are electronics. It is not entirely impossible to look at the part itself and map out all the traces on the board (gets harder on multilayer boards, but it's still not impossible). Parts are parts, in the case of resistors, capacitors, diodes and stuff, and they're all marked and/or measurable. Lots of circuits have common subcomponents that are 'universal'- no different than linked lists or binary trees are to programming. Maybe you'll see a proprietary IC, but its manufacturer might have the specs available- I haven't seen an IC data sheet yet that doesn't have an internal schematic of the IC. You might be able to buy them from that manufacturer directly, or build the equivalent from other ICs and parts.
Far as I can tell though, most ICs are pretty standard and available.
So then... releasing their specs or not, it makes no difference on whether or not someone could figure out how their card works and/or clone it.
Yes I realize this takes a lot of work and man-hours to do, but surely this happens in industry of all sorts all the time.
do() || do_not();
Not to say there aren't other reasons already mentioned here, but the most common situation I've seen (and I got quite a few specs released out of DEC in the early '90's), is that the specifications often have a mixture of information considered proprietary (e.g. detailed logic design) and the programming information.
Seldom were there a nice set of documents, partitioned between programming and logic design.
So you have to track down the right documents, edit out the stuff that hardware folks are worried about, and get the right sign-offs. And you therefore have to deal with whatever random document preparation system was used by the engineers to do the documents.
This all turns out to be a fair amount of time, trouble and hassle.
So even if there aren't other paranoid concerns, it is harder than one might naively think.
...there are no specs.
Often products are created & sold based on some back-of-a-napkin drawing that a manager handed to development. I've been fortunate in my career -- I've been lucky to get them on notebook paper. It's much nicer than trying to figure out what was drawn through the martini condensation stains...
Chip H.
That means companies like Broadcom (they tend to not have any drivers for linux) won't get chosen by anyone wanting to run Linux, and thus will lose money as people will chose non-Broadcom hardware.
I'm not sure about all hardware, but I'm sure part of the reason Broadcom doesn't openly document their WiFi hardware is because they use software radios, where all of the channel number to frequency conversion is done in the driver and not in the hardware.
This would mean that someone writing an open source driver would have to properly tell the hardware what frequencies to use--something that shouldn't be a problem.
However, it also means that you could easily tell the radio to broadcast in frequencies (and possibly powers) that aren't within the spectrum their FCC license covers. IE, people could do things they aren't supposed to and maybe Broadcomm is worried about law suits.
--
Don't fight Firefox! Let FireFox fight YOU!
What. The. Fuck?
We recently went over this in my computer organization class.
You need to leave whatever school you're going to.
Immediately.
Seriously. It's obviously a complete waste of money. Do it now before your head gets any more messed up.
Intel is reluctant to release their ISA documentation
Nooooo they aren't.
Without releasing ISA documentation, people can't program your fucking CPU. Yeah, I'm sure that's exactly what Intel wants -- nobody to code for it. Great business plan. Where do I sign up?
Interesting? Jesus christ on a cracker, the mods are fucked up today.
They don't release the specs because the hardware is generally full of bugs that they work around in their drivers. Different versions of the hardware have their own bugs and work arounds. Sometimes I think they're too embarassed to release the specs for fear the would would see what a dogs breakfast some of their work amounts to.
Further most of them have "specs" which barely qualify for the name -- often driver writers will go read the RTL, or talk directly to the hardware guys to figure out how something works -- often much of it is not written down, and usually not in one coherent document that could be called a spec.
I know this for a fact about several producers of hardware that serves various purposes -- who, for obvious reasons, I shall not name.
Others are anal about getting things right and writing great specs -- even if they never publish them -- But I think they're in the minority.
Ian Ameline
I was about to mod you insightful, but then I realized what the grandparent was probably talking about... the microcode. The microcode is a lot more important for recreating details. Pentium processors have a limited ability to fix silicon bugs in software. The microcode is in volatile memory, so it must be loaded on every boot by either the OS or the BIOS. It's top-secret, but access to this lower-level info might let you write a custom instruction (or not, I don't know how much the mechanism can change the operation)
An example microcode fix is for "High Temperature and Low Supply Voltage Operation May Result in Incorrect Processor Operation"
HIV Crosses Species Barrier... into Muppets
> ... the more common problem is that the hardware people paid to have their
> drivers and stuff written for them and that a great deal of their product's
> functionality is, in fact, within the driver rather than within the device or
> firmware. These drivers are then restricted by the agreement between the
> driver-writing entity and the hardware maker... or so they claim. ATI
> apparantly has this difficulty which is why we can't get really good drivers
> for Linux just yet.
As a former ATI employee (working on HydraVision some 3-4 years ago)
I can tell you that ATI's drivers are written in-house.
Nope.
Intel has never published details on microcode except how to load it.
The grandparent explicitly stated ISA , and the fact that AMD and everyone else copied it.
There's no microcode system for any AMD or Cyrix or any other x86 clone for that matter, but that hasn't stopped anyone from doing what the grandparent was posting about - copying the ISA. Microcode is completely irrelevant to the discussion.
I just spent the entire afternoon looking for a webcam that we could use with linux for a project.
I tested just about every model avaliable... and none met the requirements, wich are work with linux and be recognized by Java Media Framework.
I know that there is a standart for USB MassStorage devices, so is just a matter of implementing ONE driver that will be compatible with every hardware that implements this standart.
Standarts make easy for developers to create drivers, and for vendors to make compatible devices. There are lot's of success cases out there, so why keep on creating non-standatized devices!?!?!
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
-- Terry
My IBM PC came with a technical reference manual that included a complete set of schematics and a listing of the BIOS. The only thing that it didn't include was a listing for the ROM BASIC.
Mea navis aericumbens anguillis abundat
Your basic problem is that you aren't thinking like a hardware person. Hardware people just fundamentally don't get how software people think there is an important distinction to be drawn between the software and the hardware that runs it--and, to be fair to them, they have a point.
An awful lot of what hardware vendors are selling these days is a hardware platform for their expensive proprietary software. Take wireless network interface cards, for example. When you buy a Wi-Fi AP from some company, e.g. Apple, the price you pay includes the cut they have to pay to the vendor of the wireless interface card they use in their products. What they probably get from the hardware vendor is more than just a steady supply of hardware to its factory line-- it's the chips, plus a code drop for the driver, a maintenance agreement, and a bunch of other goodies that are all rolled up in the contract at once. The price the hardware vendor charges is divided between a per-unit total, a per-calendar-interval total and sometimes an upfront charge. The accountants have a field day.
Remembering who is paying for what helps here. You are never going to get specifications for the hardware you buy at retail, because the people who make it are never in control of the whole package from sand to plastic wrap-- they have to buy and integrate pieces from other companies, who are providing more than just chips and a few pages of programming guide. As I said, those guys are providing a hardware platform for their proprietary software and they won't let the vendors of retail systems redistribute their crown jewels. It's really that simple.
jhw
Let's send some email to Linux magazines like Linux Journal and others, asking them to interview a few companies like nVidia, ATI, Broadcom and others about this question. Maybe if they think there's enough publicity pressure, they'd give useful answers. Then instead of wondering, we'd *know*.
Whoooooooosh.
So by all indications it's safer to sit on the documentation rather than do something and get busted, one way or another. Rules of the business world are quite different from the rules of F/OSS world.
In essence, it's the "patent" argument. All information may be "free", but the first person who spends money creating it is the loser, as the other parsites sponge off their work and don't need to recoup those dollars.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
There are a few reasons I have seen based on RE drivers. I'll name a few here in no particular order.
Embarrassment. Sometimes they don't want to tell you that it's necessary to reset the chip repeatedly until it just happens to initialize correctly (probably due to a design flaw).
More embarrassment. They don't want to admit that many of the so-called 'hardware features' are really implemented (poorly) in the driver. Many IDE "RAID cards" are just a bunch of IDE co ntrollers. The RAID is in the driver. The driver's RAID implementation is not generally anywhere near as good as the Linux soft raid device.
Closely related to the above, for (snake oil) security devices, they don't want to document that flipping bit 5 of the 3rd register will bypass all protection.
The IP isn't theirs. The product is just relabled.
Their default answer to anything is NO, and they haven't (and probably won't) give it any thought.
In the case of some graphics cards, they don't want the public to find out the driver has hacks in it to cheat the benchmarks.
If you don't use your own chips, you don't write drivers for them, either.
Contrary to the popular belief, there indeed is no God.
They already provide hamburgers to an open standard. Their product interfaces in the same way as all other hamburgers, directly with the mouth port.
Very fancy restaurants have proprietary interfaces: You are required to use specialized hooks (salad fork, etc.) to interface with the food which must be used in a specific way.
Chinese restaurants use the most difficult interface of all, but it's fairly simple and often fully documented on the chopsticks package.
Can you be Even More Awesome?!
Mission
Availability of a graphics card with fully published specs and open source drivers.
Note that the mission is not to actually design or make it. And:
In order to get manufacturers to make such hardware, we have to show that it will be economically viable to do so.
No mention of making it themselves. The rest of the page makes it appear that their main work is coming up with a feature list.
If you dig through the rest of the site, it appears some guy wrote some sort of emulator and they intend to convince someone else to translate it to FPGA code and put it on an FPGA, but the FPGA code probably won't be available. That's not an open source graphics card.
I believe this project is an offshoot of what was originally this guy's ideas. In fact I am pretty sure of it because the name of the guy on OpenGraphics is also Timothy Miller. I wrote those guys when that original article first hit slashdot that I was willing to pre-commit to paying $200 each for up to 5 cards, and I stand by that. But I won't pay for someone's simulation code, or for an FPGA sold by the same bullshit company as before and with a closed FPGA.
I wish someone would try to do an Open Source graphics card, I'd like to buy it. I think it it likely that people would find other uses for it -- reprogramming it to be a software radio, for example. Perhaps after the Open Graphics Card project screws around with the big companies enough, someone else will take their simulation and design and make an open graphics card.
But in the end, the Open Graphics Card project is simply producing a very detailed spec and begging one of the usual asshole companies to make a closed source version to match it. This is doomed to failure. They won't do it, and if they do there will be small undocumented differences from the spec and you won't be able to correct the spec easily or change the FPGA.
This is not a situation that can be solved by lobbying companies. I believe it can be solved by making hardware, even if you have to make your own company in the process.
That argument is absurd. If the hardware is capable of significant output on unpermitted frequencies, what's to stop a corrupted driver download, or bug in the official firmware, from doing that? Wireless cards are complex systems that are certainly prone to bugs.
What if a disgruntled employee leaks the docs? Will the company have its FCC certification immediately revoked? If so, why would management build hardware that exposes them to that risk?
What if someone reverse engineers their hardware and writes a fast-propagating worm that programs it to jam law enforcement frequencies? Or microwave users' balls?
If the FCC was truly anal about theoretical interference, it would not certify software transmitters at all.
Several chips from the previous 802.11b generation are heavily documented. Some of them allow sw to increase power output to >=250mW, which combined with a large directional antenna will exceed FCC allowable output. Wait... why aren't these companies being raided by the FCC and DHS?
Frankly "Blame the FCC, we're their bitch" is just a vendor cop out created by competetive paranoia, lawyer power trips, and corporate inflexibility.
They're trying to get the BSD nerds to f*ck off while they sell to the trillions of Windows users that don't mind a silicon-induced lock up twice a week.
Hey, I'm not bitter.. I'm right.
Go to ViaArena. Click on "Open Source", and go from there. Source for drivers for their Ethernet and graphics chips is provided.
When the number of device driver writers for your part numbers in single digits, you don't need super great docs. When you try to write good docs, the next thing people will complain about is the quality of the docs!
"This mission is too important to allow you to jeopardize it." -- HAL
It's very simple: back in the old days, when there was no monopoly, many chip manufacturers gave away thick, printed databooks. It was expensive for them, but they needed developers to use their products.
Now, however, there is a monopoly. You don't need to attract developers. The only concern is to have a driver for Windows, and having that driver included with the Windows install disk, so that your device, be it a soundcard, graphics card, or whatever, is "easier" to use. I wonder if there is a "dark hand" behind it...
Some years ago I sent a proposal to the European Comission: banning the sale in Europe of peripherals for which there is no public interface information available. It should not hurt the manufacturers, as the information can be made freely available in Internet (it's cheaper than shipping huge printed manuals), but it would have a side effect: the driver advantage for Window could disappear.
I never understood that argument. I agree that from a pure quantitative perspective it is easier to make the hardware operate out of the authorized specs if you do have the driver source code. However, any more-than-average hacker can decompile a binary driver and replace the adequate values directly in the code. Hacking the source requires very similar programming skills.
Is there some jurisprudence somewhere which states that if you provide source instead of binary to someone, you are breaking the law if that person can later on change the source code to break some regulations ? That would be damn precise and subtile from our beloved law people.
--
Go Debian!
Would it be possible to develop a standard conversion tool that translates or at least helps to translate Windows driver source code to Linux driver source code, which would then be releases as binary only? So that HW manufacture could produce a binary Linux driver easily without too much expensive Linux experience work and without revealing their (perhaps legally hazardous) specs to outside community?
Note that IF a company wants to release HW specs it is mainly because they want to have Linux drivers available and a Linux market. It is not that releasing specs would be ever ba an end itself, but rather an unpleasant means.
Generally, wouldn't it be a time for Mr. Torvalds to start thinking about making life easier for proprietary driver development (like freezing the driver binary interface between minor kernel releases).
On the other hand, why is open source hardware development not catching on? Is it again this patent isssue? If the OSS community would provide nice open blueprints for hardware, I don't see why the chinese wouldn't be more than happy to print millions of chips for the consumer market, with manufacturing costs only, no development costs at all.
Anssi Porttikivi / app@iki.fi