I would think that in theory you could figure out AoA from a combination of gyros and accelerometers - ie an inertial navigation system.
Now, how accurate it would be is an entirely different matter. INS determines the absolute position, orientation, and velocity of the aircraft at all times. That is the only way it would work at all. If you know orientation and velocity, you know AoA.
Now, in practice the designers probably didn't really think that airliners flying 60kts without crew awareness of the fact would be a problem they had to deal with. That is REALLY slow for an airliner - they'd have been falling like a ton of bricks.
Artificial horizon - based on gyro. Attitude indicator - based on gyro. (Usually independent - small plans use vac vs electric power, not 100% what the setup on an airliner is but they have usually multiple independent inertial navigation systems that run the glass displays. And I don't think airliners have a turn coordinator per se but they usually have an independent artificial horizon. Altitude and rate of climb - based on static air. I don't know about this case but I suspect this is less likely to have frozen up like the pitot tube as static ports do not face into the airflow. I think they're usually on the bottom of the fuselage where ice shouldn't accumulate much. Airpseed - based on static and pitot air. I'm guessing this is the only thing that failed, but it is pretty important.
Nova had a really good special on the likely cause of the problem.
Frankly, I think our school system is half the problem.
Before institutionalized education, the average teenager probably spent most of their formative years around adults, learning to act like adults.
Today, they spend most of their formative years around others their own age, learning to act like others their own age. They often do this up to the age of 21-22 with college being what it is. Sure, it is a lot more fun, but not exactly great for developing maturity/responsibility.
However, the problem certainly doesn't end with schools. The whole system has some fundamental flaws:
1. People just naturally want to fit in with everybody else. If they talk to their friends and find that 70% of them like candidate A, pretty soon they'll all like candidate A. The hold-out who likes candidate B will find themselves less accepted by the group. Sure, maybe that is learned in part in the school cafeteria, but I think most people are wired that way too.
2. People favor sound bytes over nuanced argument. People now live in fear that candidate A will get rid of social security or whatever. Nobody can even talk about reforming the system - they simply get labeled by some sound bite and massacred in the polls. So, people keep their messages simple. However, not every problem has a simple solution.
3. There is no accountability after election. People say whatever they need to say to get elected, and then when they're up for re-election they do the same. The same flaws of human nature that prevent people from making rational decisions about voting the first time prevent people from considering actual track record the second time.
4. People are lousy at estimating risk. People worry about somebody blowing up a plane they fly on once every three years, or that the politician will somehow turn the US into a theocracy, or that social security will be completely eliminated, or that social security will be completely bankrupt, or sea levels will rise 200 feet, or whatever. They don't worry about outcomes which are less dramatic but much more likely to impact them, so candidate bothers to talk about anything grounded in the real world.
I know exactly what ps, grep, and kill do. I can't remember the last time I did a ps -eal and just paged through the list of processes running on my machine. If it rose to the top on atop and didn't have an innocent-looking name then maybe I'd get suspicious.
If the virus just piped instructions into bash or whatever it would run under the process name bash. How likely is somebody to notice an extra bash running or whatever as long as it doesn't consume an ungodly amount of resources?
Now, not running as root would make a process easy prey for rkhunter and things like that - assuming the user runs them.
We need to get away from enumerating badness and simply define SELinux policies for apps or whatever.
About the only thing a virus running as admin/root gets is the ability to infect other executables, or to affect something that happens on a different user account. The average win/mac/linux desktop has only one user account actually used on it anyway.
Oh, running as root/admin also lets the virus start on boot, instead of login. If you're infecting servers that don't have anybody logged in 99% of the time I guess that matters. If you're infecting desktops, how many people leave their PCs running but not logged in?
The whole OS security model needs to change to something more like what is done in Android or SELinux. That does require a lot of upstream/distro support or otherwise needs to be designed into the apps. Even android has its limitations - users can't easily modify an apps permissions so they're stuck with just the options of use or not use. Access needs to be more granular than the user account. Vim doesn't need to be able to open TCP sockets, and firefox doesn't need to be able to read my thunderbird contacts list or whatever. If apps were isolated in general then their ability to cause damage would be greatly limited.
If your goal isn't to make money, but just to be educated, then why enroll in a degree program? Why not just audit the courses or whatever? You learn just as much, and end up being just as well-rounded. However, you get to also pick what courses you want to take and usually end up paying less for them.
Priority #1 for a teenager is to figure out some way to support themselves for the rest of their life that they'll be able to live with. Once they're self-supporting they can pay for all the fun they want, whether that be in the form of movie tickets or tuition payments or whatever.
I have nothing against teens doing otherwise. However, my kids know that I won't be paying for it if they go that route, which generally means they won't be able to do it anyway since they would still have to cite my income on their financial aid forms (and I'm not required by law to provide this info). So far it is working out just fine for them.
Ah, one of the very rare cases where US citizens actually seem to have more rights than their peers in Europe. It would be much more difficult to make a case like this in a US court. Plus, even if a court pursued it they would be stopped dead in their tracks when they hit a reporter, since they generally don't have to divulge their sources. A few have been held in contempt over issues related to national security, but even those decisions were highly controversial and I can't see courts going this far over celebrity gossip.
Also, in the US privacy laws aren't nearly as strong - especially for celebrities.
Btrfs is already in the kernel. Removing the experimental tag in the config item won't in itself cause any more instability.
The only reason I could see forking a new branch is if integrating btrfs required making changes to a higher layer in the kernel (which the filesystem drivers plug into). Changes contained within the filesystem driver don't impact people who don't use that filesystem, or enable support for it when building their kernel.
Branching the entire kernel codebase should be reserved for major changes to the architecture of the kernel itself - ones that you can't simply turn on/off with configuration options/etc. The problem with such branching is that you're now maintaining two diverging codebases and you constantly need to translate/merge changes from the one back into the other. The last time it happened it took years to get the new branch mainstreamed, so I doubt Linus is looking to repeat that experience anytime soon.
As long as changes are evolutionary and not revolutionary branching shouldn't be necessary.
You need to look at it from a different perspective.
A recent CM7 deployment wouldn't boot on some phones. A dot release was quickly issued to fix the problem. Probably quite a few people got burned. However, what kinds of users got burned? They were early adopters who managed to root their phone and who generally know how to boot into recovery/etc. So, getting their phones back up and running wasn't that big a deal - just an inconvenience.
Suppose that same update went out OTA to EVERYBODY with that model of phone. Tens of thousands of people would have phones that didn't boot correctly before it would be caught. Those phones would no longer receive OTA updates, so the only fix is for every person to mail in their phone or bring it into a service center of some kind (maybe a local store), where it would be recovered from HBOOT with a signed image on an SD card. What would that cost the company in terms of money and reputation?
Cyanogen et al can get away with minimal QA because it is marketed towards users who don't need much hand-holding. The general consumption OTA builds are marketed at a different target - reliability is most critical there.
And yes, I agree that CM overall tends to have a higher level of general quality than most carrier builds. It is just that when they get it wrong, they sometimes manage to get it quite spectacularly wrong. A systematic test suite on many phones upgraded under various conditions would minimize that risk, though at considerable cost and delay.
Cyanogenmod doesn't have quality control - at least not in the traditional sense. If a changelog shows any changes between the last build and the release candidate, then you essentially don't have quality control. Now, this is par for the course for enthusiast-backed distros, and cyanogen quality is better than most.
What the Cyanogenmod team calls stable is really beta at best on most controlled projects - it means that maybe some devs have used the build for a day or whatever. When updates don't boot or whatever clearly there wasn't any actual testing.
The way actual quality control works is this:
1. Freeze features. 2. Fix known serious bugs. 3. Issue RC. 4. Test RC. 5. If bad, go back to 2. 6. If good, relabel RC as release version. DON'T MAKE CHANGES TO IT!
That last bit is important. If you even add a bugfix to an RC then you need to re-test - at least if you don't want regressions.
No phone manufacturer is going to want to warrant anything they didn't make, and they're certainly not going to make it easy for customers to enhance an existing product instead of buying a new one - unless they want a brand experience (like Apple). Most people don't say "gee, I liked my last HTC phone" - they say "hey, this phone has the best price/features."
And, as far as rooting and support goes, there is nothing stopping manufacturers from adding a fastboot oem unlock option to their devices. That should stop the completely clueless from doing damage.
Also, despite what everybody says, merely rooting your phone and flashing the firmware doesn't void your warranty. Warranties are legally-controlled things. Ford can put a sticker on the car that buying non-Ford parts or accessories will void your warranty, but if you add generic floor mats and your engine dies they're not going to be able to get out of fixing it. If you flash a new firmware and the phone hangs on boot, then it is probably your problem. If you flash a new firmware, later get bad reception, then flash the original firmware and still have bad reception, then the phone might have a hardware problem that the manufacturer would need to fix. Of course, you might need to go to court to enforce this right.
In my experience the biggest problem with corporate IT is risk aversion. Process is a substitute for trusted personnel, because it is hard to have the latter in a large organization, and it is easy to have the former.
If there is a massive security breach, the head of IT is likely to get fired over it (or maybe somebody one level down/etc). However, just about anybody in IT is capable of leaving open a door that would allow such a breach. So, there are tons of rules to try to prevent this, and tons of checks to make sure the rules are followed. Of course, a security breach is just one thing that can get messed up, and there are a million other bad things that can happen, and a bunch of rules to go along with each of them.
In a smaller company you hire people you trust, and actually invest in them. Sadly, that seems to be something lacking in most corporate IT departments. If you can't trust your employees, then you try to control them instead. It sort-of works, but it tends to prevent anything good from happening in the same way that it tends to prevent anything bad from happening. Mostly it is about having somebody else to blame when an underling turns out to be fallible.
That is true, but Amazon has a solution for this (at least as far as the distribution centers go). The South Caroline house just approved a bill to make Amazon tax-exempt in exchange for the creation of a new distribution center in the state. So, expect any future Amazon facilities to be exempt from local taxes, and when time comes to close a facility expect the states Amazon is already operating in to start passing exemptions to avoid being the location where they close a facility.
Mega-corps can get around these kinds of things because they have discretion around where they do business, and states often need them more than the reverse.
I think that this is a good reason to eliminate the ability for local jurisdictions to levy sales taxes. Ditto for speed limits - it is annoying to have a road change speeds 10 times in 10 miles with no real change in the population density/etc.
I do support having local governments in general, but in this case it really does get in the way of commerce. If the locality wants to have a crazy property tax structure then only people who live in it need to worry about it. If the locality believes in having stop signs every 10 feet, congestion fees, and a sales tax that applies differently to 5000 different classes of products then that is a cost they impose on anybody who merely needs to pass through, or do mail order/etc.
Having local control over local affairs makes sense. Having a country with 10,000 tax jurisdictions and probably 100,000 different tax rules affecting sales of anything from penicillin to diapers to soda is just a burden on commerce that doesn't really add any real value.
N1 - last update issued about 1.5 years after first sale (maybe it is 1.75). NS - last update issued about 2 months after first sale.
That isn't exactly a stellar history. Granted, the N1 and NS may still get more updates in the future (or they may not - there are no promises, and Google seems to just stop updating phones and not really announce any kind of official EOL policy). Also - I couldn't find an official firmware release history / changelog for any of these phones so it is possible I missed some kind of a minor update. Corrections are welcome.
N1 has had constant OTA updates since it was launched - in fact, it was updated to 2.3.4 about two weeks ago. NS, exactly the same, some times getting releases some weeks before N1.
So... did you just not bother looking for it, or are you intentionally spreading FUD?
So, per my post, I couldn't find any kind of official change history for the firmware on either the N1 or NS, and you still haven't provided a link to one. I did in fact go looking for it, and apparently did not find whatever you managed to find. A link to an official release history / changelog / etc for those phones would be welcome (assuming Google bothers to publish one).
So, taking your statement at face value, the N1 has had updates up to two years after first sale, and the NS has had updates up to five months after first sale. If they're still publishing N1 updates two years from now I'll be willing to call it a well-supported platform.
I never said that the N1 wasn't getting updates - only that Google does not have a history of support phones for more than about 1.5-1.75 years after original sale. It looks like with the N1 they're bumping that up to 2 years. I'd call the bare acceptable minimum two years after the date of the last sale, as this is the length of a typical phone service contract. I believe they were selling the ADP right up until the N1 came out, so they effectively stopped releasing updates for that phone six months BEFORE they stopped selling it. Now, I do agree that the ADP was a bit of a niche and served more as a reference platform - it would not have made sense for them to stop selling it before a replacement was available.
Honestly, the only smartphone out there that I would consider to have a reliable history of support is the iPhone, and you can't even change the battery on that without doing surgery. It kills me to have to say that, and I really do hope that Google demonstrates their commitment to support by issuing updates to the N1 for another 1.5 years (which would be about two years after their last sale).
It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).
Only a problem on Linux, and a self-imposed problem at that. Given the situation though, it is indeed clean-room re-implementation or nothing. It is a goal of the author of the GPL to make this very thing a legal requirement: if software isn't licensed under terms he found (and codified as) acceptable, and is worth having, said software should be independently re-authored and released under terms he does find acceptable. In other words, this is the GPL in action, as intended.
Agreed on all points, but I don't really see this as a big problem for linux. In five years we'll probably have btrfs have the level of adoption of ext3, and zfs will probably have less adoption than ufs/2/etc does now. In the end, licensing does make a difference.
The licensing is by far the biggest problem with ZFS.
That's a matter of perspective; the licensors do not find the licensing to be a problem, which is what made it an allowable choice for them. People whose software's license is not incompatible with that of ZFS do not find it problematic. People whose software's license was explicitly conceived with the express purpose of superseding other licenses' limitations and grants of right with its own obviously "have a problem" with it; that is the designed legal goal of the GPL.
Well, I'm not sure what publishing ZFS under the CDDL has gotten Sun (and now Oracle). ZFS was intended to breathe new life into Solaris, but it didn't work out all that well in the end - probably because it was too much under the control of a single company for anybody to want to trust it.
You mentioned clean-room re-implementation. I'm glad that the linux camp didn't go that route with ZFS (creating a binary compatible filesystem), but rather they created a new one aiming for a similar feature set. If ZFS were re-implemented it probably would have been forever in catchup mode, with the non-GPL implementation being considered the reference one. New features might not have been well-suited to the GPL implementation requiring refactoring/etc over time. By starting from scratch btrfs will start out behind, but it has the potential to move ahead.
You seem to be of the mindset that the GPL forces projects to shoot themselves in the foot by re-implementing things that others have already done. I'll agree that this is a downside to the GPL, but from what I've observed the costs are outweighed by the benefits. I think a lot more people are likely to contribute to a GPL project than a non-GPL one. Corporate contributors in particular have more incentive to contribute to a GPL project rather than a non-copyleft one as it is much harder for a competitor to get an advantage by leveraging the code. Sun was a bit of an exception - they wanted the benefits of open source but in this case they were already suffering because they were in direct competition with linux and generally losing, and they didn't want to make it possible for linux to leverage their code easily.
The original devices Google was selling were developer devices: they weren't targeted at consumers, so I don't think they carried the same support expectations.
The original ADP was identical hardware-wise to the G1, which was a consumer device. The G1 had no better support than the ADP. If the G1 wasn't at least reasonably successful there might never have been an N1.
In any case, the hardware in those devices wouldn't have been able to run Android 2.x in any usable manner. Believe me, my first Android phone had pretty similar hardware to those developer devices and I tried Android 2.2 on it. Unusable.
I own a G1, and with a recent radio which frees up 16MB or RAM it actually is usable with 2.2. Granted, it is limited.
However, I don't consider that a valid excuse for Google abandoning their initial platform in 1.5 year's time. They could have backported whatever enhancements they could have to the older platform. Microsoft still supports XP after 10 years. Google didn't even support their platform for the length of a typical cell phone contract.
I agree that it's too early to tell whether the Nexus devices will be properly supported, but it's not really fair to bunch the Nexus phones together with the earlier developer devices.
I dunno. I think Google's commitment is to making the next version of Android shinier than the last. If it is easy to get it to run on one of their existing phone models they'll probably do it. If it isn't then they probably won't. The newer models are clearly more future-proof (RAM being the biggest factor), but the N1 isn't even as old as the ADP was when it was declared obsolete.
Don't get me wrong - I love android, and the fact that Google is trying to create reference devices with a superior experience. However, they could really use better long-term support. I'm not sure that they need the enterprise-level 10-year support that MS provides, but is 3-4 years too much to ask?
Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.
And without burning linux in your BIOS, how do you propose to run it on a system that lacks a hard drive? The best you can do right now is PXE, and that has a lot of limitations. At the very least you need to control the dhcp server to do it.
The parent was arguing that bootloaders should be simple, and I was arguing that complexity is fine if it suits their purpose, which is loading the kernel. I'd love to see LinuxBIOS being standard on all PCs, as it is a more versatile way of finding and loading the kernel.
Bootloader can load just the microkernel what then knows what part of the disk to read to load filesystem modules and execute their process and then load other OS modules after running INIT or similar non-OS process.
What if there isn't a disk on the machine? I agree that the only thing the bootloader needs to do is load the kernel, but that doesn't mean that it doesn't need to understand anything about advanced storage systems. There is stuff like PXE, but that has some limitations, and in the end you're just adding extra steps to the process.
If your BIOS could have a "URL of kernel" parameter, how would that be a bad thing?
Well, one of the nice things about linuxbios/etc is that it offers a great deal more versatility.
Do you really want to have to have a hard drive installed just so that you can boot off of an OS image on a SAN? Or a USB drive or whatever?
The whole purpose of a boot loader is to find a kernel and boot it. Anything that makes it possible for the bootloader to find a kernel on a more exotic architecture is perfectly in-scope as far as I'm concerned, as long as it doesn't leave anything behind in RAM once it is done doing its job.
Copy on write also increases striped raid performance as long as there is a reasonable amount of free space, as it avoids having to read a stripe before writing it. This also depends on the whole "rampant layering violation" thing.
And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.
The licensing is by far the biggest problem with ZFS. It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).
Also - the native VPN client in Android (as far as I have been able to tell) has a few other issues:
1. If the VPN isn't up, it just sends out traffic over the direct interface. All it takes is one packet with your token in it to leak your token - 98% VPN coverage just isn't good enough. If I want a VPN, then I don't want traffic to go out in the clear unless I explicitly acknowledge a message asking me about this.
2. I can't find any setting that lets me make the VPN the default route. There is the openvpn redirect gateway option, which isn't the same thing (it is dumb and even sends DHCP acks for the gateway over the VPN causing you to lose the lease).
Google should simply run all authentication over https, period. Wifi just makes the problem obvious, but even wired ethernet is vulnerable to sniffing, etc.
At some point non-SSL http should be EOL'ed. There should be two standards - https with trusted certificate (shows padlock), and https without a trusted certificate (treated like http is treated today and does not show padlock). That will eliminate the need for everybody to have a trusted certificate chain, but will cut out all the passive attacks.
You let me know which manufacturers are regularly pushing updates out to phones, and I'll give you a cookie, lol.
Any of the Nexus devices. Do I get a cookie now?
Really? I haven't seen Google support a phone for more than 1.5 years to date. Right now they have issued three phones under their brand:
ADP - last official update issued about 1 year after first sale, and six months before the N1 came out. If you're relying on Google support you're running Android 1.6, although if you are using Cyanogenmod you could be up to 2.2. N1 - last update issued about 1.5 years after first sale (maybe it is 1.75). NS - last update issued about 2 months after first sale.
That isn't exactly a stellar history. Granted, the N1 and NS may still get more updates in the future (or they may not - there are no promises, and Google seems to just stop updating phones and not really announce any kind of official EOL policy). Also - I couldn't find an official firmware release history / changelog for any of these phones so it is possible I missed some kind of a minor update. Corrections are welcome.
Would work at face value. Genetic algorithms can easily be used to solve something like that.
I'm not convinced it would work.
Such an algorithm might detect 15 different tax breaks for education, then notice that a huge percentage of college students own iPods, and thus conclude that the best simplification is a $5k tax credit for anybody who buys an iPod, or something equally dumb. Now, if such a break didn't change public behavior, then it might even work out the same in the end. However, any change in tax rules will definitely change public behavior, which means that the algorithm would have to be run iteratively.
The problem is that a set of a few hundred million people will itself implement what amounts to something like a genetic algorithm to game the tax code. So, which do you have more confidence in:
1. The ability of a computer program to come up with an un-gameable simple tax code? or 2. The ability of a few hundred million people to collectively figure out how to game the new tax code faster than the computer can fix it?
People still game the tax code, of course, but the current code at least targets the breaks where they are intended to go, which makes this a little harder.
Slashdot Mirror
I would think that in theory you could figure out AoA from a combination of gyros and accelerometers - ie an inertial navigation system.
Now, how accurate it would be is an entirely different matter. INS determines the absolute position, orientation, and velocity of the aircraft at all times. That is the only way it would work at all. If you know orientation and velocity, you know AoA.
Now, in practice the designers probably didn't really think that airliners flying 60kts without crew awareness of the fact would be a problem they had to deal with. That is REALLY slow for an airliner - they'd have been falling like a ton of bricks.
Artificial horizon - based on gyro.
Attitude indicator - based on gyro. (Usually independent - small plans use vac vs electric power, not 100% what the setup on an airliner is but they have usually multiple independent inertial navigation systems that run the glass displays. And I don't think airliners have a turn coordinator per se but they usually have an independent artificial horizon.
Altitude and rate of climb - based on static air. I don't know about this case but I suspect this is less likely to have frozen up like the pitot tube as static ports do not face into the airflow. I think they're usually on the bottom of the fuselage where ice shouldn't accumulate much.
Airpseed - based on static and pitot air. I'm guessing this is the only thing that failed, but it is pretty important.
Nova had a really good special on the likely cause of the problem.
Frankly, I think our school system is half the problem.
Before institutionalized education, the average teenager probably spent most of their formative years around adults, learning to act like adults.
Today, they spend most of their formative years around others their own age, learning to act like others their own age. They often do this up to the age of 21-22 with college being what it is. Sure, it is a lot more fun, but not exactly great for developing maturity/responsibility.
However, the problem certainly doesn't end with schools. The whole system has some fundamental flaws:
1. People just naturally want to fit in with everybody else. If they talk to their friends and find that 70% of them like candidate A, pretty soon they'll all like candidate A. The hold-out who likes candidate B will find themselves less accepted by the group. Sure, maybe that is learned in part in the school cafeteria, but I think most people are wired that way too.
2. People favor sound bytes over nuanced argument. People now live in fear that candidate A will get rid of social security or whatever. Nobody can even talk about reforming the system - they simply get labeled by some sound bite and massacred in the polls. So, people keep their messages simple. However, not every problem has a simple solution.
3. There is no accountability after election. People say whatever they need to say to get elected, and then when they're up for re-election they do the same. The same flaws of human nature that prevent people from making rational decisions about voting the first time prevent people from considering actual track record the second time.
4. People are lousy at estimating risk. People worry about somebody blowing up a plane they fly on once every three years, or that the politician will somehow turn the US into a theocracy, or that social security will be completely eliminated, or that social security will be completely bankrupt, or sea levels will rise 200 feet, or whatever. They don't worry about outcomes which are less dramatic but much more likely to impact them, so candidate bothers to talk about anything grounded in the real world.
I know exactly what ps, grep, and kill do. I can't remember the last time I did a ps -eal and just paged through the list of processes running on my machine. If it rose to the top on atop and didn't have an innocent-looking name then maybe I'd get suspicious.
If the virus just piped instructions into bash or whatever it would run under the process name bash. How likely is somebody to notice an extra bash running or whatever as long as it doesn't consume an ungodly amount of resources?
Now, not running as root would make a process easy prey for rkhunter and things like that - assuming the user runs them.
We need to get away from enumerating badness and simply define SELinux policies for apps or whatever.
About the only thing a virus running as admin/root gets is the ability to infect other executables, or to affect something that happens on a different user account. The average win/mac/linux desktop has only one user account actually used on it anyway.
Oh, running as root/admin also lets the virus start on boot, instead of login. If you're infecting servers that don't have anybody logged in 99% of the time I guess that matters. If you're infecting desktops, how many people leave their PCs running but not logged in?
The whole OS security model needs to change to something more like what is done in Android or SELinux. That does require a lot of upstream/distro support or otherwise needs to be designed into the apps. Even android has its limitations - users can't easily modify an apps permissions so they're stuck with just the options of use or not use. Access needs to be more granular than the user account. Vim doesn't need to be able to open TCP sockets, and firefox doesn't need to be able to read my thunderbird contacts list or whatever. If apps were isolated in general then their ability to cause damage would be greatly limited.
If your goal isn't to make money, but just to be educated, then why enroll in a degree program? Why not just audit the courses or whatever? You learn just as much, and end up being just as well-rounded. However, you get to also pick what courses you want to take and usually end up paying less for them.
Priority #1 for a teenager is to figure out some way to support themselves for the rest of their life that they'll be able to live with. Once they're self-supporting they can pay for all the fun they want, whether that be in the form of movie tickets or tuition payments or whatever.
I have nothing against teens doing otherwise. However, my kids know that I won't be paying for it if they go that route, which generally means they won't be able to do it anyway since they would still have to cite my income on their financial aid forms (and I'm not required by law to provide this info). So far it is working out just fine for them.
Ah, one of the very rare cases where US citizens actually seem to have more rights than their peers in Europe. It would be much more difficult to make a case like this in a US court. Plus, even if a court pursued it they would be stopped dead in their tracks when they hit a reporter, since they generally don't have to divulge their sources. A few have been held in contempt over issues related to national security, but even those decisions were highly controversial and I can't see courts going this far over celebrity gossip.
Also, in the US privacy laws aren't nearly as strong - especially for celebrities.
Btrfs is already in the kernel. Removing the experimental tag in the config item won't in itself cause any more instability.
The only reason I could see forking a new branch is if integrating btrfs required making changes to a higher layer in the kernel (which the filesystem drivers plug into). Changes contained within the filesystem driver don't impact people who don't use that filesystem, or enable support for it when building their kernel.
Branching the entire kernel codebase should be reserved for major changes to the architecture of the kernel itself - ones that you can't simply turn on/off with configuration options/etc. The problem with such branching is that you're now maintaining two diverging codebases and you constantly need to translate/merge changes from the one back into the other. The last time it happened it took years to get the new branch mainstreamed, so I doubt Linus is looking to repeat that experience anytime soon.
As long as changes are evolutionary and not revolutionary branching shouldn't be necessary.
You need to look at it from a different perspective.
A recent CM7 deployment wouldn't boot on some phones. A dot release was quickly issued to fix the problem. Probably quite a few people got burned. However, what kinds of users got burned? They were early adopters who managed to root their phone and who generally know how to boot into recovery/etc. So, getting their phones back up and running wasn't that big a deal - just an inconvenience.
Suppose that same update went out OTA to EVERYBODY with that model of phone. Tens of thousands of people would have phones that didn't boot correctly before it would be caught. Those phones would no longer receive OTA updates, so the only fix is for every person to mail in their phone or bring it into a service center of some kind (maybe a local store), where it would be recovered from HBOOT with a signed image on an SD card. What would that cost the company in terms of money and reputation?
Cyanogen et al can get away with minimal QA because it is marketed towards users who don't need much hand-holding. The general consumption OTA builds are marketed at a different target - reliability is most critical there.
And yes, I agree that CM overall tends to have a higher level of general quality than most carrier builds. It is just that when they get it wrong, they sometimes manage to get it quite spectacularly wrong. A systematic test suite on many phones upgraded under various conditions would minimize that risk, though at considerable cost and delay.
Cyanogenmod doesn't have quality control - at least not in the traditional sense. If a changelog shows any changes between the last build and the release candidate, then you essentially don't have quality control. Now, this is par for the course for enthusiast-backed distros, and cyanogen quality is better than most.
What the Cyanogenmod team calls stable is really beta at best on most controlled projects - it means that maybe some devs have used the build for a day or whatever. When updates don't boot or whatever clearly there wasn't any actual testing.
The way actual quality control works is this:
1. Freeze features.
2. Fix known serious bugs.
3. Issue RC.
4. Test RC.
5. If bad, go back to 2.
6. If good, relabel RC as release version. DON'T MAKE CHANGES TO IT!
That last bit is important. If you even add a bugfix to an RC then you need to re-test - at least if you don't want regressions.
No phone manufacturer is going to want to warrant anything they didn't make, and they're certainly not going to make it easy for customers to enhance an existing product instead of buying a new one - unless they want a brand experience (like Apple). Most people don't say "gee, I liked my last HTC phone" - they say "hey, this phone has the best price/features."
And, as far as rooting and support goes, there is nothing stopping manufacturers from adding a fastboot oem unlock option to their devices. That should stop the completely clueless from doing damage.
Also, despite what everybody says, merely rooting your phone and flashing the firmware doesn't void your warranty. Warranties are legally-controlled things. Ford can put a sticker on the car that buying non-Ford parts or accessories will void your warranty, but if you add generic floor mats and your engine dies they're not going to be able to get out of fixing it. If you flash a new firmware and the phone hangs on boot, then it is probably your problem. If you flash a new firmware, later get bad reception, then flash the original firmware and still have bad reception, then the phone might have a hardware problem that the manufacturer would need to fix. Of course, you might need to go to court to enforce this right.
In my experience the biggest problem with corporate IT is risk aversion. Process is a substitute for trusted personnel, because it is hard to have the latter in a large organization, and it is easy to have the former.
If there is a massive security breach, the head of IT is likely to get fired over it (or maybe somebody one level down/etc). However, just about anybody in IT is capable of leaving open a door that would allow such a breach. So, there are tons of rules to try to prevent this, and tons of checks to make sure the rules are followed. Of course, a security breach is just one thing that can get messed up, and there are a million other bad things that can happen, and a bunch of rules to go along with each of them.
In a smaller company you hire people you trust, and actually invest in them. Sadly, that seems to be something lacking in most corporate IT departments. If you can't trust your employees, then you try to control them instead. It sort-of works, but it tends to prevent anything good from happening in the same way that it tends to prevent anything bad from happening. Mostly it is about having somebody else to blame when an underling turns out to be fallible.
That is true, but Amazon has a solution for this (at least as far as the distribution centers go). The South Caroline house just approved a bill to make Amazon tax-exempt in exchange for the creation of a new distribution center in the state. So, expect any future Amazon facilities to be exempt from local taxes, and when time comes to close a facility expect the states Amazon is already operating in to start passing exemptions to avoid being the location where they close a facility.
Mega-corps can get around these kinds of things because they have discretion around where they do business, and states often need them more than the reverse.
I think that this is a good reason to eliminate the ability for local jurisdictions to levy sales taxes. Ditto for speed limits - it is annoying to have a road change speeds 10 times in 10 miles with no real change in the population density/etc.
I do support having local governments in general, but in this case it really does get in the way of commerce. If the locality wants to have a crazy property tax structure then only people who live in it need to worry about it. If the locality believes in having stop signs every 10 feet, congestion fees, and a sales tax that applies differently to 5000 different classes of products then that is a cost they impose on anybody who merely needs to pass through, or do mail order/etc.
Having local control over local affairs makes sense. Having a country with 10,000 tax jurisdictions and probably 100,000 different tax rules affecting sales of anything from penicillin to diapers to soda is just a burden on commerce that doesn't really add any real value.
N1 - last update issued about 1.5 years after first sale (maybe it is 1.75).
NS - last update issued about 2 months after first sale.
That isn't exactly a stellar history. Granted, the N1 and NS may still get more updates in the future (or they may not - there are no promises, and Google seems to just stop updating phones and not really announce any kind of official EOL policy). Also - I couldn't find an official firmware release history / changelog for any of these phones so it is possible I missed some kind of a minor update. Corrections are welcome.
N1 has had constant OTA updates since it was launched - in fact, it was updated to 2.3.4 about two weeks ago.
NS, exactly the same, some times getting releases some weeks before N1.
So... did you just not bother looking for it, or are you intentionally spreading FUD?
So, per my post, I couldn't find any kind of official change history for the firmware on either the N1 or NS, and you still haven't provided a link to one. I did in fact go looking for it, and apparently did not find whatever you managed to find. A link to an official release history / changelog / etc for those phones would be welcome (assuming Google bothers to publish one).
So, taking your statement at face value, the N1 has had updates up to two years after first sale, and the NS has had updates up to five months after first sale. If they're still publishing N1 updates two years from now I'll be willing to call it a well-supported platform.
I never said that the N1 wasn't getting updates - only that Google does not have a history of support phones for more than about 1.5-1.75 years after original sale. It looks like with the N1 they're bumping that up to 2 years. I'd call the bare acceptable minimum two years after the date of the last sale, as this is the length of a typical phone service contract. I believe they were selling the ADP right up until the N1 came out, so they effectively stopped releasing updates for that phone six months BEFORE they stopped selling it. Now, I do agree that the ADP was a bit of a niche and served more as a reference platform - it would not have made sense for them to stop selling it before a replacement was available.
Honestly, the only smartphone out there that I would consider to have a reliable history of support is the iPhone, and you can't even change the battery on that without doing surgery. It kills me to have to say that, and I really do hope that Google demonstrates their commitment to support by issuing updates to the N1 for another 1.5 years (which would be about two years after their last sale).
It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).
Only a problem on Linux, and a self-imposed problem at that. Given the situation though, it is indeed clean-room re-implementation or nothing. It is a goal of the author of the GPL to make this very thing a legal requirement: if software isn't licensed under terms he found (and codified as) acceptable, and is worth having, said software should be independently re-authored and released under terms he does find acceptable. In other words, this is the GPL in action, as intended.
Agreed on all points, but I don't really see this as a big problem for linux. In five years we'll probably have btrfs have the level of adoption of ext3, and zfs will probably have less adoption than ufs/2/etc does now. In the end, licensing does make a difference.
The licensing is by far the biggest problem with ZFS.
That's a matter of perspective; the licensors do not find the licensing to be a problem, which is what made it an allowable choice for them. People whose software's license is not incompatible with that of ZFS do not find it problematic. People whose software's license was explicitly conceived with the express purpose of superseding other licenses' limitations and grants of right with its own obviously "have a problem" with it; that is the designed legal goal of the GPL.
Well, I'm not sure what publishing ZFS under the CDDL has gotten Sun (and now Oracle). ZFS was intended to breathe new life into Solaris, but it didn't work out all that well in the end - probably because it was too much under the control of a single company for anybody to want to trust it.
You mentioned clean-room re-implementation. I'm glad that the linux camp didn't go that route with ZFS (creating a binary compatible filesystem), but rather they created a new one aiming for a similar feature set. If ZFS were re-implemented it probably would have been forever in catchup mode, with the non-GPL implementation being considered the reference one. New features might not have been well-suited to the GPL implementation requiring refactoring/etc over time. By starting from scratch btrfs will start out behind, but it has the potential to move ahead.
You seem to be of the mindset that the GPL forces projects to shoot themselves in the foot by re-implementing things that others have already done. I'll agree that this is a downside to the GPL, but from what I've observed the costs are outweighed by the benefits. I think a lot more people are likely to contribute to a GPL project than a non-GPL one. Corporate contributors in particular have more incentive to contribute to a GPL project rather than a non-copyleft one as it is much harder for a competitor to get an advantage by leveraging the code. Sun was a bit of an exception - they wanted the benefits of open source but in this case they were already suffering because they were in direct competition with linux and generally losing, and they didn't want to make it possible for linux to leverage their code easily.
The original devices Google was selling were developer devices: they weren't targeted at consumers, so I don't think they carried the same support expectations.
The original ADP was identical hardware-wise to the G1, which was a consumer device. The G1 had no better support than the ADP. If the G1 wasn't at least reasonably successful there might never have been an N1.
In any case, the hardware in those devices wouldn't have been able to run Android 2.x in any usable manner. Believe me, my first Android phone had pretty similar hardware to those developer devices and I tried Android 2.2 on it. Unusable.
I own a G1, and with a recent radio which frees up 16MB or RAM it actually is usable with 2.2. Granted, it is limited.
However, I don't consider that a valid excuse for Google abandoning their initial platform in 1.5 year's time. They could have backported whatever enhancements they could have to the older platform. Microsoft still supports XP after 10 years. Google didn't even support their platform for the length of a typical cell phone contract.
I agree that it's too early to tell whether the Nexus devices will be properly supported, but it's not really fair to bunch the Nexus phones together with the earlier developer devices.
I dunno. I think Google's commitment is to making the next version of Android shinier than the last. If it is easy to get it to run on one of their existing phone models they'll probably do it. If it isn't then they probably won't. The newer models are clearly more future-proof (RAM being the biggest factor), but the N1 isn't even as old as the ADP was when it was declared obsolete.
Don't get me wrong - I love android, and the fact that Google is trying to create reference devices with a superior experience. However, they could really use better long-term support. I'm not sure that they need the enterprise-level 10-year support that MS provides, but is 3-4 years too much to ask?
Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.
See Kexec.
And without burning linux in your BIOS, how do you propose to run it on a system that lacks a hard drive? The best you can do right now is PXE, and that has a lot of limitations. At the very least you need to control the dhcp server to do it.
The parent was arguing that bootloaders should be simple, and I was arguing that complexity is fine if it suits their purpose, which is loading the kernel. I'd love to see LinuxBIOS being standard on all PCs, as it is a more versatile way of finding and loading the kernel.
Bootloader can load just the microkernel what then knows what part of the disk to read to load filesystem modules and execute their process and then load other OS modules after running INIT or similar non-OS process.
What if there isn't a disk on the machine? I agree that the only thing the bootloader needs to do is load the kernel, but that doesn't mean that it doesn't need to understand anything about advanced storage systems. There is stuff like PXE, but that has some limitations, and in the end you're just adding extra steps to the process.
If your BIOS could have a "URL of kernel" parameter, how would that be a bad thing?
Well, one of the nice things about linuxbios/etc is that it offers a great deal more versatility.
Do you really want to have to have a hard drive installed just so that you can boot off of an OS image on a SAN? Or a USB drive or whatever?
The whole purpose of a boot loader is to find a kernel and boot it. Anything that makes it possible for the bootloader to find a kernel on a more exotic architecture is perfectly in-scope as far as I'm concerned, as long as it doesn't leave anything behind in RAM once it is done doing its job.
Copy on write also increases striped raid performance as long as there is a reasonable amount of free space, as it avoids having to read a stripe before writing it. This also depends on the whole "rampant layering violation" thing.
And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.
The licensing is by far the biggest problem with ZFS. It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).
Also - the native VPN client in Android (as far as I have been able to tell) has a few other issues:
1. If the VPN isn't up, it just sends out traffic over the direct interface. All it takes is one packet with your token in it to leak your token - 98% VPN coverage just isn't good enough. If I want a VPN, then I don't want traffic to go out in the clear unless I explicitly acknowledge a message asking me about this.
2. I can't find any setting that lets me make the VPN the default route. There is the openvpn redirect gateway option, which isn't the same thing (it is dumb and even sends DHCP acks for the gateway over the VPN causing you to lose the lease).
Agreed.
Google should simply run all authentication over https, period. Wifi just makes the problem obvious, but even wired ethernet is vulnerable to sniffing, etc.
At some point non-SSL http should be EOL'ed. There should be two standards - https with trusted certificate (shows padlock), and https without a trusted certificate (treated like http is treated today and does not show padlock). That will eliminate the need for everybody to have a trusted certificate chain, but will cut out all the passive attacks.
You let me know which manufacturers are regularly pushing updates out to phones, and I'll give you a cookie, lol.
Any of the Nexus devices. Do I get a cookie now?
Really? I haven't seen Google support a phone for more than 1.5 years to date. Right now they have issued three phones under their brand:
ADP - last official update issued about 1 year after first sale, and six months before the N1 came out. If you're relying on Google support you're running Android 1.6, although if you are using Cyanogenmod you could be up to 2.2.
N1 - last update issued about 1.5 years after first sale (maybe it is 1.75).
NS - last update issued about 2 months after first sale.
That isn't exactly a stellar history. Granted, the N1 and NS may still get more updates in the future (or they may not - there are no promises, and Google seems to just stop updating phones and not really announce any kind of official EOL policy). Also - I couldn't find an official firmware release history / changelog for any of these phones so it is possible I missed some kind of a minor update. Corrections are welcome.
Would work at face value. Genetic algorithms can easily be used to solve something like that.
I'm not convinced it would work.
Such an algorithm might detect 15 different tax breaks for education, then notice that a huge percentage of college students own iPods, and thus conclude that the best simplification is a $5k tax credit for anybody who buys an iPod, or something equally dumb. Now, if such a break didn't change public behavior, then it might even work out the same in the end. However, any change in tax rules will definitely change public behavior, which means that the algorithm would have to be run iteratively.
The problem is that a set of a few hundred million people will itself implement what amounts to something like a genetic algorithm to game the tax code. So, which do you have more confidence in:
1. The ability of a computer program to come up with an un-gameable simple tax code?
or
2. The ability of a few hundred million people to collectively figure out how to game the new tax code faster than the computer can fix it?
People still game the tax code, of course, but the current code at least targets the breaks where they are intended to go, which makes this a little harder.