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?

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,