Process priority got nothing to do with I/O priority, never mind that the concept of I/O priority as a single number, as it is usually implemented, is broken anyway. Eventually, you're accessing data on a spinning platter, and you're either going to get it on time if you have timing requirements, or you don't care much. No general purpose OS I know of is letting anyone specify this at that sort of granularity.

I don't get that so long as there is resource competition, you can't provide solid time guarantees. Errors are things you can't deal with, so it's a strawman: it becomes outside of OS's control. It's like claiming you can't do it because after all someone can yank the cord out of the socket. I do deal with industrial communication protocols that run on a controlled schedule and in spite of all the resource competition, things that need to happen at certain times do in fact happen that way. This extends all the way to allocation of computational and storage resources at the nodes. The storage resources are in fact scheduled based on queued data requests, so that in spite of bursts of activity, the scheduled transfers happen timely -- meaning that a read may be scheduled ahead of time if by the deadline other things would preclude it from happening. Same goes for scheduling writes, and for cache resources as well. It requires a different mindset when coding applications, but it works wonderfully, and you can keep those hard drives busy.

It used to be that their engine was the only thing that made people switch. When the choices were IE, Netscape and Opera, it didn't take much figuring out to go for Opera. I used to pay for it, it was so good.

Look, it's no longer a web browser's feature if it needs something else besides the client machine it runs on and the web server that serves the content. Opera is providing, essentially, their own ISP infrastructure and bundling access to it into their product. Calling it a web browser is disingenuous. Yes, I am familiar with Opera's bundled email client, so their ISP thing is simply a yet another add-on. But it's not something that a web browser excels at. The rest of the product does that, web browser proper got nothing much to do with it.

Why on earth would you need a web browser to do email?

You live on this cloud nine where standards are complete and leave nothing up for interpretation, and where implementations of the standards are bug-free and introduce no vendor-specific extensions. Alas, in the real world, it's not that way.

It's really better for browsing image galleries, especially over poor connections. Other than that I agree.

Sorry, there no such thing as "excelling" at compression "especially" with Opera Turbo. The browser has zero control over compression, it can request plain old gzip compression from the server, and the server may or may not oblige. That's all that's available without a dedicated server. Opera Turbo is a system where the browser basically hijacks you connection and routes it over an Opera-controlled server. It's that server that then obtains the website content for you and compresses it. It's the only way technically to accomplish that, at the price of essentially giving yourself a man-in-the-middle attack. It's not very funny. The only thing their browser is really excellent at is IIRC browsing porn or generally image galleries with lots of image content. They were excellent at it even in their humble beginning days, where it was ad sponsored free or ad-free paid for -- you basically needed Opera to browse porn over a modem connection on a low-end machine (486DX2 w/Windows 95). With the switch to webkit, they lose whatever technical advantages they might have had.

Sorry, knowing the disk bandwidth is not the whole picture. You also need to know how many hard drive transactions, worst case, do you need for yourself to read the file. Reading the fragmented-as-hell firefox url database can take forever in spite of the file being so small that you'd expect, by hard drive bandwidth alone, to be done with the copy in a 0.1s or so. Unfortunately, most of the "programmers" out there never bother to read up on various APIs exposed by their OS that let them get a list of blocks for a given file -- both Linux and Windows provide that, IIRC. We have "programmers" whose entire idea of what it takes to get data out of a mechanical disk is equivalent to invoking a bunch of C standard library APIs. And they claim that duh well, they never ever needed anything else. Sure, because the idiots don't even know what's out there to begin with -- they don't even know what to look for. This problem could be solved by proper education and, um, evangelism by those who know better. But those who know better often have better things to do than writing articles.

You seem to think that just because you can live in fantasyland things are going to be A-OK. The problem with current virtual memory based OSes is that they let you code like the storage wasn't there, heck, they in fact don't really let you code to account for the storage. For example, you cannot tell the OS to give your application a certain minimum (or maximum) hard drive bandwidth or hard drive transaction rate. Thus when you're running things, the OS doesn't really know that when you're playing media, that file copy operation as well as the background virus scan and filesystem's built-in defragmentation is really an afterthought and should be kept out of the way. That's just but an example. Once you start getting all this impemented properly, you end up with an operating system that has realtime guarantees of various kinds, because that's what it really is all about.

The progress bar is estimating an aspect of the behavior of a very complex system. Remember that the underlying system is not only your software, but all the other running software (OS included), RAM, peripherals such as storage devices and network interfaces, contents of the storage, and network traffic. The behavior of such a system can be at best captured in a stochastic model of some sort. A model, I must add, where a lot of the state variables are not subject to direct observation. What your progress bar can show is then, at best, something close to the expected behavior of the system. Capturing the model of the underlying system to produce a model requires hard core domain specific knowledge in stochastic modeling. It's precisely the stuff that "experienced programmers" proclaim loudly they don't need -- that they can somehow do their job while resorting to essentially high school level maths. I'm sorry, but if you don't even know what's out there when it comes to applied math, then you're in no position to boast about getting through all your programming without ever having to resort to any college-level mathematics.

Almost any decently performing progress bar would need to use some sort of progress monitoring framework. Such a framework would need to constantly capture system performance and estimate the state of the system. When the time comes for your progress-monitored task, your model will be "aware", for example, that there is a disc burn operation that already does 30 hard drive transactions/s, and that a network download into a fragmented filesystem takes another 15 transactions/s. In spite of the hard drive being able to stream 65 megabytes/s, you're IOPS bound and can maybe get 1 megabyte/s for your own use, and won't get more than 10-15 transactions/s. This is just a most basic example of the stuff you'd need to take care of. So, the performance monitoring framework belongs in the kernel, and it's usually there to one extent or another, but you actually have to build a stochastic model that can consume performance data and properly use it. It's nowhere near a trivial problem, and everyone who tries to trivialize it just makes a fool of themselves.

The good old progress bar is perhaps the clearest example of how you can never be a truly good software developer without knowing your math past high school. Yet everyone does it like they were still 16, and you get what you complain about. Real software engineering is hard, and requires lots of knowledge in applied mathematics -- simply because applied mathematics is the only tool we got that can do the job.

Oh no, it's not a stupid idea, it's the perfect plan to shaft the gullible out of the last money they can't afford. The next logical step will be the debtors' prisons, obviously run by private corporations like most of the prisons are. Free labor, right here in the U.S., hardly subject to any labor standards.

I agree, but I don't know what fantasyland do you currently live in where credit card companies are not trying to create economic activity. People wouldn't be able to buy the crap they can't afford if it wasn't for pocketable credit, a.k.a. credit cards. In other words: the credit card companies were creating economic activity almost since day one, by allowing the gullible to buy stuff they can't afford. This hashtag purchase option just further lowers the bar that is already too low. IMHO it'll only be used by the most clueless -- those who are easiest to exploit by the system anyway. The whole idea is basically just to further exploit the underprivileged, as those are the ones vastly most likely to buy stuff they can't afford. It's not even shafting the little people, it's shafting the poorest of the little people. It is monstrous, but it's not new.

Here, you have to explicitly tweet (or retweet) a particular hashtag, and you have to have your card preauthorized. I still think it's a bit risky of a proposition, but at least it's trivial not to opt-in. What will happen is that the "particular hashtag", or rather "costly hashtag" space will become polluted, and the negative outcomes of this feature will get so much public outcry that it'll get dropped quickly -- or so one hopes.

Alas, I had to double check the calendar, I thought it was April 1st already...

My experience with core i7 Optiplex machines running Windows 7 and CAD systems is excellent. Those systems really fly, even compared to, say, Core 2 Duo (my laptop). A Libreoffice install takes easily 5x less time than on good P4 systems we had before. I'd be very hesitant to proclaim that an i7 will not keep up with hardware from a decade ago...

And how much power does it take to make a complete new machine? Part of the price of a new system is the cost of power needed to make all the parts :)