(The team couldn't study what happened when the two sides touched: The friction of the two sides moving in different directions sent the rubber bands flying out of the drum.)
What? It seems pretty obvious that they could see exactly what happened when the two sides touched, "The friction of the two sides moving in different directions sent the rubber bands flying out of the drum".
One idea I've seen floated is making the charging station + car act as a local battery for the power company. The user would have a set of preferences set up letting the charging station know the desired charge level for the car, and the station would charge when power is cheap and discharge when power is expensive within those limits.
So a typical usage scenario might actually be "Driver arrives at home and plugs in car during peak power usage time, car discharges further (down to some limit to cover things like "crap, I need X for dinner") until peak power usage ends, then trickle charges back up to some nominal level, and fully tops off at some low power usage point during the night."
Obviously the system needs to be adjustable on the fly for things like "I'm planning on going out tonight"
You generally wouldn't do fast charging at home, you'd do slow charging at normal household power levels (though probably from a large appliance-type socket rather than a regular outlet) It's cheaper for the power company and causes less wear on the battery. If this really becomes an issue more power companies might move to load-based pricing of power to further discourage power usage spikes that aren't necessary.
No, there isn't a difference between, "I want something for free", and "I want something for free because it's really really important.". The problem with this reasoning is that for some people, the barrier for really, really important is set really, really low.
I agree that the GP shouldn't have been modded troll though, not because it's true, but because it looks like a heartfelt sentiment.
This reminds me of an article I ran across a while back (too lazy for link) about a Chinese school for calculators (that's right, people who do arithmetic) who used the abacus as a teaching tool.
The first step is to learn to perform calculations on the abacus very rapidly. Once a certain level of proficiency is achieved, the abacus is removed and the student is able to perform the calculations without the help of the abacus. Generally they make flicking motions with their fingers while performing calculations, but with further training the hand motions are also eliminated and the computation is purely mental.
Practically useful? Probably not, but interesting. Personally I fire up a python interpreter when I need to do arithmetic on numbers too large to do in my head.
Nicely written and informative, but has no bearing whatsoever on the original question. The poster needs to be working while on the boat, which means "listening to the waves", while quite pleasant, will not help him meet his work responsibilities that are paying for this maritime expenses.
As has been mentioned previously in the thread, most people don't have the funds to stop working and sail full time. On the other hand, quite a lot of people have the funds necessary to sail full time if they can keep their jobs. (even more if they fully commit and sell their homes, cars, etc.. and move all of their possessions onto the boat) Therefore the constant and reliable communication with the home company is absolutely essential to the idea.
There's a gigantic difference between, "keep up to date on practices and algorithms in your field" and "read every patent that might have something to do with your work".
My understanding is that in the programming industry, current best practice is the "ostrich strategy", where you don't look at patents at all because it means you limit your liability if something does come up, because real "due diligence" in this field is pretty much impossible. If there were an impeccably designed and maintained patent index to check, and if the patents were written in a straightforward manner, this might not be the case, but as it is having every engineer (or even enough of them for peer review to catch things) be aware of patents to a high enough degree to provide real protection against infringement is a prohibitive amount of work.
Also "a neat design" doesn't necessarily mean "reinventing the wheel". In most cases in programming that sort of thing is an elegant implementation of a known algorithm for your specific problem.
Personally I'd far rather be notified ahead of time rather than when it happens. Configurable may be better, but at a certain point people start complaining about things being too complex. In my opinion both approaches have their strong and weak points.
It might not be a reasonable example, but in my head I have a scenario where some poor sap is frantically playing a game, nearing the climactic finale, and a dialog pops up asking, "allow app to access your bank account? Allow/Deny". How many people would just frantically clear the dialog and continue with the game?
99% of the Android users assume that since they've gotten the phone from their mobile provider whom they somewhat trust, and the phone came preloaded with the Android market app, that they can trust Android Market as much as they trust their mobile provider.
They CAN trust Android Market as much as they trust their mobile provider... which is to say either "unfounded trust", or "not at all".
The problem with this is that there is no way to verify that the action was performed based on user interaction, unless the OS interrupts the app every time it does something "suspicious" to ask for the user's permission. This doesn't work, because then the UI has a horrible interface that bothers you about things all the time.
The only information the OS has is that the app requested permission to dial phone numbers and the user hit "ok" to allowing that kind of access when the app was installed. Something you *might* want to do is have a separate security level for dialing when the phone is idle. (I have no idea if Android does this or not) Don't disallow it completely! what if I want an app to call my wife and remind her of something at a certain time? What if I'm paranoid about getting kidnapped and have a deadman switch app that calls someone and lets them know where I am if I DON'T enter a code into the phone once an hour? These are real (if odd) use cases.
Here's an example of why your plan doesn't work. Let's pick on google maps, and assume it's a malicious app. It isn't allowed to dial phone numbers unless the user is interacting with the app at the time. So you're driving somewhere and using the phone for navigation, you've met the requirement, so the app strikes! It calls a phone sex line while you're driving and gets you billed for it! There's fundamentally no way around this while providing powerful features and a good user interface.
If the app is malicious and you trust it, there is nothing the OS can do to protect you except for just disabling all the functionality you bought the thing for in the first place. (I'm hoping that smartphones in general allow you to disable functionality that you aren't comfortable with, if not that's bad, but a separate issue)
There are certainly things you can do to help reduce the exposure of the user, like only allowing programs to dial when the phone is in interactive mode (unless it specifically requested permission to do THAT), but in general, they are doing what they can to provide the user with the information they need in order to make an informed decision.
Sure that list is intimidating, but if you can't figure out why an app needs access to certain functionality, then you shouldn't install it, duh. It's up to the app author to clearly explain why it needs that access, and what it does with it that you just can't live without. Also they need to somehow establish their credibility. But that's a separate issue, partially addressed by the official app marketplace.
The problem with WebSense and it's ilk isn't really the false negatives, if you are dedicated enough to find unblocked sites that have what you're looking for, you're probably dedicated enough to proxy around them somehow. The real problem is false positives. I frequently will be following the trail of some work-pertinent information (usually a workaround for some obscure software bug) only to have it end with "this site is blocked due to: Personal sites".
I'm not claiming I don't waste time online at work (I'm here aren't I?), but WebSense doesn't seem to impact that at all, and it does interfere with my actual work on a pretty regular basis.
P.S. My experience is with WebSense, but I'm not saying they are bad in particular, it's the whole approach that is deeply flawed.
I see, and that helps the other apps on the box how?
I can understand where you're coming from, but you're thinking like a sysadmin, not a programmer. For general-purpose software we can't afford to take shortcuts like that, our software needs to be well-behaved or else someone else's well-behaved software gets used because it integrates better.
The example from the article describes a setup where the application is installed on three dedicated boxen, but how about MY use-case where I want some lightweight proxying in addition to the same box providing firewalling, DNS lookup, NTP server, NFS access, distcc, and a DLNA server? If I install YOUR proxy, I'll immediately uninstall it because it pins 80% of my RAM, or more likely I'd just never find out about it because that's just not something that's necessary for the application.
Re:Cache behavior is hard and not portable
on
Knuth Got It Wrong
·
· Score: 1
1. I don't think you can do this kind of optimization in a portable way period, POSIX might pretend you can, but I doubt the implementations are consistent enough to reliably deliver. 2. It's 4K, that's the page size that everyone has used for about 10 years now (of course it's finally changing now, bwahahaha). 2a. Unless you mean page size for non-x86 hardware, in which case portability? Bwahahaha.
But seriously, the algorithm is going to be the same, though the data structures and implementation might need a few tweaks here and there, that's what we get paid for, right?
Re:Theoretical performance vs real-world performan
on
Knuth Got It Wrong
·
· Score: 1
You actually have it backwards. With a finite n, it's completely up in the air which one is faster, since constant factors may outweigh the O() complexity. It's only as n approaches infinity that you can say for certain that O(n) will be faster than O(nlogn). That is the point the GP is making.
Also assuming you have operations that are O(1) and O(nlogn), and algorithms that are O(nlogn) and O(n) respectively, the "addition-based" algorithm is asymptotically faster (they will NOT converge), but that isn't the case in your example, it's actually O(1) and O(mlogm) (an independent input m), so for a bounded value of m, the O(nmlogm) may very well be faster than O(nlogn).
The fundamental problem here is a mixing of concerns, the memory access speed has no affect whatsoever on the computational complexity of the algorithm, which is all that classical big-Oh notation addresses. I wouldn't be at all surprised to find that modern notation has a standard way to denote special costs of operations, but if someone says "algorithm x is O(nlogn)", it is understood to mean idealized computational complexity based on the number of operations performed. If you feel like modeling things like number of IO operations as part of the complexity analysis, that is perfectly valid, but it doesn't invalidate the idealized representation of it's complexity.
Put another way, "Quicksort" has a complexity of O(nlogn) no matter what its set size is or what the operations cost, it doesn't matter that for most values of n the function is not computable, or that a particular comparison operation may take 5.6 millennia to compute, the complexity is still O(nlogn).
Re:Discrete Math &/or DataStructures material
on
Knuth Got It Wrong
·
· Score: 1
I had the same experience with Discrete Math and "Implementation and Optimization of Algorithms", which were actually synchronized such that you would be covering theory in Discrete Math that had application in "IOA". My favorite pair of classes in my major. Haven't had that much of a chance to use them in my career though *sigh*.
The node must be = page size AND page aligned. If it is not both of these things you will often read two pages per node. This isn't just a restriction that says, "when you read from swap, you must read 4K at a time". The reality is that the data is partitioned into specific 4K chunks, and if your data structure is not aligned to that 4K partitioning scheme, you can read a trivial amount of data and cause not just one, but two page faults. Also you seem to have missed the entire point of the article, which is that once you've had a page fault, you want to maximize the amount of useful data you retrieve with that page. The point is that there IS practically no difference between faulting a page and reading a single word from it and faulting a page and reading all of it. The time to do the page fault in this case absolutely dwarfs the time spent processing the data retrieved in that page. The use of a cache-oblivious algorithm is orthogonal to page-aligning your data structure, which is what the article is about.
Put another way, if your working set doesn't fit in ram, or more particularly if it is much larger than your available ram, you will get practiccally no benefit from using a cache-oblivious or cache-aware algorithm if you aren't also page-aligning your data, the disk access overheads (including swapping out OTHER memory) absolutely dwarfs any gain from micro-optimizations.
Tiny nit, cache-oblivious algorithms are generally asymptotically optimal (some are actually optimal), which means they tend towards optimality, but an architecture-aware solution can be strictly better. As I say though this is a very tiny nit, only in the highest echelons of performance-critical applications should this be an issue.
Specifically regarding the VM optimization the article is about, if your data structures/access patterns aren't aligned to pages you will generate "unnecessary" page faults. The VM system does not share the properties of cache that make that kind of optimization possible. As far as that is concerned I think the article is mostly correct, for optimal large-scale data processing, you have to be page-aware, which is exceedingly common in kernelspace (either BSD or Linux), but also exceedingly rare in userspace.
Concerning his assertion that CS departments are ignoring physical realities of computing, I'm not as sure of. I specifically recall having the concepts he is talking about introduced to me in a data structures class (not specifically with regard to VM page size, but with regard to cache alignment and on-disk data representation, obviously it generalizes to VM behavior if your application is using it.) YMMV, which perhaps makes his point.
haha, I guess you don't remember AOL, Compuserve or Prodigy. They tried that, and it didn't work out all that well for them.
Sure there are plenty of companies that want to lock their customers into their specific version of the internet, but fundamentally it's just too easy to get access to the real thing. Even if Safari started mangling pages sufficiently badly by default (which it is NOT doing right now), people could just move to other browsers. If it happened on one of Apple's locked-down platforms, sure it could cause some problems among that population, but they would still be free to switch to another platform that isn't as locked down.
Overall I see this as a reaction to an unsustainable business plan rather than anything else. Sure the timing is rather suspicious, but IMO the bad thing Apple is doing is the anti-competitive blocking of other players from its platform rather than some user-initiated reformatting of web pages.
I'm surprised that so many people use readability, but not AutoPager. It's a firefox extension that merges together consecutive pages. Couple it with AdBlock and NoScript and you have an extremely readable web,
The problem with these cell videos is they don't capture the whole event. A group of cops beating up a person looks extreme until you find out that person was resisting arrest and put both the cop and civilians in danger.
And? If the video is out of context or has been altered, the defendant (the police officer) or his counsel can argue that in court. Just because a recording might be inaccurate is certainly no reason to ban production of said recording. The court system has the means to take that kind of thing into account, the only reason to outright ban recordings is to keep the truth from getting out.
As far as public opinion is concerned, if the recording is modified and defamatory, I believe that would be covered under some branch of libel law.
That's the point, a good engineer's (or scientist's) response to new data that they can't fully explain is generally unmitigated glee, it means they've found something new. My takeaway from the article is, "try this new technique/tool, you'll see new data".
On another note, I've done some very basic analysis of disk performance at work, and this approach would have allowed me to be much more confident in my results. As it was, basically all I could do when comparing disks and filesystems was use iozone to characterize the "knee points" the article keeps mentioning, and try to map changes in aggregate numbers to saturation of various interfaces and/or devices. This method for actually getting sampling data for latency, and potentially from real workloads even, would have been extremely helpful.
Actually yes, the Android platform is a *very* customized Linux, the userspace for it is completely Google's invention, they basically took just the kernel and went from there. And as the other poster mentions, they made quite a lot of changes to the kernel as well. I think it would be fair to say that Android is the most extensive Linux fork to date, though they are at least trying to re-merge the kernel-level stuff.
Distributions such as Red Hat, Debian, etc... make changes around the periphery, but they keep their customizations to a minimal level where you can still build at least somewhat portable applications. Android threw this out completely, if you want to port an application from a Linux-based distribution to Android, you'll have a rather large porting effort ahead of you as the most fundamental system libraries were replaced.
To be clear, I'm not attacking Google here. They seem to be working pretty diligently to try and re-merge at least the kernel stuff. On the other hand, as a Linux developer, I'm not particularly interested in trying to learn their platform for development, I'm far more interested in the phone/portable environments that maintain userspace compatibility with the Linux ecosystem.
Slashdot Mirror
I was amused by this aside:
(The team couldn't study what happened when the two sides touched: The friction of the two sides moving in different directions sent the rubber bands flying out of the drum.)
What? It seems pretty obvious that they could see exactly what happened when the two sides touched, "The friction of the two sides moving in different directions sent the rubber bands flying out of the drum".
One idea I've seen floated is making the charging station + car act as a local battery for the power company. The user would have a set of preferences set up letting the charging station know the desired charge level for the car, and the station would charge when power is cheap and discharge when power is expensive within those limits.
So a typical usage scenario might actually be "Driver arrives at home and plugs in car during peak power usage time, car discharges further (down to some limit to cover things like "crap, I need X for dinner") until peak power usage ends, then trickle charges back up to some nominal level, and fully tops off at some low power usage point during the night."
Obviously the system needs to be adjustable on the fly for things like "I'm planning on going out tonight"
You generally wouldn't do fast charging at home, you'd do slow charging at normal household power levels (though probably from a large appliance-type socket rather than a regular outlet) It's cheaper for the power company and causes less wear on the battery.
If this really becomes an issue more power companies might move to load-based pricing of power to further discourage power usage spikes that aren't necessary.
No, there isn't a difference between, "I want something for free", and "I want something for free because it's really really important.". The problem with this reasoning is that for some people, the barrier for really, really important is set really, really low.
I agree that the GP shouldn't have been modded troll though, not because it's true, but because it looks like a heartfelt sentiment.
This reminds me of an article I ran across a while back (too lazy for link) about a Chinese school for calculators (that's right, people who do arithmetic) who used the abacus as a teaching tool.
The first step is to learn to perform calculations on the abacus very rapidly. Once a certain level of proficiency is achieved, the abacus is removed and the student is able to perform the calculations without the help of the abacus. Generally they make flicking motions with their fingers while performing calculations, but with further training the hand motions are also eliminated and the computation is purely mental.
Practically useful? Probably not, but interesting. Personally I fire up a python interpreter when I need to do arithmetic on numbers too large to do in my head.
Nicely written and informative, but has no bearing whatsoever on the original question. The poster needs to be working while on the boat, which means "listening to the waves", while quite pleasant, will not help him meet his work responsibilities that are paying for this maritime expenses.
As has been mentioned previously in the thread, most people don't have the funds to stop working and sail full time. On the other hand, quite a lot of people have the funds necessary to sail full time if they can keep their jobs. (even more if they fully commit and sell their homes, cars, etc.. and move all of their possessions onto the boat) Therefore the constant and reliable communication with the home company is absolutely essential to the idea.
No I'm similar, though not so much with science/math papers and more with requirement and design documentation and business proposal type crap.
I'm fine with having a WYSIWYG display *option*, but I definitely don't want to use a WYSIWYG interface to actually write content.
There's a gigantic difference between, "keep up to date on practices and algorithms in your field" and "read every patent that might have something to do with your work".
My understanding is that in the programming industry, current best practice is the "ostrich strategy", where you don't look at patents at all because it means you limit your liability if something does come up, because real "due diligence" in this field is pretty much impossible. If there were an impeccably designed and maintained patent index to check, and if the patents were written in a straightforward manner, this might not be the case, but as it is having every engineer (or even enough of them for peer review to catch things) be aware of patents to a high enough degree to provide real protection against infringement is a prohibitive amount of work.
Also "a neat design" doesn't necessarily mean "reinventing the wheel". In most cases in programming that sort of thing is an elegant implementation of a known algorithm for your specific problem.
Personally I'd far rather be notified ahead of time rather than when it happens. Configurable may be better, but at a certain point people start complaining about things being too complex. In my opinion both approaches have their strong and weak points.
It might not be a reasonable example, but in my head I have a scenario where some poor sap is frantically playing a game, nearing the climactic finale, and a dialog pops up asking, "allow app to access your bank account? Allow/Deny". How many people would just frantically clear the dialog and continue with the game?
99% of the Android users assume that since they've gotten the phone from their mobile provider whom they somewhat trust, and the phone came preloaded with the Android market app, that they can trust Android Market as much as they trust their mobile provider.
They CAN trust Android Market as much as they trust their mobile provider... which is to say either "unfounded trust", or "not at all".
The problem with this is that there is no way to verify that the action was performed based on user interaction, unless the OS interrupts the app every time it does something "suspicious" to ask for the user's permission. This doesn't work, because then the UI has a horrible interface that bothers you about things all the time.
The only information the OS has is that the app requested permission to dial phone numbers and the user hit "ok" to allowing that kind of access when the app was installed. Something you *might* want to do is have a separate security level for dialing when the phone is idle. (I have no idea if Android does this or not) Don't disallow it completely! what if I want an app to call my wife and remind her of something at a certain time? What if I'm paranoid about getting kidnapped and have a deadman switch app that calls someone and lets them know where I am if I DON'T enter a code into the phone once an hour? These are real (if odd) use cases.
Here's an example of why your plan doesn't work. Let's pick on google maps, and assume it's a malicious app. It isn't allowed to dial phone numbers unless the user is interacting with the app at the time. So you're driving somewhere and using the phone for navigation, you've met the requirement, so the app strikes! It calls a phone sex line while you're driving and gets you billed for it! There's fundamentally no way around this while providing powerful features and a good user interface.
If the app is malicious and you trust it, there is nothing the OS can do to protect you except for just disabling all the functionality you bought the thing for in the first place. (I'm hoping that smartphones in general allow you to disable functionality that you aren't comfortable with, if not that's bad, but a separate issue)
There are certainly things you can do to help reduce the exposure of the user, like only allowing programs to dial when the phone is in interactive mode (unless it specifically requested permission to do THAT), but in general, they are doing what they can to provide the user with the information they need in order to make an informed decision.
Sure that list is intimidating, but if you can't figure out why an app needs access to certain functionality, then you shouldn't install it, duh. It's up to the app author to clearly explain why it needs that access, and what it does with it that you just can't live without. Also they need to somehow establish their credibility. But that's a separate issue, partially addressed by the official app marketplace.
The problem with WebSense and it's ilk isn't really the false negatives, if you are dedicated enough to find unblocked sites that have what you're looking for, you're probably dedicated enough to proxy around them somehow. The real problem is false positives. I frequently will be following the trail of some work-pertinent information (usually a workaround for some obscure software bug) only to have it end with "this site is blocked due to: Personal sites".
I'm not claiming I don't waste time online at work (I'm here aren't I?), but WebSense doesn't seem to impact that at all, and it does interfere with my actual work on a pretty regular basis.
P.S. My experience is with WebSense, but I'm not saying they are bad in particular, it's the whole approach that is deeply flawed.
I see, and that helps the other apps on the box how?
I can understand where you're coming from, but you're thinking like a sysadmin, not a programmer. For general-purpose software we can't afford to take shortcuts like that, our software needs to be well-behaved or else someone else's well-behaved software gets used because it integrates better.
The example from the article describes a setup where the application is installed on three dedicated boxen, but how about MY use-case where I want some lightweight proxying in addition to the same box providing firewalling, DNS lookup, NTP server, NFS access, distcc, and a DLNA server? If I install YOUR proxy, I'll immediately uninstall it because it pins 80% of my RAM, or more likely I'd just never find out about it because that's just not something that's necessary for the application.
1. I don't think you can do this kind of optimization in a portable way period, POSIX might pretend you can, but I doubt the implementations are consistent enough to reliably deliver.
2. It's 4K, that's the page size that everyone has used for about 10 years now (of course it's finally changing now, bwahahaha).
2a. Unless you mean page size for non-x86 hardware, in which case portability? Bwahahaha.
But seriously, the algorithm is going to be the same, though the data structures and implementation might need a few tweaks here and there, that's what we get paid for, right?
You actually have it backwards. With a finite n, it's completely up in the air which one is faster, since constant factors may outweigh the O() complexity. It's only as n approaches infinity that you can say for certain that O(n) will be faster than O(nlogn). That is the point the GP is making.
Also assuming you have operations that are O(1) and O(nlogn), and algorithms that are O(nlogn) and O(n) respectively, the "addition-based" algorithm is asymptotically faster (they will NOT converge), but that isn't the case in your example, it's actually O(1) and O(mlogm) (an independent input m), so for a bounded value of m, the O(nmlogm) may very well be faster than O(nlogn).
The fundamental problem here is a mixing of concerns, the memory access speed has no affect whatsoever on the computational complexity of the algorithm, which is all that classical big-Oh notation addresses. I wouldn't be at all surprised to find that modern notation has a standard way to denote special costs of operations, but if someone says "algorithm x is O(nlogn)", it is understood to mean idealized computational complexity based on the number of operations performed. If you feel like modeling things like number of IO operations as part of the complexity analysis, that is perfectly valid, but it doesn't invalidate the idealized representation of it's complexity.
Put another way, "Quicksort" has a complexity of O(nlogn) no matter what its set size is or what the operations cost, it doesn't matter that for most values of n the function is not computable, or that a particular comparison operation may take 5.6 millennia to compute, the complexity is still O(nlogn).
I had the same experience with Discrete Math and "Implementation and Optimization of Algorithms", which were actually synchronized such that you would be covering theory in Discrete Math that had application in "IOA". My favorite pair of classes in my major. Haven't had that much of a chance to use them in my career though *sigh*.
The node must be = page size AND page aligned. If it is not both of these things you will often read two pages per node. This isn't just a restriction that says, "when you read from swap, you must read 4K at a time". The reality is that the data is partitioned into specific 4K chunks, and if your data structure is not aligned to that 4K partitioning scheme, you can read a trivial amount of data and cause not just one, but two page faults.
Also you seem to have missed the entire point of the article, which is that once you've had a page fault, you want to maximize the amount of useful data you retrieve with that page. The point is that there IS practically no difference between faulting a page and reading a single word from it and faulting a page and reading all of it. The time to do the page fault in this case absolutely dwarfs the time spent processing the data retrieved in that page. The use of a cache-oblivious algorithm is orthogonal to page-aligning your data structure, which is what the article is about.
Put another way, if your working set doesn't fit in ram, or more particularly if it is much larger than your available ram, you will get practiccally no benefit from using a cache-oblivious or cache-aware algorithm if you aren't also page-aligning your data, the disk access overheads (including swapping out OTHER memory) absolutely dwarfs any gain from micro-optimizations.
Tiny nit, cache-oblivious algorithms are generally asymptotically optimal (some are actually optimal), which means they tend towards optimality, but an architecture-aware solution can be strictly better. As I say though this is a very tiny nit, only in the highest echelons of performance-critical applications should this be an issue.
Specifically regarding the VM optimization the article is about, if your data structures/access patterns aren't aligned to pages you will generate "unnecessary" page faults. The VM system does not share the properties of cache that make that kind of optimization possible. As far as that is concerned I think the article is mostly correct, for optimal large-scale data processing, you have to be page-aware, which is exceedingly common in kernelspace (either BSD or Linux), but also exceedingly rare in userspace.
Concerning his assertion that CS departments are ignoring physical realities of computing, I'm not as sure of. I specifically recall having the concepts he is talking about introduced to me in a data structures class (not specifically with regard to VM page size, but with regard to cache alignment and on-disk data representation, obviously it generalizes to VM behavior if your application is using it.) YMMV, which perhaps makes his point.
haha, I guess you don't remember AOL, Compuserve or Prodigy. They tried that, and it didn't work out all that well for them.
Sure there are plenty of companies that want to lock their customers into their specific version of the internet, but fundamentally it's just too easy to get access to the real thing. Even if Safari started mangling pages sufficiently badly by default (which it is NOT doing right now), people could just move to other browsers. If it happened on one of Apple's locked-down platforms, sure it could cause some problems among that population, but they would still be free to switch to another platform that isn't as locked down.
Overall I see this as a reaction to an unsustainable business plan rather than anything else. Sure the timing is rather suspicious, but IMO the bad thing Apple is doing is the anti-competitive blocking of other players from its platform rather than some user-initiated reformatting of web pages.
I'm surprised that so many people use readability, but not AutoPager. It's a firefox extension that merges together consecutive pages. Couple it with AdBlock and NoScript and you have an extremely readable web,
Try AutoPager for Firefox, it addresses several of your concerns, and from what I gather is far more configurable.
In what world does the activities of a multinational corporation NOT include "interstate commerce"?
The problem with these cell videos is they don't capture the whole event. A group of cops beating up a person looks extreme until you find out that person was resisting arrest and put both the cop and civilians in danger.
And? If the video is out of context or has been altered, the defendant (the police officer) or his counsel can argue that in court. Just because a recording might be inaccurate is certainly no reason to ban production of said recording. The court system has the means to take that kind of thing into account, the only reason to outright ban recordings is to keep the truth from getting out.
As far as public opinion is concerned, if the recording is modified and defamatory, I believe that would be covered under some branch of libel law.
That's the point, a good engineer's (or scientist's) response to new data that they can't fully explain is generally unmitigated glee, it means they've found something new. My takeaway from the article is, "try this new technique/tool, you'll see new data".
On another note, I've done some very basic analysis of disk performance at work, and this approach would have allowed me to be much more confident in my results. As it was, basically all I could do when comparing disks and filesystems was use iozone to characterize the "knee points" the article keeps mentioning, and try to map changes in aggregate numbers to saturation of various interfaces and/or devices. This method for actually getting sampling data for latency, and potentially from real workloads even, would have been extremely helpful.
Actually yes, the Android platform is a *very* customized Linux, the userspace for it is completely Google's invention, they basically took just the kernel and went from there. And as the other poster mentions, they made quite a lot of changes to the kernel as well. I think it would be fair to say that Android is the most extensive Linux fork to date, though they are at least trying to re-merge the kernel-level stuff.
Distributions such as Red Hat, Debian, etc... make changes around the periphery, but they keep their customizations to a minimal level where you can still build at least somewhat portable applications. Android threw this out completely, if you want to port an application from a Linux-based distribution to Android, you'll have a rather large porting effort ahead of you as the most fundamental system libraries were replaced.
To be clear, I'm not attacking Google here. They seem to be working pretty diligently to try and re-merge at least the kernel stuff. On the other hand, as a Linux developer, I'm not particularly interested in trying to learn their platform for development, I'm far more interested in the phone/portable environments that maintain userspace compatibility with the Linux ecosystem.