Its a tough call. Sony got hammered on price premium when they entered the market, as they discovered that the sole metric for "better" on a commodity x86 box was CPU speed/version. They shipped with Pentium, the rest of the world did Pentium MMX, sony lost out.
what apple bring to the table is not just industrial design of the box, but the OS. The first Unix desktop with consistent consumer grade usability. A unix desktop optimised for laptops and the hardware it runs on.
Too bad that MS will be pushing longhorn with all their marketing $$$, and working with HP/Dell to bring competitive home boxes out, while apples reserves will suffer from the fact that nobody sensible will by a (doomed) PPC part from now on.
I used to work with laptop developers, so know their problems.
Laptops are not any less endurable than desktops, it is just they get thrown around a lot more. A workstation SCSI disk is very fragile, but you dont throw it the backs of cars, kick it under the seat of the airplane in front etc, etc. Furthermore, vendors dont like unrelaible laptops; the annualized failure rate (AFR) makes the difference between profit and loss on warrantied systems.
What has happened is that the trend towards consumer-centric laptops has eliminated much of the exchangable-IDE drive design of the past. These all-in-ones are robust as they are mechanically simpler. The other big trend is that with two main ODMs in taiwan doing much of the work, a greater level of expertise has built up into doing quality designs.
Now, for an annedote of amusement:
When the first thin-and-flat laptops came out, the AFR went up. This was tracked down to people dropping their laptops while trying to lift them out of bags/briefcases one handed, and losing their grip. The older laptops were so fat and heavy they could be lifted two handed, but the new ones were thin and light enough to be one handed -only nobody had thought of this when it was designed
If you look at today's laptops, they normally have grippy texture on the top and bottom, or some features on the batteries to provide a better handgrip. This is to eliminate the problem.
That's an amusing story but it shows the problem: a robust laptop is not an intel chipset in a box. It is a system designed with ergonomics in mind too.
they meant bios passwords. Implict was the idea that people stealing the laptops are drug addicts wanting to get enough for the nights fix. Anything that reduces the value of the laptop helps.
The laptop integrates with secured HDD drives; these need a supplied password to start working properly; you set it up so the BIOS password powers both. If the password is stored on the disk, it should be pretty persistent, leaving only brute force attacks.
I dont work with them; I work in the same corporate R&D lab. big difference. I dont believe in TCB, I dont believe in DRM. I dont think anyone here believes that real DRM is workable.
But you are right, TCB could be used for ubiquitous DRM, and that would be wrong. I guess now I am lucky in that the OS (winXP) doesnt know about the TCB; its some helper device driver that just stores my keys. Longhorn would be a different matter.
My laptop got stolen from my own house last year; in hibernate state.
Revoking SSH keys took as much time as killing card info, There is so many places sensititive data could end up (like your bank login/card info), such as
-hibernate file
-pagefile
-browser password store
-browser page cache
-directory where I save PDF shopping receipts
-mailbox
Now I lock a lot of the system down. Not just my home dir
-temp
-browser cache
-various program directories. This is win32, where the EFS stuff doesnt encrypt filenames, just the contents. Its known that EFS is breakable (just reset the login password or something), but to make it harder
1. laptop needs a bios password. 2. that password is also used to enable the HDD 3. My winnt EFS private key is stored in the laptop TPM module.
#3 is interesting. I know TPM is associated with 'evil-DRM-Trusted-computing-stuff', but I use it as an unbreakable store of my sensitive keys. If what the inventors say is true (I work with some of them), you'd have to be a stronly motivate government to stand a chance of getting stuff off the TPM, so implicitly, off this hard disk.
Does this make me a criminal? I dont think so. The police told me off for not bios-locking my last box. Their view is the less usable stolen laptops are, the less valuable they are, so theft reduces all round. It is every laptop owner's duty to lock down their boxes so nobody can get at them!
MS is primarily a US company; the EU regions are sales, propaganda and a small research lab in Cambridge. (That's Cambridge #1, in the fens, not cambridge #2 in MA).
Cutting back on sales would hurt them long term.
A more likely way to fight back would be to get the US government on their side, how a US company was being picked upon because it was succeeding, the EU is doing anti-US actions at the French behest, etc, etc.
The end result is we'll probably end up with another unsatisfactory compromise. Indeed, the whole EU proposal (a version of XP without media player, for the same price) is a bit bogus. If the EU said "$5 less for no WMA, another $5 for no IE", you'd see PCs with mozilla and winamp (or worse, AOL edition netscape + real audio) within two months. One week for the PC vendor to make the image, one night to FTP it the ODM in Taiwan, 5 weeks to get the boxes in the shops.
Lots of minor projects get reincorporated into distro, without any clue what changes were made, and yet are still expected to field bugreps against them.
At the same time, distros need to identify projects that are significant, and get involved in the dev list/planning, if only to get some kind of presence in the project.
For example, the Apache Ant project took input from the eclipse and netbeans teams over their release schedules, and once we'd determined that Ant1.7 wouldnt cut it, did a 1.6.4 release for them: http://wiki.apache.org/ant/Ant17/Planning
One concern I have about this downstream involvement is that it creates extra schedule pressure. A project that releases when it wants can be more relaxed about schedules and release when happy. When vendor driven, you are more prone to release to meet some random milestone, rather than when the quality is best. That means shorter beta tests, possibly lower standards all round. Which can't be good.
Well, there is nothing wrong with having a select email list giving heads up warnings to key distributors. One per vendor, no favouritism among community (Debian) and commercial products, and relying on trust amongst participants.
I think products like Apache HTTPD work like this. Once you have a significant amount of market share, and a significant amount of redistribution, you need to take security more seriously.
Maybe this will mark a maturing of Mozilla. Till now firefox has relied on being "more secure than IE", which isnt really that hard to achieve. Now it has market share, it is vulnerable to zero day exploits -maybe more so, with all the source public. And that means the team needs to come up with a process that the redistributors and end users are happy with.
Hey, maybe the zero day exploits are our next metric of mozilla's popularity:)
The 'system restore' feature of windows was detecting that MS Messenger was missing, and 'fixing it'. As only an incompetent fool would want to delete msn messenger.
I think if you turned off system restore you could delete that and the pinball game.
Just be glad you werent auto-reported to the department of homeland security for being subversive.
Once you try and come up with an aircon design for 500 rack mounted boxes, power management matters there too.
I've found that the pentium-m laptop is better at work things (compiling, running java code) than the P4-Xeon-desktop. Its the best CPU design from intel for years.
I'm not going to argue the points, just observe that one possible cause for my frustration in the US is the way that coverage was sold off on such a fragmented basis. So many companies bidded up the NY coverage, whoever wanted oregon-south-east-sticks got got it 15c. Once you had the radio waves, it was free to do with what you wanted.
The EU process was -per country -GSM *mandated* on the relevant frequencies. -same(ish) frequencies everywhere
So in a single country, you pick a provider and be relatively sure that it will work everywhere, bar the ones that are well known for bad coverage.
In the US, you dont even get per-state coverage. So when I am stuck in a ski resort like Bachelor, OR, I'd see signs "Cellular one is our provider, get cellular one today", as if I'd run out and buy a new phone, just to make calls from that place, even if it didnt work there.
Conclusion: The granularity of contract was too small.
Now in the EU, doing it per-country is arguably too small too. Its why you get hit hard when you go abroad. Maybe next time, they will do a "per EU" contract, though the countries like the licensing fees, and may not be willing to play that way.
Yes, both are flawed. But when I lived in Oregon I found what was on offer truly sucked. There are still some parts of the state (much of the coast; nealry everywhere south of eugene bar I5), where analog is all you get, and you are meant to be grateful.
Note that the use of SMS is not just to save money on calls (my virgin prepay is 5p/minute after the first few minutes of a day; no monthly fee). Its more a social thing. you text people a bit when its less important than voice, more than email. I'm told that in Japan it is common for a round of texting is the precursor to a call "can I call you now?", with all the incurred extra revenue for the telcos that implies.
A big rip-off in europe is when you roam, the caller makes an apparent long haul connection to the home country, the recipient ends up fielding the receipt costs. Which is why when you travel for any length of time, you just buy a new prepay SIM for that country, text the # to your contacts, and away you go.
-steve
(ps, you can have countries that are not states. Scotland, for example)
Despite the article authors critique of DSL, he could at least get a pay-as-you-go mobile for a reasonable fee, one that works everywhere.
Whereas US mobile phones, what an epic.
1. you need to work out which providers have approximate coverage in the places you live, work and travel.
2. you then need to decide between prepay or x-minute contracts.
3. prepay is very expensive, minutes expire unless you phone is topped up, not available everywhere.
4. x-minute contracts are rounded up minutes. Its not "50 minutes of calls a month", its "50 calls a month, of 1 minute or less each". And the minutes expire.
5. you pay to receive calls, on your mobile. So family minutes are cut in half if they are used intra-family.
6. you pay to receive text messages!
7. there is no such thing as text message interop! You cant text other networks. So you need to know the network of your friends.
8. Different network providers have different handsets. You cant juggle SIM cards around or choose the phone you want.
9. When you buy a phone, you pay an "activation fee" for some idiot in the shop to turn it on and press a few buttons.
10. phones are bound to a particular area code. If you move, you either need a new number, or people pay long distance rates to get to your phone.
Clearly the incompetence and pricing of EU land lines helped encourage good mobile phone networks. But also those crushing government standards bodies that mandated GSM everywhere, SIM cards everywhere ended up creating an ecosystem of phones, SIM cards and low friction switching between providers. It also created a new crime: phone theft, but that's another story.
I'm glad you dont have javadocs. Its a cheap way to make a bad book.
more to the point, it dates so fast in the OSS world. Oreilly could get away with the original Java in a Nutshell book because the entire Java API was small enough to print, and because the API stayed frozen for two years.
but any living OSS project has an API that evolves weekly; and point releases every few months. printed documentation just doesnt cut it here. Instead books have to focus on why and how to use library, not what the APIs are.
I know that is actually harder, but the reader benefits, and so ultimately, the author and publisher.
-steve
(currently writing the second edition of Java Development with Ant)
1. The Apache Portable Runtime will probably be the basis for a lot of the portabliity stuff.
2. OSS things -like eclipse's SWT windowing toolkit wont need rewriting -they become the test suite as well as part of the distributable.
3. Things like garbage collection and VM performance could be an area for research. Hopefully it will be a good platform for academic research, stuff we can use.
4. Testing is the big problem. There are not yet enough public tests to verify JVM 'compliance'. I dont know if apache can get hold of the Java1.5 Test Kit. Sun have given teams access to other TCKs (Axis and Geronimo, for example), so it may be possible. If we can do that, we may have a chance.
Wine has a harder problem, in that the Win32 is only implicitly specified by the behaviour of the system. Java is a lot cleaner, and was designed for portability from day one. But some bits of the JDK are probably badly specified; that will surface eventually.
steve loughran. (apache member, but not (yet) involved in harmony)
My isp blocks outbound port 135 connections as worm symptoms. It effectively locks up internet access for anyone using outlook. But for security reasons, that is probably a good thing.
Actually, reliablity may not be too bad, and bandwidth would be excellent. Plus the RIAA wouldnt be able to know what was going on, 'cept by using drive-round-vans like the TV license detectors they have here in the UK.
The trick is to get away from the star model of access point and client and go to full fledged mesh networks, with the appopriate discovery and routing.
This is still a research area, but it is interesting. the best bit: many of the algorithms for routing and discovery are the same as those for P2P networks.
I've only ever worked on CMOS cameras, so things may be different there. its a very different process.
In CMOS, each pixel is monochrome; a filter array is placed over the top to give it colour. Something like RGRGRG on one row, then BRBRBR on the one underneath.
For those people writing the code to handle this straight off the camera, you get frame size metadata, marker info of new frames, then the data itself.
Processing it into quality colour images is a choice of using the best algorithm you have *in the time available*. If you are doing a viewfinder or video capture you also want to subsample -do this before applying the color matrix equations (that is what they are) saves a lot of CPU load.
I can well believe that full raw data and third party algorithms can radically improve quality of images. But that has a consequence: it makes the unimproved images look worse. Maybe that is Nikon's concern -adobe will make the nikon software look bad.
I've used VMWare to test windows drivers on linux boxes; its great for testing device independent bits (like filesystems). Buti it has limits
-threading/race conditions dont surface (nonexistent/different thread model)
-limited set of devices
-no power events
They are still fantastic; you can treat a bluescreen or a toasted filesystem as an app crash, not a major distaster. But eventually you need to move to real hardware.
It's a lot better than Autoroute on the laptop was, that one suggested to me that I turn left off the clifton suspension bridge to get to the road 70m below.
It also knows a lot about blocked off roads, enough to suggest an almost viable route between two roads. I say almost, as it did add one illegal U-turn:-
If I look five years ahead, I worry about how to design networks and protocols that are defensible against MPAA, RIAA and generic lawsuits.
A lot of the adhoc stuff in the PDF look a bit like this something that must terrify the {MPA.RIA}A lawyers who would like to make DRM a requirement of all future network topologies and protocols.
TCP was an implicit political statement. It said "we don't need telcos to make us pay for every second of a virtual ciruit", the way the OSI architecture was designed.
Future networks need to think about what threats there are to their functional operation, its not just scalability, or adhoc-ness, its defending against politicians and lawyers who dont understand.
Do you think when skynet becomes self aware, it wouldnt acquire admin rights on./ and lock out all postings about "killer terminator robots seen motorbiking round LA" or "help, the military grid is now sentient".
Instead, assuming that the/. audience are the people who stand a chance of stopping it, it would probably distract them all with different postings, like "free video p0rn service", or introduce a special distro of linux which looked like a descendant of debian but turned out to be a node in the syket grid-brain.
Maybe it really varies by subject; Biology is a wierd one because there is so much money there.
CS, by its very nature, is so computer centric, and often there are the accompanying code, screenshots, demo programs and videos: the web is the natural way to distribute this stuff.
Even in CS, the ACM is not free to read, it is relatively low cost compared to the 'retail' publishers, who are still up to their old practises.
I am fortunate I recently had a paper turned down by one of the latter, because their journal rules explicitly stated "not to be published online". I have got it into an IEEE conference instead, and we will be hosting it for everyone to see.
And that, when you think about it, is what matters. The more people read your work, the more they may learn from it (or, for people playing academic politics, the more they may cite it).
Slashdot Mirror
Its a tough call. Sony got hammered on price premium when they entered the market, as they discovered that the sole metric for "better" on a commodity x86 box was CPU speed/version. They shipped with Pentium, the rest of the world did Pentium MMX, sony lost out.
what apple bring to the table is not just industrial design of the box, but the OS. The first Unix desktop with consistent consumer grade usability. A unix desktop optimised for laptops and the hardware it runs on.
Too bad that MS will be pushing longhorn with all their marketing $$$, and working with HP/Dell to bring competitive home boxes out, while apples reserves will suffer from the fact that nobody sensible will by a (doomed) PPC part from now on.
yes, the PC wars just got interesting again
I used to work with laptop developers, so know their problems.
Laptops are not any less endurable than desktops, it is just they get thrown around a lot more. A workstation SCSI disk is very fragile, but you dont throw it the backs of cars, kick it under the seat of the airplane in front etc, etc. Furthermore, vendors dont like unrelaible laptops; the annualized failure rate (AFR) makes the difference between profit and loss on warrantied systems.
What has happened is that the trend towards consumer-centric laptops has eliminated much of the exchangable-IDE drive design of the past. These all-in-ones are robust as they are mechanically simpler. The other big trend is that with two main ODMs in taiwan doing much of the work, a greater level of expertise has built up into doing quality designs.
Now, for an annedote of amusement:
When the first thin-and-flat laptops came out, the AFR went up. This was tracked down to people dropping their laptops while trying to lift them out of bags/briefcases one handed, and losing their grip. The older laptops were so fat and heavy they could be lifted two handed, but the new ones were thin and light enough to be one handed -only nobody had thought of this when it was designed
If you look at today's laptops, they normally have grippy texture on the top and bottom, or some features on the batteries to provide a better handgrip. This is to eliminate the problem.
That's an amusing story but it shows the problem: a robust laptop is not an intel chipset in a box. It is a system designed with ergonomics in mind too.
I thought it was "hello, here is a new release of fedora for you to install..."
The apache projects, home to plenty much java stuff, are mentors, and there is room to add more.
I think they were just in a rush to get stuff out, and didnt have time to approach that many orgs (and/or wanted to limit leaks)
they meant bios passwords. Implict was the idea that people stealing the laptops are drug addicts wanting to get enough for the nights fix. Anything that reduces the value of the laptop helps.
The laptop integrates with secured HDD drives; these need a supplied password to start working properly; you set it up so the BIOS password powers both. If the password is stored on the disk, it should be pretty persistent, leaving only brute force attacks.
I dont work with them; I work in the same corporate R&D lab. big difference. I dont believe in TCB, I dont believe in DRM. I dont think anyone here believes that real DRM is workable.
But you are right, TCB could be used for ubiquitous DRM, and that would be wrong. I guess now I am lucky in that the OS (winXP) doesnt know about the TCB; its some helper device driver that just stores my keys. Longhorn would be a different matter.
My laptop got stolen from my own house last year; in hibernate state.
Revoking SSH keys took as much time as killing card info, There is so many places sensititive data could end up (like your bank login/card info), such as
-hibernate file
-pagefile
-browser password store
-browser page cache
-directory where I save PDF shopping receipts
-mailbox
Now I lock a lot of the system down. Not just my home dir
-temp
-browser cache
-various program directories.
This is win32, where the EFS stuff doesnt encrypt filenames, just the contents. Its known that EFS is breakable (just reset the login password or something), but to make it harder
1. laptop needs a bios password.
2. that password is also used to enable the HDD
3. My winnt EFS private key is stored in the laptop TPM module.
#3 is interesting. I know TPM is associated with 'evil-DRM-Trusted-computing-stuff', but I use it as an unbreakable store of my sensitive keys. If what the inventors say is true (I work with some of them), you'd have to be a stronly motivate government to stand a chance of getting stuff off the TPM, so implicitly, off this hard disk.
Does this make me a criminal? I dont think so. The police told me off for not bios-locking my last box. Their view is the less usable stolen laptops are, the less valuable they are, so theft reduces all round. It is every laptop owner's duty to lock down their boxes so nobody can get at them!
MS is primarily a US company; the EU regions are sales, propaganda and a small research lab in Cambridge. (That's Cambridge #1, in the fens, not cambridge #2 in MA).
Cutting back on sales would hurt them long term.
A more likely way to fight back would be to get the US government on their side, how a US company was being picked upon because it was succeeding, the EU is doing anti-US actions at the French behest, etc, etc.
The end result is we'll probably end up with another unsatisfactory compromise. Indeed, the whole EU proposal (a version of XP without media player, for the same price) is a bit bogus. If the EU said "$5 less for no WMA, another $5 for no IE", you'd see PCs with mozilla and winamp (or worse, AOL edition netscape + real audio) within two months. One week for the PC vendor to make the image, one night to FTP it the ODM in Taiwan, 5 weeks to get the boxes in the shops.
This is a really good summary of OSS projects.
Lots of minor projects get reincorporated into distro, without any clue what changes were made, and yet are still expected to field bugreps against them.
At the same time, distros need to identify projects that are significant, and get involved in the dev list/planning, if only to get some kind of presence in the project.
For example, the Apache Ant project took input from the eclipse and netbeans teams over their release schedules, and once we'd determined that Ant1.7 wouldnt cut it, did a 1.6.4 release for them: http://wiki.apache.org/ant/Ant17/Planning
One concern I have about this downstream involvement is that it creates extra schedule pressure. A project that releases when it wants can be more relaxed about schedules and release when happy. When vendor driven, you are more prone to release to meet some random milestone, rather than when the quality is best. That means shorter beta tests, possibly lower standards all round. Which can't be good.
Well, there is nothing wrong with having a select email list giving heads up warnings to key distributors. One per vendor, no favouritism among community (Debian) and commercial products, and relying on trust amongst participants.
:)
I think products like Apache HTTPD work like this. Once you have a significant amount of market share, and a significant amount of redistribution, you need to take security more seriously.
Maybe this will mark a maturing of Mozilla. Till now firefox has relied on being "more secure than IE", which isnt really that hard to achieve. Now it has market share, it is vulnerable to zero day exploits -maybe more so, with all the source public. And that means the team needs to come up with a process that the redistributors and end users are happy with.
Hey, maybe the zero day exploits are our next metric of mozilla's popularity
The 'system restore' feature of windows was detecting that MS Messenger was missing, and 'fixing it'. As only an incompetent fool would want to delete msn messenger.
I think if you turned off system restore you could delete that and the pinball game.
Just be glad you werent auto-reported to the department of homeland security for being subversive.
Once you try and come up with an aircon design for 500 rack mounted boxes, power management matters there too.
I've found that the pentium-m laptop is better at work things (compiling, running java code) than the P4-Xeon-desktop. Its the best CPU design from intel for years.
I'm not going to argue the points, just observe that one possible cause for my frustration in the US is the way that coverage was sold off on such a fragmented basis. So many companies bidded up the NY coverage, whoever wanted oregon-south-east-sticks got got it 15c. Once you had the radio waves, it was free to do with what you wanted.
The EU process was
-per country
-GSM *mandated* on the relevant frequencies.
-same(ish) frequencies everywhere
So in a single country, you pick a provider and be relatively sure that it will work everywhere, bar the ones that are well known for bad coverage.
In the US, you dont even get per-state coverage. So when I am stuck in a ski resort like Bachelor, OR, I'd see signs "Cellular one is our provider, get cellular one today", as if I'd run out and buy a new phone, just to make calls from that place, even if it didnt work there.
Conclusion: The granularity of contract was too small.
Now in the EU, doing it per-country is arguably too small too. Its why you get hit hard when you go abroad. Maybe next time, they will do a "per EU" contract, though the countries like the licensing fees, and may not be willing to play that way.
Yes, both are flawed. But when I lived in Oregon I found what was on offer truly sucked. There are still some parts of the state (much of the coast; nealry everywhere south of eugene bar I5), where analog is all you get, and you are meant to be grateful.
Note that the use of SMS is not just to save money on calls (my virgin prepay is 5p/minute after the first few minutes of a day; no monthly fee). Its more a social thing. you text people a bit when its less important than voice, more than email. I'm told that in Japan it is common for a round of texting is the precursor to a call "can I call you now?", with all the incurred extra revenue for the telcos that implies.
A big rip-off in europe is when you roam, the caller makes an apparent long haul connection to the home country, the recipient ends up fielding the receipt costs. Which is why when you travel for any length of time, you just buy a new prepay SIM for that country, text the # to your contacts, and away you go.
-steve
(ps, you can have countries that are not states. Scotland, for example)
Despite the article authors critique of DSL, he could at least get a pay-as-you-go mobile for a reasonable fee, one that works everywhere.
Whereas US mobile phones, what an epic.
1. you need to work out which providers have approximate coverage in the places you live, work and travel.
2. you then need to decide between prepay or x-minute contracts.
3. prepay is very expensive, minutes expire unless you phone is topped up, not available everywhere.
4. x-minute contracts are rounded up minutes. Its not "50 minutes of calls a month", its "50 calls a month, of 1 minute or less each". And the minutes expire.
5. you pay to receive calls, on your mobile. So family minutes are cut in half if they are used intra-family.
6. you pay to receive text messages!
7. there is no such thing as text message interop! You cant text other networks. So you need to know the network of your friends.
8. Different network providers have different handsets. You cant juggle SIM cards around or choose the phone you want.
9. When you buy a phone, you pay an "activation fee" for some idiot in the shop to turn it on and press a few buttons.
10. phones are bound to a particular area code. If you move, you either need a new number, or people pay long distance rates to get to your phone.
Clearly the incompetence and pricing of EU land lines helped encourage good mobile phone networks. But also those crushing government standards bodies that mandated GSM everywhere, SIM cards everywhere ended up creating an ecosystem of phones, SIM cards and low friction switching between providers. It also created a new crime: phone theft, but that's another story.
-steve
I'm glad you dont have javadocs. Its a cheap way to make a bad book.
more to the point, it dates so fast in the OSS world. Oreilly could get away with the original Java in a Nutshell book because the entire Java API was small enough to print, and because the API stayed frozen for two years.
but any living OSS project has an API that evolves weekly; and point releases every few months. printed documentation just doesnt cut it here. Instead books have to focus on why and how to use library, not what the APIs are.
I know that is actually harder, but the reader benefits, and so ultimately, the author and publisher.
-steve
(currently writing the second edition of Java Development with Ant)
1. The Apache Portable Runtime will probably be the basis for a lot of the portabliity stuff.
2. OSS things -like eclipse's SWT windowing toolkit wont need rewriting -they become the test suite as well as part of the distributable.
3. Things like garbage collection and VM performance could be an area for research. Hopefully it will be a good platform for academic research, stuff we can use.
4. Testing is the big problem. There are not yet enough public tests to verify JVM 'compliance'. I dont know if apache can get hold of the Java1.5 Test Kit. Sun have given teams access to other TCKs (Axis and Geronimo, for example), so it may be possible. If we can do that, we may have a chance.
Wine has a harder problem, in that the Win32 is only implicitly specified by the behaviour of the system. Java is a lot cleaner, and was designed for portability from day one. But some bits of the JDK are probably badly specified; that will surface eventually.
steve loughran.
(apache member, but not (yet) involved in harmony)
agreed.
My isp blocks outbound port 135 connections as worm symptoms. It effectively locks up internet access for anyone using outlook. But for security reasons, that is probably a good thing.
Actually, reliablity may not be too bad, and bandwidth would be excellent. Plus the RIAA wouldnt be able to know what was going on, 'cept by using drive-round-vans like the TV license detectors they have here in the UK.
The trick is to get away from the star model of access point and client and go to full fledged mesh networks, with the appopriate discovery and routing.
This is still a research area, but it is interesting. the best bit: many of the algorithms for routing and discovery are the same as those for P2P networks.
I've only ever worked on CMOS cameras, so things may be different there. its a very different process.
In CMOS, each pixel is monochrome; a filter array is placed over the top to give it colour. Something like RGRGRG on one row, then BRBRBR on the one underneath.
For those people writing the code to handle this straight off the camera, you get frame size metadata, marker info of new frames, then the data itself.
Processing it into quality colour images is a choice of using the best algorithm you have *in the time available*. If you are doing a viewfinder or video capture you also want to subsample -do this before applying the color matrix equations (that is what they are) saves a lot of CPU load.
I can well believe that full raw data and third party algorithms can radically improve quality of images. But that has a consequence: it makes the unimproved images look worse. Maybe that is Nikon's concern -adobe will make the nikon software look bad.
I've used VMWare to test windows drivers on linux boxes; its great for testing device independent bits (like filesystems). Buti it has limits
-threading/race conditions dont surface (nonexistent/different thread model)
-limited set of devices
-no power events
They are still fantastic; you can treat a bluescreen or a toasted filesystem as an app crash, not a major distaster. But eventually you need to move to real hardware.
It's a lot better than Autoroute on the laptop was, that one suggested to me that I turn left off the clifton suspension bridge to get to the road 70m below.
8 0&saddr=nugent+hill,+bristol&daddr=Dove+Street,+Ci ty+of+Bristol,+Bristol,+BS2&hl=en
It also knows a lot about blocked off roads, enough to suggest an almost viable route between two roads. I say almost, as it did add one illegal U-turn:-
http://maps.google.co.uk/maps?spn=0.009552,0.0157
If I look five years ahead, I worry about how to design networks and protocols that are defensible against MPAA, RIAA and generic lawsuits.
A lot of the adhoc stuff in the PDF look a bit like this something that must terrify the {MPA.RIA}A lawyers who would like to make DRM a requirement of all future network topologies and protocols.
TCP was an implicit political statement. It said "we don't need telcos to make us pay for every second of a virtual ciruit", the way the OSI architecture was designed.
Future networks need to think about what threats there are to their functional operation, its not just scalability, or adhoc-ness, its defending against politicians and lawyers who dont understand.
Do you think when skynet becomes self aware, it wouldnt acquire admin rights on ./ and lock out all postings about "killer terminator robots seen motorbiking round LA" or "help, the military grid is now sentient".
/. audience are the people who stand a chance of stopping it, it would probably distract them all with different postings, like "free video p0rn service", or introduce a special distro of linux which looked like a descendant of debian but turned out to be a node in the syket grid-brain.
Instead, assuming that the
Maybe it really varies by subject; Biology is a wierd one because there is so much money there.
CS, by its very nature, is so computer centric, and often there are the accompanying code, screenshots, demo programs and videos: the web is the natural way to distribute this stuff.
Even in CS, the ACM is not free to read, it is relatively low cost compared to the 'retail' publishers, who are still up to their old practises.
I am fortunate I recently had a paper turned down by one of the latter, because their journal rules explicitly stated "not to be published online". I have got it into an IEEE conference instead, and we will be hosting it for everyone to see.
And that, when you think about it, is what matters. The more people read your work, the more they may learn from it (or, for people playing academic politics, the more they may cite it).