Since grades are supposed to be approximately normally distributed, no technology should raise grades. They should remain the same: approximately normally distributed. The real metric would be "can Johnny read better" or "can Jenny do math better" not "are their grades higher?"
Oh, wait, forgot about that stupid grade inflation thing where we're making the tests easier and not changing the grading curve to match...
Power and Power variation. To get enough power out of steam, you have to have high compressions, which steam is lousy at. Driving a turbine to generate electricity can be done at lower compressions, and also at more constant compressions.
This is pure arrogance. You aren't *THAT* good. Code is more than inputs and outputs. You should be judged on how you do it. It has been my near universal experience in the last 30 years of reading/reviewing code that the people most opposed to code reviews tend to be the producers of the worst, hardest to maintain code in the tree.
WinCE based boot loaders have existed for the past 10-12 years. But there's a problem with them. You can't replace the code at the reset vectors which is necessary to get the deep sleep modes working properly. You can run Linux or BSD on the box, but you'll not be able to suspend the laptop, nor will you be able to easily script the booting. If you are relying on WinCE to do the booting, you're also not able to reclaim that space in the Flash memory either.
Back in the day, the reason that the MobilePro 780 (and friends) had severe limitations running Linux/BSD was due to the design of the hardware. WinCE was installed into mask programmable ROMs. This meant that it was impossible to replace the code at the locations the processors vectored to when doing a reset. This meant that deep sleep was impossible.
These days, the OS is held in flash memory, and can be replaced more easily. Most of the systems I've played with it has been possible to replace things. One big issue, however, is that the WinCE boot loader has a different interface to the kernel hand-off than uboot or redboot. This can be replaced, but can be harder because of protected boot blocks.... I've not reflashed the latest
A 2/3 vote is easy to see if it passes. You must have at least 2x the number of 'yes' votes than 'no' votes. 136 to 70 fails because 136 is less than 140. It is as simple as that.
Also, this news is almost a year old. April 30, 2009 is the date on the article.
Well, if they learn safe habits as teenagers, then they are more likely to practice safe habits as adults. We are sexual creatures, and we do our children a big disservice by not teaching them about sex when they are young. People marry, get divorced, etc. It is a reality of the culture today. Knowing about condoms isn't going to make you more likely to cheat on your wife/husband. It isn't going to make you more or less likely to get a divorce. Those problems come from other areas and pathologies. Pretending that the only time people have sex is when they are teens is insane.... this is a life-long learning issue. One that does society as a whole a big disservice. The Lord taught us certain ways to behave. Be he also taught us that all sinners must be forgiven, and through him they will know God and be saved. Judge not, lest ye be judged, as that old book goes.
Yet, it is ok for a bunch of moralizing do-gooders to damage society in the name of religion and morality? Give me a break. You don't learn morality by always being good. You learn morality by getting burned sometimes when you are bad, even if you learned all about it before you got burned. Bah.
To get the flavor of this right, you need to get all your neighbor's to sneak their TV into this neighbors yard. Then have them all call the cops and issue a press release that this neighbor is clearly the head of a TV theft gang. He has stolen so many he can't keep them all inside and has to litter his front yard with them. For bonus points get him arrested for littering and creating a pubic nuisance.
I've used the various add-ons that make multi-tasking possible on iPhone OS 3.1.2. Of course, I just mean "being able to run multiple GUI applications at once" by this statement, but that's kinda what it means in the popular, non-technical press...
I have a few observations.
First, some applications react very well to running in this mode. In fact, most of the ones I've tried do act well. I can get my facebook updates, have my chat client running, etc. So long as I'm careful with memory usage, things are all fast.
When memory gets tight, things fall apart. Sometimes the app dies, sometimes it gets really slow, etc. I have an old 2G phone, so memory is limited there. I doubt that native support for this would be stable enough to be enabled in iPhone OS 4 by default on the 2G.
Finally, the one reason I'd want this, assuming I had the memory, is that Apple would likely improve the GUI aspects of multi-tasking. There's no notification right now if I get a chat message. There's no mail notification. I'd love to have that stuff be possible while I'm playing a game (or disabled, depending on the game). The various jailbrake add-ons don't address this aspect of things. It is a rough edge in an otherwise highly integrated environment.
Almost correct. While the case precedents exist, they are still not as strong as you'd like because they have never been reviewed. This means they are still vulnerable to being replaced by precedents from other cases that do get fully reviewed. That's the bad thing about this ending in a settlement: since the case never wound its way entirely through the system, these rulings were never fully tested.
So the fact that the case was weak enough for one side to settle is encouraging, but there's still a long way to go before there's a good level of case law on open source.
I have a 62" TV at home. And if you read the letter of the law, I have to get permission from the NFL to watch the game on my TV. This rule was put in place years ago when *NOBODY* had TV's this large at home (except maybe for the rear project crowd). Now that TV's bigger than 55" are very affordable, lots of people have them, and it will become more of a problem. I'd hate to see a rule designed to apply to.0001% of the population being used as a big revenue stream as technology evolves. This rule needs to change with the times, since the assumptions that anybody who has a TV bigger than 55" must be commercial is no longer valid.
I have no problems with the NFL charging businesses to make money off their public exhibition of the superbowl, mind you, but when it starts to make life difficult for me as a private citizen I start to get cranky.
As someone who worked on the refit to the Loran-C US chains, I can tell you that the secondary transmitters do *NOT* listen for the master station pulse to send out their pulse. It is all controlled by custom hardware that is fed off atomic clocks that are fed off GPS (when available). If the MASTER station goes down, the secondary stations continue to chirp, and most receivers can work out the master's missing pulses.
The stations, transmitters and arrangements of pulses in LORAN-C were all designed to be redundant to failure of one component wouldn't shut down a station or the network.
Uber coders also know when to trash old code rather than update it to new standards. The culling of the herd to fit the available resources if often more important than keeping the sickly and poorly written code alive. It optimizes resource use for everybody: the code is smaller, less of it has to be maintained, etc. These skills are often overlooked as well since they are devlishly hard to measure.
This is absolutely critical for small companies to have. Otherwise the code grows faster than their ability to keep it up to date. They need more people doing more work than is necessary. This can push the small company over the edge of profitability (either there are too few people to do the work needed so sales suffer, or there's too few sales to support all the mouths needed to keep this extra code around).
Another trait of uber-coders is they have a global view. This global view often allows then do things much more efficiently because they know exactly the right level to do it. They don't have to do a lot of extra work "just in case" at the wrong layers. Poor programmers do the extra work and justify it as being careful, when they are only being wasteful to the project.
Large companies could benefit from these traits, but the way management is setup makes it difficult to properly measure these skills, reward the teams that practice them and to save the company money (which, in theory should be split between the company and the uber-coders). Sometimes the skills are recognized outside of the normal set of metrics, but often times they are not.
finally, if you think you are an uber-coder, it would be in your best interest to also be an uber-communicator. Not that you have to communicate a lot, but often times the right communications at the right times help more than huge reports that nobody does more than glance at anyway. The best prose for me often times is cut down by 1/2 from my initial drafts and 3/4 rewritten, but everybody is different. The uber-communication skills is what will get you noticed, promoted and have raises go your way. This is especially true if you can make other people more productive by merging the uber-coding and uber-communicating roles.
Even this article points out that btrfs isn't ready for production, while ZFS is in production systems today. How does that make brtfs better? Does it have a better license? Does it have more potential? Maybe. But that alone doesn't make it better today.
It all depends on what FreeNAS' target market is going to be. Is it going to be old desktop machines that people recycle into NAS boxes, or will it be the large variety of NAS boxes that are found in the wild today. If the former, then the switch to Linux buys you nothing. Really, FreeBSD and Linux run the same on x86 hardware (sometimes one is faster, or the other, or there's an issue that keeps one or the other from running, but in general both just work damn well). If the target is the latter, then Linux might have a small edge, but only because the FreeBSD project hasn't focused on the proper packaging of FreeBSD for an embedded system that has the tight memory constraints that the non-intel NAS boxes have. Many companies have climbed this hill, but there's nothing that's been standardized enough to be ready to include in FreeBSD (although both NanoBSD and TinyBSD could be made to work). M0m0wall and FreeNAS innovated in other areas, and this area would be easy to innovate in as well, since the problem is well understood and most of the tools necessary to make it work are already extant in the tree.
Forking FreeNAS may or may not be the right thing to do. It might be better to provide a FreeNAS 0.7 -> NewFreeNAS project that is rewritten from scratch for FreeBSD 8.0 that doesn't suffer from the php interface that replaces/etc/rc.d. That's the main barrier to porting from 7.x -> 8.x for FreeNAS (and m0m0wall). It would likely be faster and simpler to go that route and fix whatever issues come up. This would allow one to migrate to better http technology that puts less in the server and more on the client in javascript/ajaxish/etc things anyway. This would allow users to continue to use FreeBSD's solid ZFS base as well as have a solution that's here today rather than waiting for Linux to catch up with its reimplementation of zfs:)
I've been involved in an open source project (FreeBSD) for a long time. There have been a number of complaints about GPL violations in the past. These complaints are usually made in private. That helps a lot. Often times the compaints are wrong (The GPL code that was alleged to have been taken and improperly included in FreeBSD turned out to have been taken from BSD 4.4lite and incorporated into the GPL code was the worst example). There have also been cases where the same code appeared in drivers in multiple places. Again, that wasn't a GPL violation because both places took the code from a common data sheet. Sometimes supposed violations are cleaned up out of an abundance of caution: it isn't clear the code is improperly included, but the code in question is easy to rewrite and/or icky to start with.
There are also times where GPL code is improperly imported code from BSD as well. Even when these are found it isn't always worth it to complain. Sometimes the gain from complaining is so small that it is easier to just let the folks use the code and not worry too much about it. Sometimes having the code out there and improperly licensed is better than getting it removed from the code base.
In general, I've found that most people that aren't lawyers don't know the law or the provenance of the code very well. By complaining in private, you get a chance to learn a bit about both. You also give people a chance to make it right. With large open source projects, the chances for accidental mistakes are high. The projects are generally keen to avoid the mistakes in the first place, and even keener on making sure that they get ironed out after the facts. Turns out most companies have a similar view and will do the right thing when asked (but sometimes it takes a little time, which is OK: the GPL never said instantly on demand).
Of course, this begs the question about the validity of the License to use GPL software after a violation has occurred, the scope to which license is lost, how to get it back, etc. GPLv2 is silent on the issue, while GPLv3 gives you one shot to fix it (but that's likely insufficient for large companies that have multiple product lines done by disjoint sets of people all of whom aren't educated on the finer points of incorporating GPL software into their products).
The GPL has been held to be valid a number of times in a court of law in different countries. This is true. However, the lawyers didn't say it was invalid, so it is also irrelevant.
They said that it was unclear what is meant by derived work, and therefore it was unclear what could be licensed with a different license when combined with GPLv2 software, and what had to have a GPLv2 license. It all hinges, according to them, on if one takes an expansive view or a narrow view reading of the independent work clause. This is something that's very much up in the air right now, with many people playing fast and loose with the rules. You have a continuum of behavior here. Everything from "I wrote this file, therefore I don't have to license it under the GPL, even though it is linked into the kernel" to "I GPL'd the shims to my proprietary driver, but not the driver itself." The authors point out it is unclear how much of this behavior is safe and how much isn't. The ambiguity and shifting attitudes about what is and is not a derived work creates risk and uncertainty when using this license.
They claim GPLv3 doesn't suffer from these weaknesses.
Nowhere to do they claim the GPLv2 is not legally valid. Just that ambiguity exists,
I had a Libretto 50CT, which pre-dated the 70CT. I loved the size (it was almost exactly the same size as a VCR tape) for portability. Had a slow Pentium processor in it. I dropped mine and the warrantee couldn't fix it so it was replaced by a Sony that I didn't like as much.
The keyboard was small, and kinda hard to type on. But I got used to it. I did a lot of development on FreeBSD PC Card and CardBus stacks on that little box. I do miss it, except when I need to see a lot of data on the screen. Then I like my newer laptops better...
There was also this crazy libretto mailing list for hacking the suckers. People posted how to overclock them by soldering and removing 0 ohm resistors, how to build car power supplies (I built one and learned a lot), how to add brightness enhancing films, how to hook up better microphones, etc. These things found their way into lots of small environments before the Soekris boxes became popular for such things.
But having used it, I do know what the limitations of the new crop of netbooks have. They are kinda cool, and all run FreeBSD very well, but I haven't jumped in yet... My life has changed a lot since I had the Libretto and I'm no longer sure it is a good fit. I like the bigger text on my "newer" laptop, but miss all the quirkiness of the Libretto....
Juniper's JunOS is FreeBSD based. It wouldn't make sense to count most of Juniper's revenues as part of the Linux EcoSystem. While they have acquired a small number of Linux-based startups, the vast majority of revenue is from is FreeBSD JunOS software. Oh, and all that hardware...
How do you separate out the difference between the two anyway?
Slashdot Mirror
Since grades are supposed to be approximately normally distributed, no technology should raise grades. They should remain the same: approximately normally distributed. The real metric would be "can Johnny read better" or "can Jenny do math better" not "are their grades higher?"
Oh, wait, forgot about that stupid grade inflation thing where we're making the tests easier and not changing the grading curve to match...
Power and Power variation. To get enough power out of steam, you have to have high compressions, which steam is lousy at. Driving a turbine to generate electricity can be done at lower compressions, and also at more constant compressions.
This is pure arrogance. You aren't *THAT* good. Code is more than inputs and outputs. You should be judged on how you do it. It has been my near universal experience in the last 30 years of reading/reviewing code that the people most opposed to code reviews tend to be the producers of the worst, hardest to maintain code in the tree.
There's two FreeBSD Ports committers who have done more:
20110412 ok 1 16978 miwi
20110517 ok 2 13027 pav
I have the ATTANSIC L1 on one of my systems, and it works great on FreeBSD 8.1.
This formatter won't do anything to help you out. It will just put a new filesystem on the part. You can't 'reformat' FLASH. Bad is bad, and you lose.
WinCE based boot loaders have existed for the past 10-12 years. But there's a problem with them. You can't replace the code at the reset vectors which is necessary to get the deep sleep modes working properly. You can run Linux or BSD on the box, but you'll not be able to suspend the laptop, nor will you be able to easily script the booting. If you are relying on WinCE to do the booting, you're also not able to reclaim that space in the Flash memory either.
Back in the day, the reason that the MobilePro 780 (and friends) had severe limitations running Linux/BSD was due to the design of the hardware. WinCE was installed into mask programmable ROMs. This meant that it was impossible to replace the code at the locations the processors vectored to when doing a reset. This meant that deep sleep was impossible.
These days, the OS is held in flash memory, and can be replaced more easily. Most of the systems I've played with it has been possible to replace things. One big issue, however, is that the WinCE boot loader has a different interface to the kernel hand-off than uboot or redboot. This can be replaced, but can be harder because of protected boot blocks.... I've not reflashed the latest
A 2/3 vote is easy to see if it passes. You must have at least 2x the number of 'yes' votes than 'no' votes. 136 to 70 fails because 136 is less than 140. It is as simple as that.
Also, this news is almost a year old. April 30, 2009 is the date on the article.
1. Make a core that's too big to fuel speculation /.
2. Seed the press with rumors of this from bloggers that get on
3. ????
4. PROFIT
Well, if they learn safe habits as teenagers, then they are more likely to practice safe habits as adults. We are sexual creatures, and we do our children a big disservice by not teaching them about sex when they are young. People marry, get divorced, etc. It is a reality of the culture today. Knowing about condoms isn't going to make you more likely to cheat on your wife/husband. It isn't going to make you more or less likely to get a divorce. Those problems come from other areas and pathologies. Pretending that the only time people have sex is when they are teens is insane.... this is a life-long learning issue. One that does society as a whole a big disservice. The Lord taught us certain ways to behave. Be he also taught us that all sinners must be forgiven, and through him they will know God and be saved. Judge not, lest ye be judged, as that old book goes.
Yet, it is ok for a bunch of moralizing do-gooders to damage society in the name of religion and morality? Give me a break. You don't learn morality by always being good. You learn morality by getting burned sometimes when you are bad, even if you learned all about it before you got burned. Bah.
To get the flavor of this right, you need to get all your neighbor's to sneak their TV into this neighbors yard. Then have them all call the cops and issue a press release that this neighbor is clearly the head of a TV theft gang. He has stolen so many he can't keep them all inside and has to litter his front yard with them. For bonus points get him arrested for littering and creating a pubic nuisance.
If these allegations are true, it is the very definition of unclean hands...
And people wonder why we need net neutrality. This should shine a bright light into why it is so needed.
I've used the various add-ons that make multi-tasking possible on iPhone OS 3.1.2. Of course, I just mean "being able to run multiple GUI applications at once" by this statement, but that's kinda what it means in the popular, non-technical press...
I have a few observations.
First, some applications react very well to running in this mode. In fact, most of the ones I've tried do act well. I can get my facebook updates, have my chat client running, etc. So long as I'm careful with memory usage, things are all fast.
When memory gets tight, things fall apart. Sometimes the app dies, sometimes it gets really slow, etc. I have an old 2G phone, so memory is limited there. I doubt that native support for this would be stable enough to be enabled in iPhone OS 4 by default on the 2G.
Finally, the one reason I'd want this, assuming I had the memory, is that Apple would likely improve the GUI aspects of multi-tasking. There's no notification right now if I get a chat message. There's no mail notification. I'd love to have that stuff be possible while I'm playing a game (or disabled, depending on the game). The various jailbrake add-ons don't address this aspect of things. It is a rough edge in an otherwise highly integrated environment.
Warner
Almost correct. While the case precedents exist, they are still not as strong as you'd like because they have never been reviewed. This means they are still vulnerable to being replaced by precedents from other cases that do get fully reviewed. That's the bad thing about this ending in a settlement: since the case never wound its way entirely through the system, these rulings were never fully tested.
So the fact that the case was weak enough for one side to settle is encouraging, but there's still a long way to go before there's a good level of case law on open source.
The problem here is the 55" rule.
I have a 62" TV at home. And if you read the letter of the law, I have to get permission from the NFL to watch the game on my TV. This rule was put in place years ago when *NOBODY* had TV's this large at home (except maybe for the rear project crowd). Now that TV's bigger than 55" are very affordable, lots of people have them, and it will become more of a problem. I'd hate to see a rule designed to apply to .0001% of the population being used as a big revenue stream as technology evolves. This rule needs to change with the times, since the assumptions that anybody who has a TV bigger than 55" must be commercial is no longer valid.
I have no problems with the NFL charging businesses to make money off their public exhibition of the superbowl, mind you, but when it starts to make life difficult for me as a private citizen I start to get cranky.
As someone who worked on the refit to the Loran-C US chains, I can tell you that the secondary transmitters do *NOT* listen for the master station pulse to send out their pulse. It is all controlled by custom hardware that is fed off atomic clocks that are fed off GPS (when available). If the MASTER station goes down, the secondary stations continue to chirp, and most receivers can work out the master's missing pulses.
The stations, transmitters and arrangements of pulses in LORAN-C were all designed to be redundant to failure of one component wouldn't shut down a station or the network.
Uber coders also know when to trash old code rather than update it to new standards. The culling of the herd to fit the available resources if often more important than keeping the sickly and poorly written code alive. It optimizes resource use for everybody: the code is smaller, less of it has to be maintained, etc. These skills are often overlooked as well since they are devlishly hard to measure.
This is absolutely critical for small companies to have. Otherwise the code grows faster than their ability to keep it up to date. They need more people doing more work than is necessary. This can push the small company over the edge of profitability (either there are too few people to do the work needed so sales suffer, or there's too few sales to support all the mouths needed to keep this extra code around).
Another trait of uber-coders is they have a global view. This global view often allows then do things much more efficiently because they know exactly the right level to do it. They don't have to do a lot of extra work "just in case" at the wrong layers. Poor programmers do the extra work and justify it as being careful, when they are only being wasteful to the project.
Large companies could benefit from these traits, but the way management is setup makes it difficult to properly measure these skills, reward the teams that practice them and to save the company money (which, in theory should be split between the company and the uber-coders). Sometimes the skills are recognized outside of the normal set of metrics, but often times they are not.
finally, if you think you are an uber-coder, it would be in your best interest to also be an uber-communicator. Not that you have to communicate a lot, but often times the right communications at the right times help more than huge reports that nobody does more than glance at anyway. The best prose for me often times is cut down by 1/2 from my initial drafts and 3/4 rewritten, but everybody is different. The uber-communication skills is what will get you noticed, promoted and have raises go your way. This is especially true if you can make other people more productive by merging the uber-coding and uber-communicating roles.
Even this article points out that btrfs isn't ready for production, while ZFS is in production systems today. How does that make brtfs better? Does it have a better license? Does it have more potential? Maybe. But that alone doesn't make it better today.
It all depends on what FreeNAS' target market is going to be. Is it going to be old desktop machines that people recycle into NAS boxes, or will it be the large variety of NAS boxes that are found in the wild today. If the former, then the switch to Linux buys you nothing. Really, FreeBSD and Linux run the same on x86 hardware (sometimes one is faster, or the other, or there's an issue that keeps one or the other from running, but in general both just work damn well). If the target is the latter, then Linux might have a small edge, but only because the FreeBSD project hasn't focused on the proper packaging of FreeBSD for an embedded system that has the tight memory constraints that the non-intel NAS boxes have. Many companies have climbed this hill, but there's nothing that's been standardized enough to be ready to include in FreeBSD (although both NanoBSD and TinyBSD could be made to work). M0m0wall and FreeNAS innovated in other areas, and this area would be easy to innovate in as well, since the problem is well understood and most of the tools necessary to make it work are already extant in the tree.
Forking FreeNAS may or may not be the right thing to do. It might be better to provide a FreeNAS 0.7 -> NewFreeNAS project that is rewritten from scratch for FreeBSD 8.0 that doesn't suffer from the php interface that replaces /etc/rc.d. That's the main barrier to porting from 7.x -> 8.x for FreeNAS (and m0m0wall). It would likely be faster and simpler to go that route and fix whatever issues come up. This would allow one to migrate to better http technology that puts less in the server and more on the client in javascript/ajaxish/etc things anyway. This would allow users to continue to use FreeBSD's solid ZFS base as well as have a solution that's here today rather than waiting for Linux to catch up with its reimplementation of zfs :)
Warner
I've been involved in an open source project (FreeBSD) for a long time. There have been a number of complaints about GPL violations in the past. These complaints are usually made in private. That helps a lot. Often times the compaints are wrong (The GPL code that was alleged to have been taken and improperly included in FreeBSD turned out to have been taken from BSD 4.4lite and incorporated into the GPL code was the worst example). There have also been cases where the same code appeared in drivers in multiple places. Again, that wasn't a GPL violation because both places took the code from a common data sheet. Sometimes supposed violations are cleaned up out of an abundance of caution: it isn't clear the code is improperly included, but the code in question is easy to rewrite and/or icky to start with.
There are also times where GPL code is improperly imported code from BSD as well. Even when these are found it isn't always worth it to complain. Sometimes the gain from complaining is so small that it is easier to just let the folks use the code and not worry too much about it. Sometimes having the code out there and improperly licensed is better than getting it removed from the code base.
In general, I've found that most people that aren't lawyers don't know the law or the provenance of the code very well. By complaining in private, you get a chance to learn a bit about both. You also give people a chance to make it right. With large open source projects, the chances for accidental mistakes are high. The projects are generally keen to avoid the mistakes in the first place, and even keener on making sure that they get ironed out after the facts. Turns out most companies have a similar view and will do the right thing when asked (but sometimes it takes a little time, which is OK: the GPL never said instantly on demand).
Of course, this begs the question about the validity of the License to use GPL software after a violation has occurred, the scope to which license is lost, how to get it back, etc. GPLv2 is silent on the issue, while GPLv3 gives you one shot to fix it (but that's likely insufficient for large companies that have multiple product lines done by disjoint sets of people all of whom aren't educated on the finer points of incorporating GPL software into their products).
The GPL has been held to be valid a number of times in a court of law in different countries. This is true. However, the lawyers didn't say it was invalid, so it is also irrelevant.
They said that it was unclear what is meant by derived work, and therefore it was unclear what could be licensed with a different license when combined with GPLv2 software, and what had to have a GPLv2 license. It all hinges, according to them, on if one takes an expansive view or a narrow view reading of the independent work clause. This is something that's very much up in the air right now, with many people playing fast and loose with the rules. You have a continuum of behavior here. Everything from "I wrote this file, therefore I don't have to license it under the GPL, even though it is linked into the kernel" to "I GPL'd the shims to my proprietary driver, but not the driver itself." The authors point out it is unclear how much of this behavior is safe and how much isn't. The ambiguity and shifting attitudes about what is and is not a derived work creates risk and uncertainty when using this license.
They claim GPLv3 doesn't suffer from these weaknesses.
Nowhere to do they claim the GPLv2 is not legally valid. Just that ambiguity exists,
This assumes that those binaries are recompiled.
assert(sizeof(foo) == sizeof(bar)) (or the compile time variations) is just as effective...
I had a Libretto 50CT, which pre-dated the 70CT. I loved the size (it was almost exactly the same size as a VCR tape) for portability. Had a slow Pentium processor in it. I dropped mine and the warrantee couldn't fix it so it was replaced by a Sony that I didn't like as much.
The keyboard was small, and kinda hard to type on. But I got used to it. I did a lot of development on FreeBSD PC Card and CardBus stacks on that little box. I do miss it, except when I need to see a lot of data on the screen. Then I like my newer laptops better...
There was also this crazy libretto mailing list for hacking the suckers. People posted how to overclock them by soldering and removing 0 ohm resistors, how to build car power supplies (I built one and learned a lot), how to add brightness enhancing films, how to hook up better microphones, etc. These things found their way into lots of small environments before the Soekris boxes became popular for such things.
But having used it, I do know what the limitations of the new crop of netbooks have. They are kinda cool, and all run FreeBSD very well, but I haven't jumped in yet... My life has changed a lot since I had the Libretto and I'm no longer sure it is a good fit. I like the bigger text on my "newer" laptop, but miss all the quirkiness of the Libretto....
Juniper's JunOS is FreeBSD based. It wouldn't make sense to count most of Juniper's revenues as part of the Linux EcoSystem. While they have acquired a small number of Linux-based startups, the vast majority of revenue is from is FreeBSD JunOS software. Oh, and all that hardware...
How do you separate out the difference between the two anyway?