In fact, there are very good reasons to have both Firewire and USB on the same machine
Absolutely. In fact, I'm actively using both on my laptop as I write this. As I just explained to another respondent, I was trying to make a different point involving Fibre Channel, not FireWire.
I don't think anyone is serious trying to suggest that USB and Fibre Channel are competing standards. Prehaps you meant Firewire?
No, I meant FC. I wanted to make the point that the differences between some of these five new technologies are quite subtle, and I wanted to highlight that subtlety by contrasting it with a difference that was extremely un-subtle, so I picked two technologies that are about as obviously different as they could be while still being in the same general category. I guess this sort of "meta-contrast" is hard to convey clearly.
You've got multiple standards that are totally incompatible with each other
But they don't all do the same things. Yes, there is some overlap, and it would be a great surprise if all five survived, but it's not hard to imagine a system that used HyperTransport or RapidIO chip-to-chip, PCI-X or 3GIO as an internal bus, and InfiniBand for SAN/clustering.
and yet neither of them has any true advantage over the other
Oh, but they do. They all have different latency/throughput balances, different levels of coherency and parallelism and switchability, and different backwards-compatibility stories. The differences are more subtle than, say, USB vs. FC, but they do exist.
Re:i'm going to suffer for this but...
on
KDE Wins 3 awards
·
· Score: 2
Behaviour of Windows drag and drop depends on whether the destinatio nand source are on the same partition, a new partition, or a shell folder, and what type of application is being dragged. KDE simply asks me when i drop it - copy, move, or link?
That's because drop targets (I always forget which one's the "client" and which one's the "server" in MS terminology) have been given the flexibility to decide what the default behavior would be. Flexibility is usually considered a good thing, even if some programmers abuse it. In any case, and as another poster already pointed out, you can always right-drag to get a context menu similar to what KDE has. Again, you have flexibility - to accept the default action or choose which action you want. Personally I always right-drag but that might not suit everyone; it would be distinctly annoying to have to go through yet another dialog every time you use drag and drop, when you know that you want the default.
Drag a file to the desktop and it has the brains to suggest I'd like to make that file my wallpaper.
That would be a terrible idea, as a default. If I drag a document to the desktop, I expect an icon on the desktop, not a whole new background...regardless of document type. I think most users probably share that expectation, and would be pretty pissed off to get the behavior you describe.
Linux web browsers often have some very useful features their windows counterparts don't
Obviously, by "windows counterparts" you mean IE. There are other browsers that run on Windows that are just as featureful in the ways you mention as anything that runs on Linux.
The old format was 24 blades in a 3U chassis, which works out to 336 blades per standard 42U rack. The new format is 6 blades per 1U chassis, which works out to 252 blades per rack. Maybe it's a more appealing form factor, but it's not denser.
Anti-trust legislation is about protecting consumers, not competitors.
Actually, anti-trust legislation is based on the assumption that the two are equivalent, i.e. that competition results in lower prices, better quality, technical innovation, etc. There's other legislation that protects consumers in other ways (e.g. safety or environmental regs) but anti-trust legislation is quite specifically intended to help consumers by enabling more companies to participate in a market.
Your argument about protecting consumers (citizens) rather than competitors (corporations) would be exactly correct with regard to an attorney general's role, but it's slightly off with regard to the intent of anti-trust laws.
Also, wouldn't having files located on a server away from the PDA require wireless access to get to them?
Not necessarily. How much data are you really likely to use on a handheld/notebook between the time you leave your network "coverage area" and the time you return? All of your applications, contact/to-do/schedule data, and frequently accessed documents will fit easily into solid-state memory, obviating any need for either disks or network storage for them. How many tens of gigabytes' worth of images, sound files, and reference books do you *need* to have instantly accessible between the time you leave the network and the time you rejoin?
The obsession with keeping such large data stores local is similar to the obsession with SUVs. People like to envision themselves as the sort who might need to take a vehicle off-road, even though 99% of SUVs *never* see such usage. Similarly, people like to envision themselves as needing tens of gigabytes of data anywhere, even though they're mostly office workers or college students who never stray very far from their nearest network connection - and connectivity is only going to improve. Five years from now you'll need to go pretty far off the beaten track to be off-network.
For people who must have mobile access to such large datasets without network connectivity, I'm sure there will always be disks available as expansion cards or separate units connected via comm ports on handhelds/notebooks. But those people aren't likely to be a majority for much longer. For *most* people, who already do have network connectivity almost all the time, network storage is likely to be a preferable solution requiring fewer power/reliability/weight/noise tradeoffs. Making everyone carry the design baggage to support a function only needed by a few users is a classic mistake, and one I'd rather avoid when designing my own "ideal" system.
You're basically confusing two concepts here: handheld and notebook. The requirements are different. A notebook should be very nearly equivalent functionally to a middling or slightly wimpy desktop, with weight measured in pounds and battery life in hours. A handheld needs to be much more extremely portable, with weight in ounces and battery life in weeks. The portability/power requirements basically dictate that a certain amount of desktop-equivalent functionality be sacrificed. That said, here are some of my ideas about what would be truly ideal for each, starting with the notebook (which more closely matches your description):
Size and display: A4 is a good display size, but a little too big for easy transportation when not in use. Fortunately, with a flexible medium such as LEP you could have both. Basically the screen could be like those portable projection screens that you roll up when not in use.
Power: solar might be nice, but you're typically not going to get that much out of it. Instead of a battery, though, use tiny methane fuel cells.
Processor: something like a Transmeta would be a good fit.
Connectivity: putting USB (including, I presume, USB2) and Firewire and Bluetooth and 802.11b (what about 802.11a) makes the base system too complex. Put one low-end (USB1) and one high-end (Firewire) interconnect on board, then provide four or more PCMCIA/CF slots so the user can customize the rest to suit their needs.
For the true handheld, things look a little different:
Size and display: it needs to be smaller (more portable) than today's handhelds, not larger, and the display needs to be instantly accessible without unrolling a screen. E-Ink is a good fit here, especially because it would be nice to have your agenda or to-do list still visible at a glance even while consuming zero power. The limit on screen resolution is the combination of the unit's physical size and the human eye; the dots can only be so small, so only so many of them can fit. I'd say that anything more than 320x320 is pushing the boundaries of usefulness.
Power: solar is definitely not going to get you anywhere. Fortunately, those methane fuel cells are small enough even for a PDA.
Processor: even a Crusoe might suck too much juice. I'd go with a super-low-power asynchronous-logic chip.
Connectivity: very limited options here. There's room for one CF card, but not two. The best hope is that they'll be able to fit connectivity logic onto something more like MMC so you can have more than one expansion slot.
One could well argue that we should be getting away from the idea of "handhelds" anyway. Maybe we should be thinking more in terms of an eyeglass-mounted virtual display (pick a resolution and color depth) connected via short-range wireless to a belt- or shoe-mounted CPU unit.
The one thing I haven't really talked about is storage. That's because I have some definitely "out there" views on that subject. Basically I don't think there's going to be a reason to have a lot of permanent storage in the user-facing device. Instead, the storage will be in the network - encrypted, fully distributed, accessed securely via our ever-improving network connectivity options. Sure, there'd be local storage, but only enough to boot and to serve as a cache of the data which still "lives" in the network. A modest amount of FMRAM should be entirely sufficient, with no need for rotating media and the costs - power, noise, mechanical fragility - associated with them. Maybe if you wanted to take your PDA to Antarctica you'd need something different, but before long the distributed-storage model should work anywhere in the civilized world.
Yes, I know some people hate the idea of data-less devices. Generally this is for one of several outdated reasons:
Diskless workstations were deployed at a time in the past when the network technology was really not adequate to support the same user experience that you'd get with a local disk.
To make things worse, a lot of diskless-workstation deployments were horribly underprovisioned, with insufficient servers and switching infrastructure.
Diskless operation used to imply ceding control of your data (and access to it) to someone else. With modern distributed-system technology that no longer needs to be the case; you can store your data on someone else's hardware, and access it via a third party's communications infrastructure, without giving up any control or privacy.
In short, none of these objections really apply any more. With the right technology and the right SLAs in place, there'd be no compelling reason to have a local disk.
The fatal flaw with MDI is the nesting of window management. This is often not desirable.
Often. Often, not always, and because it's often not desirable, or because you personally don't find it desirable, you don't want anyone to have the option? The whole point of what I was suggesting was to give choices back to the user. If you personally don't like MDI, don't use it; just set up your preference so SDI is used throughout your environment. Problem solved.
If you find yourself wanting MDI it's probably because your main window manager is not very usable (but may look pretty, eh;)
Au contraire. I use icewm on Linux because it's pretty much the most minimal (but still functional) window manager I could find. What eye-candy-laden window manager do you use?
The fact that MSDEV forces you to have all your windows in a single huge (99% of the time maximized) window just sucks IMO.
Yes, it sucks, but not because it's MDI; it sucks because it takes a choice away from the user. As you might have noticed if you had read the rest of the comments on this thread, some people actually like MDI. Do their preferences not count, should they be ignored because you're more "elite" than they are? I don't think so. They should have that choice, and the way to let them have that choice is to improve the way that applications and window managers interact.
keep in mind that you started by comparing win linux docs etc. so the fact that linux is not ideal (and of course it is not) does not prove anything - just continue comparing to windows (you suddenly forgot all about that part of your original post)
No, I didn't forget it. I thought that point had already been made, and I don't like repeating myself. I forgot how dense some people around here can be, or how their attention spans are so short that they forget anything not waved in front of their face in the last five minutes.
there is NO comparable info (publicly accessbile) on windows.
That is a lie. I do both Windows and NT kernel development. I have one book on NT filesystems and two on drivers, all of which are better written and more informative than their Linux counterparts and all of which are available for anyone to buy at a decent technical bookstore. Just because you haven't looked for it doesn't mean it doesn't exist.
In short, piss off. You obviously don't know what you're talking about, and don't care that you don't know. I'm usually a Linux advocate, but I hate FUD even when it's "good guy" FUD.
there is plenty of docs for linux (and linux in general) - books, internet, everywhere...
Yeah, right. Where's the book on developing filesystems for Linux? There isn't one. It's only very recently that books on driver development were available. OK, no book...where's the design spec for the VFS layer or the VM subsystem? Guess what? Again, no such thing. There is no actual documentation in these areas, just the code and word of mouth, and if you think reading the code for something like a VM subsystem is a reasonable substitute for adequate documentation, feel free to go try it.
you can talk to kernel developers directly (and they generally have no NDAs)
Yeah, fat lot of good that will do you with some of the people involved. As I said in my previous post, for example, good luck getting anything but obscenities out of Al Viro when you ask questions. It should come as no surprise that the same people who fail to document their code often aren't very good about answering questions either. Other kernel developers have been pounding on Andrea Arcangeli for a month now, trying without success to get answers about his VM subsystem. Sadly, that's par for the course. If you have an obvious question you can often find an answer, but stray one foot off the beaten path and you're likely to get diddly-squat.
just notice how many OSs have linux binary compatibility
That proves nothing. The syscall ABI is one of the simplest interfaces around, and is a pretty straightforward implementation of what those systems pretty much already had. That falls squarely into the category of "obvious questions".
as far as non-file system namespace: not sure what you mean, in linux everything is file. but not everything has to be physical file on the disc
Yes, yes, I know, did I mention that I've spent the last decade writing kernel code for a living, mostly on (in) various flavors of UNIX? The point is that even though these things aren't files on disk they're still files in the sense of being kernel-visible entities with associated vnodes etc....but that means there's a lot more kernel code involved than there needs to be. In general, the less kernel code people have to write the better it is for everybody...and, remember, I'm saying that as a kernel developer myself. As soon as you start putting stuff into the kernel that belongs in user space, you're drastically magnifying the effect of any bugs in the code (i.e. crash) without adding any functionality. Making the kernel the only namespace manager in the system only results in a lot of incompetent boobs writing kernel code when they have no business doing so, and a lot of users' systems crashing as a result.
The ideal interface, in my opinion, would be to support nesting of window managers within other window managers and/or within applications. The biggest problem with MDI is that every MDI application basically acts as its own window manager. Usually this "embedded window manager" is a really crappy one, which turn people off to MDI in general, but there are exceptions; my preferred browser and text editor both use tabbed document windows to very good effect. It would be cool if we could tell applications what window manager instance (WMI) to use, so that the app can delegate window management to the WMI of the user's choice. Want SDI? Tell the app to plop its subwindows into the same WMI as the parent window. Want MDI? Tell the app to plop its subwindows into a WMI ("using *this* window manager, please") embedded within the parent window. You could use the same interface to switch between a Mac-style single menu bar and Windows-style per-window menu bars. All of this could go into a fairly simple config file, allowing users to choose whatever combinations of overlapping/tabbed, MDI/SDI, Mac/Windows styles - including hybrids and mixed modes - that they want.
How do I get access to this information? Sorry, what's that? I have to fly to Redmond, get body searched, sign an NDA in blood?
Oh, poppycock. Yes, Microsoft has some hidden interfaces, but most of the important interfaces are way more accessible under Windows than under (for example) Linux. There's tons of information in MSDN that goes way beyond any documentation that's available for most open-source projects. Want to use VBA to write scripts that add functionality to Word/Excel, or use them a data source? Plenty of information available. Want to do the same for any of the open-source word processors or spreadsheets? Good luck. Want to write an Explorer shell extension to expose a new (non-filesystem) namespace? Plenty of information available. Want to do the same on Linux? Yeah right; Linux doesn't even have a concept of non-filesystem namespaces[1]. Want to write a filesystem for Windows? There've been whole books published on the subject - and more books on generic driver development - for all flavors of Windows, for years. Want to write a filesystem for Linux? Good luck finding any documentation for the interfaces you'll use, and good luck getting anything but obsecenities out of Al Viro (primary designer of the piece of crap that is the Linux VFS layer) when you ask questions. Oh yeah, you'll have to get intimately involved in the revolving-VM-system mess too, because of the way filesystems interact with the VM system.
Yeah, sure, MSDN costs money, and there are some glaring omissions in what it covers, and it can be a real bitch to find the information you need when it's hidden in the knowledge base or something. Overall, though, MS provides very good documentation, and they even provide a huge mass of source code including the actual source for just about every driver they've written. I wish as much useful information were available for Linux.
[1] This is a serious matter. One of the worst things about Windows is the way that the architecture has historically forced a lot of people to implement stuff as drivers because there was no way to do what they needed to do in user space. This has resulted in a lot of driver code written by crappy programmers, and is about 90% of the reason Windows is so unstable. The code written by Microsoft themselves stability-wise, although they still share some responsibility for every crash even if it's proximately caused by someone else's code. The lack of non-filesystem namespace handling in Linux is an example of Linus et al making the same inexcusable mistake.
What evidence can you present that supports your conclusion that Andrea did not expend effort in debugging Rik's VM component?
I never claimed that, nor is it relevant, so I don't need such evidence. Andrea did in fact spend considerable time helping debug RVM problems, but obviously at some point gave up and decided to undermine that ongoing effort instead.
don't you think it would have been more difficult to determine the more stable VM with unstable code being tested at the same time?
Odd-second-number kernel series aren't so unstable that it would be impossible to distinguish VM-related problems from other problems.
I know you think its better to lose "by the book", but real world managers would grasp at the straw
"The book" is written the way it is because - in general - the odds of failure are lower when you do things by the book. Real managers who have a clue know that. "Grasping at straws" is bad practice. The folks at SEI will tell you that the primary hallmark of a mature software-development model is that it produces repeatable results (and, at the higher levels, information that can be used to improve the process further. Sometimes you have to pick the best of several bad alternatives, but that should still be done according to proven risk-management principles instead of "grasping at straws".
I don't believe this decision "calls the whole open-source development model into question".
Linux development is often held up as a model of how well open-source development can work. If AVM had proven to be less stable than RVM - and there was, at the time, practically no reason to believe otherwise - and the resulting instability in 2.4 were also associated with an obvious case of bad process management, that most certainly would reflect on open-source development models. I can see it now. "Open source development is fragile, it's vulnerable to the whims of untrained project leaders who make decisions based on politics rather than technical merit..." and so on. You can't seriously believe such polemics would not be written in such a situation, can you?
"Stands on principle" and "good precedents" sound rather ideological and they don't benefit you if you're "dead".
See previous about why the book is written the way it is; the whole point of the book is to reduce the chances of ending up "dead". Try to put yourself in Linus's shoes, at the time the decision was made. You have two choices:
You can keep going with a well documented and well tested VM system that has been making steady progress, even if some problems - including some fairly serious ones - still exist and some of its principles are well understood only by a few people.
You can accept a patch that implements a whole new VM system that's totally undocumented, that *nobody* except the author understands, and that's very lightly tested so you have no real idea whether it's stable.
Can you seriously suggest that #2 was the responsible choice, most likely to lead to success? I don't think so. Linus made the decision based almost entirely on his personal feelings about the people involved, a lapse of technical objectivity which any "real manager" knows often leads to disaster. Whether disaster actually occurs in the here-and-now is irrelevant; such behavior should be discouraged in the strongest terms by anyone who cares about the future of Linux.
If you implement a VM that way, launching a program takes a very long time.
And it's better to load the whole thing? Um...hello? Anybody in there? Sure, you can save some latency by transferring the data in large chunks instead of individual pages, but you make up for that in wasted transfer time. Then you have to consider the effect of filling up the cache with pages you actually turn out not to need, evicting other pages you do need to make room for them. Overall, it's a big loss.
Most operating systems today load most or all of a program at startup
Bullshit.
Much of the memory-demanding things servers do look like short-lived programs.
Bullshit again. Maybe it's true for web servers, though with mod_perl and such out there I have my doubts. It's definitely not true for most other common/interesting workloads.
the memory usage behavior for most programs has changed considerably, but we're still using virtual memory concepts that were developed in the 1960 and mature by 1980.
Three strikes, you're out. I was there in 1980, in fact I was working on one of the earliest SMP VM systems (UMAX, at Encore). Things have changed a lot since then.
And remember, even when everything works right, you get the effect of at best 2X the memory.
Hm. Four strikes? The 2X figure is a Linux 2.2-specific red herring. Many systems can make effective use of more under many workloads.
Before anyone else points it out, that should be 245. I don't know how that period got in there; I guess it's something I should watch out for when I post at 3am. In any case, this just means that the previous poster was off by three orders of magnitude rather than four. Congratulations.:-P
Why do you think that Andrea did not make an honest effort to help fix RVM bugs?
Obviously the only authoritative answer would have to come from Andrea, but my guess can mostly be expressed in one word: ego. He thought his fundamental ideas were better than Rik's.
I think (and I can be dead wrong here) Andrea (as did at least Linus) took a good look at Rik's RVM, and saw 2.5 being started a year from now because of time needed to fix a "complex" RVM.
No matter how long it might have taken to fix RVM in 2.4, that's no excuse for 2.5 not being open. All of the flip-flopping should have taken place in 2.5, and if AVM turned out to be the "winner" in that environment it could have been back-ported to 2.4 if necessary.
Except if more (talented) developers can understand the unknown (AVM) devil, but not the better known devil.
That gets a little harder when AVM - and in particular its features that diverge from 2.2 - is almost totally undocumented. Many of the kernel developers have complained bitterly about this fact.
Was Linus better off standing pat?
Yes. The best and average cases were comparable, and the worst case for standing pat was better as it didn't involve calling the whole open-source development model into question. Perhaps even more importantly, taking a stand on principle would have set a good precedent and example for the future.
The saddest thing here is that such garbage got modded up as "informative" instead of being modded down into oblivion for being "uninformed".
It's not that expensive to double the size of RAM today. It can be cheaper than adding a fast disk drive just for paging.
Even with RAM at US$0.25/MB or less, that's still untrue. A top of the line hard disk is under a penny per megabyte, which represents a pretty significant difference.
disks still top out around 10,000 RPM, making main memory 300,000 times faster than backing store
Where the hell do you get 300K from? Picking the first drive I see at an online store I see an average seek time of 4.9ms (RPM is totally irrelevant). 4.9ms/0.02ms = 24.5, not 300K. Yeah, yeah, you have to factor in transfer times as well, but 300K is still way out of line.
On a server which is processing short transactions, you're much better off throttling at the transaction launch point
Not all workloads are characterized as short, independent, stateless operations. Yes, there are applications out there that aren't webservers, and they deserve to be well supported by the OS as well.
The main value of VM today is getting rid of dead code at run-time.
Bullshit. But I see others have already addressed that.
I'd argue that it's time to go back to a swapping model - all of an app has to be in before it runs.
So, because the mismatch between RAM and disk access times is so great, it's better to move all of a process's address from RAM to disk and back again instead of just part? Riiiiight.
As someone else said, please take an OS class. While you're at it, read Hennessy and Patterson. You seem to be missing a lot of information about how computers actually work at both the hardware and software levels.
There are some philosphical arguments over whether killing processes is the best way of handling an Out Of Memory situation, but it is surely better than deadlocking the box, which is what most VM systems (including the famed FreeBSD's) do when OOM occurs.
Untrue. Simply untrue. Most VM systems will slow down, some gracefully and some not, but they will not deadlock.
It's also more than a philosophical issue, BTW; it's a very real-life practical issue. The whole idea of killing a process - any process - completely and irretrievably because the system is low on memory is simply brain-dead. Better solutions might involve working-set limits, emergency reserves (similar to what's already done for disk space in some filesystems), disallowing memory overcommit, long-term suspension of processes so their pages can be stolen, etc. - the possibilities are nearly endless. The OOM-killer approach always carries the possibility of leaving the system truly deadlocked as one member of a temporal-dependency chain - perhaps spanning multiple machines - gets shot in the head. You'll have plenty of memory, but it won't be doing you any good as you're deadlocked nonetheless. There is no problem that the OOM killer solves that is not solved better by a different approach.
There is no development kernel branch to test things out on right now
And whose fault is that? Who has unilaterally refused to open a 2.5 branch even though there clearly should have been one months ago? The lack of a 2.5 branch is a major piece of what's wrong, and it can be laid at exactly one person's clay feet.
are you saying its preferable for new Linux development to be shutdown for another 6 months to a year?
No, there have been quite enough delays associated with 2.3/2.4 already. More than enough. And there will continue to be delays until the processes get ironed out.
What would have been preferable, IMO, would have been if more resources had been devoted to fixing and tuning the VM we already had (RVM, for good or ill). Linus could have put his foot down. He could have said "There will be no 2.4 VM except for RVM. The price for admission to the next round of VM redesign is that you help us fix RVM." People - notably Andrea - would have listened, and contributed more constructively. They know that Linus's good will is like currency. But Linus didn't say that. Alan Cox pretty much has, and kudos to him for having the courage to do so. What Linus did was take a bad situation and act in a way that nine times out of ten would make it worse. Maybe he'll get away with it this time because AVM in its current state is more robust than RVM in its current state, but that would actually be a bad thing because it will only reinforce the bad decision-making and we'll get burned next time instead of this time.
And Zdnet to opine on how the "stable" 2.4 kernel is DEMONSTRABLY unreliable?
First off, are good reviews from places like ZDnet the goal for Linux development? Second, do you think it's better for the stable 2.4 kernel to be subtly, unpredictably unreliable? Better the devil you know, and all that.
Most importantly, what if Linus's gamble - and that's what it was - hadn't succeeded? What would the ZDnet reviews be like then? What kind of ammo would that provide for everyone who wanted to claim that open-source development processes weren't all they're cracked up to be? Yeah, it looks (so far, knock wood) like we've been lucky this time, but I don't think relying on luck is a good thing.
I'll take a "manager" that makes mistakes and makes decisions based on product survival over a manager that religiously follows an engineering practices manual.
The two aren't as diametrically opposed as you make them out to be. Good engineering practices are good because they help increase either the speed or the reliability with which product can be delivered. Slavish adherence to any dogma is a bad thing, but so is the belief that everything you're doing is OK just because you managed to win one game of chicken. My point is that this scenario is going to be repeated. I'd rather encourage responsible driving than watch what happens when Linus plays one game of chicken too many and brings everyone else along for the ride.
FWIW, I think that Andrea's setup is modeled after the 2.2 VM
Yes, mostly. Except for the classzone stuff.
We all know this simplistic setup had scalability problems (like much of 2.2) but at least it worked right. Hopefully given some more time, Rik can really get his to go, since it seems more sophisticated/scalable long-term.
Absolutely. I'd love to see Rik and Andrea (and others?) competing on purely technical merit, in the 2.5 tree. I think that would be great for everyone.
I did read the whole thing, asshole. Why would you think otherwise? Because I didn't respond to every other point you made? Ridiculous! Don't try to act all aggrieved, as though your comment was taken out of context; it was absurd regardless of context - even in a context where I agreed with the rest of what you were saying. Context is not the issue here. The issue here is the way that you, in your classic "I teach at MIT" arrogance, have refused to accept that anything you say could have been in error even when the error is waved in front of your face. I pity your students.
IMO both Rik's code (RVM) and Andrea's (AVM) were accepted prematurely, and Linus's ADD is the root of the problem here. Everyone thought the 2.2 VM was broken, so he jumped on RVM when it really hadn't received adequate testing with various workloads. Then, when that didn't work out, he did something even worse by jumping on AVM in the middle of a "stable" kernel series when it was totally undocumented and even less thoroughly tested than RVM. That's just bad software engineering, regardless of the quality of Rik's or Andrea's work.
Ideally, an "old-fashioned" alternative to RVM would have been maintained throughout the 2.3 process, as a fallback in case RVM turned out not to be ready for 2.4 - which was in fact the case. But this wasn't done, there was no alternative, and so RVM became the basis for 2.4. Once that decision was made it should not have been unmade by replacing RVM with AVM. Andrea's work should have been in the 2.5 tree, which should have been opened a long time ago to deal with precisely this sort of situation. 2.4 is not the last Linux kernel that will ever exist. We don't need to make it perfect. It would be far better to admit its imperfections, band-aid them as best we can, and try to get a head start on creating something better for 2.6. What we have instead is error on top of error, "not ready" replaced with "even less ready".
To clarify, I have nothing but the highest regard for both Rik's and Andrea's work. Obviously they have different ideas and attitudes. Rik has drawn on many sources in his design, resulting in a system that is both very advanced and very complicated. The process of reining in the complexity is still incomplete, but I still have hope that some day Rik will be able to come up with something that's really awesome, and he has always documented his ideas thoroughly. Andrea, by contrast, is much more pragmatic; he wants something that works now even if it's somewhat more limited in scope (e.g. by being almost impossible to reconcile with NUMA). The dark side of that "pragmatism" is that Andrea has skimped on non-code activities such as documenting or explaining the basic ideas on which his system is based. Nonetheless, both have done great work and should continue to do great work...in the 2.5 tree.
Why not let the 2 VM's compete and the users will decide?
There was an interesting thread on this a while back, rooted at this comment. Unfortunately, the article's old enough that it's only available as a static page, and the oh-so-wonderful Slashdot code that generated the page seems to've done so with the comments in basically random order, so it's almost impossible to follow the thread. Maybe I'll try to recreate its original structure and put the result on my website.
In brief, I think it's a great idea. Competition is good; let individuals and teams compete on the basis of the quality of their work, and bless the "winner" as part of the official tree. The "loser" is always free to try again in the next round. The only problem is that this all should have occurred in the 2.3.xx and/or 2.5.xx series; 2.4.xx should not be changing horses in midstream.
Slashdot Mirror
Absolutely. In fact, I'm actively using both on my laptop as I write this. As I just explained to another respondent, I was trying to make a different point involving Fibre Channel, not FireWire.
No, I meant FC. I wanted to make the point that the differences between some of these five new technologies are quite subtle, and I wanted to highlight that subtlety by contrasting it with a difference that was extremely un-subtle, so I picked two technologies that are about as obviously different as they could be while still being in the same general category. I guess this sort of "meta-contrast" is hard to convey clearly.
But they don't all do the same things. Yes, there is some overlap, and it would be a great surprise if all five survived, but it's not hard to imagine a system that used HyperTransport or RapidIO chip-to-chip, PCI-X or 3GIO as an internal bus, and InfiniBand for SAN/clustering.
Oh, but they do. They all have different latency/throughput balances, different levels of coherency and parallelism and switchability, and different backwards-compatibility stories. The differences are more subtle than, say, USB vs. FC, but they do exist.
That's because drop targets (I always forget which one's the "client" and which one's the "server" in MS terminology) have been given the flexibility to decide what the default behavior would be. Flexibility is usually considered a good thing, even if some programmers abuse it. In any case, and as another poster already pointed out, you can always right-drag to get a context menu similar to what KDE has. Again, you have flexibility - to accept the default action or choose which action you want. Personally I always right-drag but that might not suit everyone; it would be distinctly annoying to have to go through yet another dialog every time you use drag and drop, when you know that you want the default.
That would be a terrible idea, as a default. If I drag a document to the desktop, I expect an icon on the desktop, not a whole new background...regardless of document type. I think most users probably share that expectation, and would be pretty pissed off to get the behavior you describe.
Obviously, by "windows counterparts" you mean IE. There are other browsers that run on Windows that are just as featureful in the ways you mention as anything that runs on Linux.
The old format was 24 blades in a 3U chassis, which works out to 336 blades per standard 42U rack. The new format is 6 blades per 1U chassis, which works out to 252 blades per rack. Maybe it's a more appealing form factor, but it's not denser.
Actually, anti-trust legislation is based on the assumption that the two are equivalent, i.e. that competition results in lower prices, better quality, technical innovation, etc. There's other legislation that protects consumers in other ways (e.g. safety or environmental regs) but anti-trust legislation is quite specifically intended to help consumers by enabling more companies to participate in a market.
Your argument about protecting consumers (citizens) rather than competitors (corporations) would be exactly correct with regard to an attorney general's role, but it's slightly off with regard to the intent of anti-trust laws.
Not necessarily. How much data are you really likely to use on a handheld/notebook between the time you leave your network "coverage area" and the time you return? All of your applications, contact/to-do/schedule data, and frequently accessed documents will fit easily into solid-state memory, obviating any need for either disks or network storage for them. How many tens of gigabytes' worth of images, sound files, and reference books do you *need* to have instantly accessible between the time you leave the network and the time you rejoin?
The obsession with keeping such large data stores local is similar to the obsession with SUVs. People like to envision themselves as the sort who might need to take a vehicle off-road, even though 99% of SUVs *never* see such usage. Similarly, people like to envision themselves as needing tens of gigabytes of data anywhere, even though they're mostly office workers or college students who never stray very far from their nearest network connection - and connectivity is only going to improve. Five years from now you'll need to go pretty far off the beaten track to be off-network.
For people who must have mobile access to such large datasets without network connectivity, I'm sure there will always be disks available as expansion cards or separate units connected via comm ports on handhelds/notebooks. But those people aren't likely to be a majority for much longer. For *most* people, who already do have network connectivity almost all the time, network storage is likely to be a preferable solution requiring fewer power/reliability/weight/noise tradeoffs. Making everyone carry the design baggage to support a function only needed by a few users is a classic mistake, and one I'd rather avoid when designing my own "ideal" system.
You're basically confusing two concepts here: handheld and notebook. The requirements are different. A notebook should be very nearly equivalent functionally to a middling or slightly wimpy desktop, with weight measured in pounds and battery life in hours. A handheld needs to be much more extremely portable, with weight in ounces and battery life in weeks. The portability/power requirements basically dictate that a certain amount of desktop-equivalent functionality be sacrificed. That said, here are some of my ideas about what would be truly ideal for each, starting with the notebook (which more closely matches your description):
For the true handheld, things look a little different:
One could well argue that we should be getting away from the idea of "handhelds" anyway. Maybe we should be thinking more in terms of an eyeglass-mounted virtual display (pick a resolution and color depth) connected via short-range wireless to a belt- or shoe-mounted CPU unit.
The one thing I haven't really talked about is storage. That's because I have some definitely "out there" views on that subject. Basically I don't think there's going to be a reason to have a lot of permanent storage in the user-facing device. Instead, the storage will be in the network - encrypted, fully distributed, accessed securely via our ever-improving network connectivity options. Sure, there'd be local storage, but only enough to boot and to serve as a cache of the data which still "lives" in the network. A modest amount of FMRAM should be entirely sufficient, with no need for rotating media and the costs - power, noise, mechanical fragility - associated with them. Maybe if you wanted to take your PDA to Antarctica you'd need something different, but before long the distributed-storage model should work anywhere in the civilized world.
Yes, I know some people hate the idea of data-less devices. Generally this is for one of several outdated reasons:
In short, none of these objections really apply any more. With the right technology and the right SLAs in place, there'd be no compelling reason to have a local disk.
Often. Often, not always, and because it's often not desirable, or because you personally don't find it desirable, you don't want anyone to have the option? The whole point of what I was suggesting was to give choices back to the user. If you personally don't like MDI, don't use it; just set up your preference so SDI is used throughout your environment. Problem solved.
Au contraire. I use icewm on Linux because it's pretty much the most minimal (but still functional) window manager I could find. What eye-candy-laden window manager do you use?
Yes, it sucks, but not because it's MDI; it sucks because it takes a choice away from the user. As you might have noticed if you had read the rest of the comments on this thread, some people actually like MDI. Do their preferences not count, should they be ignored because you're more "elite" than they are? I don't think so. They should have that choice, and the way to let them have that choice is to improve the way that applications and window managers interact.
No, I didn't forget it. I thought that point had already been made, and I don't like repeating myself. I forgot how dense some people around here can be, or how their attention spans are so short that they forget anything not waved in front of their face in the last five minutes.
That is a lie. I do both Windows and NT kernel development. I have one book on NT filesystems and two on drivers, all of which are better written and more informative than their Linux counterparts and all of which are available for anyone to buy at a decent technical bookstore. Just because you haven't looked for it doesn't mean it doesn't exist.
In short, piss off. You obviously don't know what you're talking about, and don't care that you don't know. I'm usually a Linux advocate, but I hate FUD even when it's "good guy" FUD.
Yeah, right. Where's the book on developing filesystems for Linux? There isn't one. It's only very recently that books on driver development were available. OK, no book...where's the design spec for the VFS layer or the VM subsystem? Guess what? Again, no such thing. There is no actual documentation in these areas, just the code and word of mouth, and if you think reading the code for something like a VM subsystem is a reasonable substitute for adequate documentation, feel free to go try it.
Yeah, fat lot of good that will do you with some of the people involved. As I said in my previous post, for example, good luck getting anything but obscenities out of Al Viro when you ask questions. It should come as no surprise that the same people who fail to document their code often aren't very good about answering questions either. Other kernel developers have been pounding on Andrea Arcangeli for a month now, trying without success to get answers about his VM subsystem. Sadly, that's par for the course. If you have an obvious question you can often find an answer, but stray one foot off the beaten path and you're likely to get diddly-squat.
That proves nothing. The syscall ABI is one of the simplest interfaces around, and is a pretty straightforward implementation of what those systems pretty much already had. That falls squarely into the category of "obvious questions".
Yes, yes, I know, did I mention that I've spent the last decade writing kernel code for a living, mostly on (in) various flavors of UNIX? The point is that even though these things aren't files on disk they're still files in the sense of being kernel-visible entities with associated vnodes etc....but that means there's a lot more kernel code involved than there needs to be. In general, the less kernel code people have to write the better it is for everybody...and, remember, I'm saying that as a kernel developer myself. As soon as you start putting stuff into the kernel that belongs in user space, you're drastically magnifying the effect of any bugs in the code (i.e. crash) without adding any functionality. Making the kernel the only namespace manager in the system only results in a lot of incompetent boobs writing kernel code when they have no business doing so, and a lot of users' systems crashing as a result.
The ideal interface, in my opinion, would be to support nesting of window managers within other window managers and/or within applications. The biggest problem with MDI is that every MDI application basically acts as its own window manager. Usually this "embedded window manager" is a really crappy one, which turn people off to MDI in general, but there are exceptions; my preferred browser and text editor both use tabbed document windows to very good effect. It would be cool if we could tell applications what window manager instance (WMI) to use, so that the app can delegate window management to the WMI of the user's choice. Want SDI? Tell the app to plop its subwindows into the same WMI as the parent window. Want MDI? Tell the app to plop its subwindows into a WMI ("using *this* window manager, please") embedded within the parent window. You could use the same interface to switch between a Mac-style single menu bar and Windows-style per-window menu bars. All of this could go into a fairly simple config file, allowing users to choose whatever combinations of overlapping/tabbed, MDI/SDI, Mac/Windows styles - including hybrids and mixed modes - that they want.
Oh, poppycock. Yes, Microsoft has some hidden interfaces, but most of the important interfaces are way more accessible under Windows than under (for example) Linux. There's tons of information in MSDN that goes way beyond any documentation that's available for most open-source projects. Want to use VBA to write scripts that add functionality to Word/Excel, or use them a data source? Plenty of information available. Want to do the same for any of the open-source word processors or spreadsheets? Good luck. Want to write an Explorer shell extension to expose a new (non-filesystem) namespace? Plenty of information available. Want to do the same on Linux? Yeah right; Linux doesn't even have a concept of non-filesystem namespaces[1]. Want to write a filesystem for Windows? There've been whole books published on the subject - and more books on generic driver development - for all flavors of Windows, for years. Want to write a filesystem for Linux? Good luck finding any documentation for the interfaces you'll use, and good luck getting anything but obsecenities out of Al Viro (primary designer of the piece of crap that is the Linux VFS layer) when you ask questions. Oh yeah, you'll have to get intimately involved in the revolving-VM-system mess too, because of the way filesystems interact with the VM system.
Yeah, sure, MSDN costs money, and there are some glaring omissions in what it covers, and it can be a real bitch to find the information you need when it's hidden in the knowledge base or something. Overall, though, MS provides very good documentation, and they even provide a huge mass of source code including the actual source for just about every driver they've written. I wish as much useful information were available for Linux.
[1] This is a serious matter. One of the worst things about Windows is the way that the architecture has historically forced a lot of people to implement stuff as drivers because there was no way to do what they needed to do in user space. This has resulted in a lot of driver code written by crappy programmers, and is about 90% of the reason Windows is so unstable. The code written by Microsoft themselves stability-wise, although they still share some responsibility for every crash even if it's proximately caused by someone else's code. The lack of non-filesystem namespace handling in Linux is an example of Linus et al making the same inexcusable mistake.
I never claimed that, nor is it relevant, so I don't need such evidence. Andrea did in fact spend considerable time helping debug RVM problems, but obviously at some point gave up and decided to undermine that ongoing effort instead.
Odd-second-number kernel series aren't so unstable that it would be impossible to distinguish VM-related problems from other problems.
"The book" is written the way it is because - in general - the odds of failure are lower when you do things by the book. Real managers who have a clue know that. "Grasping at straws" is bad practice. The folks at SEI will tell you that the primary hallmark of a mature software-development model is that it produces repeatable results (and, at the higher levels, information that can be used to improve the process further. Sometimes you have to pick the best of several bad alternatives, but that should still be done according to proven risk-management principles instead of "grasping at straws".
Linux development is often held up as a model of how well open-source development can work. If AVM had proven to be less stable than RVM - and there was, at the time, practically no reason to believe otherwise - and the resulting instability in 2.4 were also associated with an obvious case of bad process management, that most certainly would reflect on open-source development models. I can see it now. "Open source development is fragile, it's vulnerable to the whims of untrained project leaders who make decisions based on politics rather than technical merit..." and so on. You can't seriously believe such polemics would not be written in such a situation, can you?
See previous about why the book is written the way it is; the whole point of the book is to reduce the chances of ending up "dead". Try to put yourself in Linus's shoes, at the time the decision was made. You have two choices:
Can you seriously suggest that #2 was the responsible choice, most likely to lead to success? I don't think so. Linus made the decision based almost entirely on his personal feelings about the people involved, a lapse of technical objectivity which any "real manager" knows often leads to disaster. Whether disaster actually occurs in the here-and-now is irrelevant; such behavior should be discouraged in the strongest terms by anyone who cares about the future of Linux.
And it's better to load the whole thing? Um...hello? Anybody in there? Sure, you can save some latency by transferring the data in large chunks instead of individual pages, but you make up for that in wasted transfer time. Then you have to consider the effect of filling up the cache with pages you actually turn out not to need, evicting other pages you do need to make room for them. Overall, it's a big loss.
Bullshit.
Bullshit again. Maybe it's true for web servers, though with mod_perl and such out there I have my doubts. It's definitely not true for most other common/interesting workloads.
Three strikes, you're out. I was there in 1980, in fact I was working on one of the earliest SMP VM systems (UMAX, at Encore). Things have changed a lot since then.
Hm. Four strikes? The 2X figure is a Linux 2.2-specific red herring. Many systems can make effective use of more under many workloads.
Before anyone else points it out, that should be 245. I don't know how that period got in there; I guess it's something I should watch out for when I post at 3am. In any case, this just means that the previous poster was off by three orders of magnitude rather than four. Congratulations. :-P
Obviously the only authoritative answer would have to come from Andrea, but my guess can mostly be expressed in one word: ego. He thought his fundamental ideas were better than Rik's.
No matter how long it might have taken to fix RVM in 2.4, that's no excuse for 2.5 not being open. All of the flip-flopping should have taken place in 2.5, and if AVM turned out to be the "winner" in that environment it could have been back-ported to 2.4 if necessary.
That gets a little harder when AVM - and in particular its features that diverge from 2.2 - is almost totally undocumented. Many of the kernel developers have complained bitterly about this fact.
Yes. The best and average cases were comparable, and the worst case for standing pat was better as it didn't involve calling the whole open-source development model into question. Perhaps even more importantly, taking a stand on principle would have set a good precedent and example for the future.
The saddest thing here is that such garbage got modded up as "informative" instead of being modded down into oblivion for being "uninformed".
Even with RAM at US$0.25/MB or less, that's still untrue. A top of the line hard disk is under a penny per megabyte, which represents a pretty significant difference.
Where the hell do you get 300K from? Picking the first drive I see at an online store I see an average seek time of 4.9ms (RPM is totally irrelevant). 4.9ms/0.02ms = 24.5, not 300K. Yeah, yeah, you have to factor in transfer times as well, but 300K is still way out of line.
Not all workloads are characterized as short, independent, stateless operations. Yes, there are applications out there that aren't webservers, and they deserve to be well supported by the OS as well.
Bullshit. But I see others have already addressed that.
So, because the mismatch between RAM and disk access times is so great, it's better to move all of a process's address from RAM to disk and back again instead of just part? Riiiiight.
As someone else said, please take an OS class. While you're at it, read Hennessy and Patterson. You seem to be missing a lot of information about how computers actually work at both the hardware and software levels.
Untrue. Simply untrue. Most VM systems will slow down, some gracefully and some not, but they will not deadlock.
It's also more than a philosophical issue, BTW; it's a very real-life practical issue. The whole idea of killing a process - any process - completely and irretrievably because the system is low on memory is simply brain-dead. Better solutions might involve working-set limits, emergency reserves (similar to what's already done for disk space in some filesystems), disallowing memory overcommit, long-term suspension of processes so their pages can be stolen, etc. - the possibilities are nearly endless. The OOM-killer approach always carries the possibility of leaving the system truly deadlocked as one member of a temporal-dependency chain - perhaps spanning multiple machines - gets shot in the head. You'll have plenty of memory, but it won't be doing you any good as you're deadlocked nonetheless. There is no problem that the OOM killer solves that is not solved better by a different approach.
And whose fault is that? Who has unilaterally refused to open a 2.5 branch even though there clearly should have been one months ago? The lack of a 2.5 branch is a major piece of what's wrong, and it can be laid at exactly one person's clay feet.
No, there have been quite enough delays associated with 2.3/2.4 already. More than enough. And there will continue to be delays until the processes get ironed out.
What would have been preferable, IMO, would have been if more resources had been devoted to fixing and tuning the VM we already had (RVM, for good or ill). Linus could have put his foot down. He could have said "There will be no 2.4 VM except for RVM. The price for admission to the next round of VM redesign is that you help us fix RVM." People - notably Andrea - would have listened, and contributed more constructively. They know that Linus's good will is like currency. But Linus didn't say that. Alan Cox pretty much has, and kudos to him for having the courage to do so. What Linus did was take a bad situation and act in a way that nine times out of ten would make it worse. Maybe he'll get away with it this time because AVM in its current state is more robust than RVM in its current state, but that would actually be a bad thing because it will only reinforce the bad decision-making and we'll get burned next time instead of this time.
First off, are good reviews from places like ZDnet the goal for Linux development? Second, do you think it's better for the stable 2.4 kernel to be subtly, unpredictably unreliable? Better the devil you know, and all that.
Most importantly, what if Linus's gamble - and that's what it was - hadn't succeeded? What would the ZDnet reviews be like then? What kind of ammo would that provide for everyone who wanted to claim that open-source development processes weren't all they're cracked up to be? Yeah, it looks (so far, knock wood) like we've been lucky this time, but I don't think relying on luck is a good thing.
The two aren't as diametrically opposed as you make them out to be. Good engineering practices are good because they help increase either the speed or the reliability with which product can be delivered. Slavish adherence to any dogma is a bad thing, but so is the belief that everything you're doing is OK just because you managed to win one game of chicken. My point is that this scenario is going to be repeated. I'd rather encourage responsible driving than watch what happens when Linus plays one game of chicken too many and brings everyone else along for the ride.
Yes, mostly. Except for the classzone stuff.
Absolutely. I'd love to see Rik and Andrea (and others?) competing on purely technical merit, in the 2.5 tree. I think that would be great for everyone.
I did read the whole thing, asshole. Why would you think otherwise? Because I didn't respond to every other point you made? Ridiculous! Don't try to act all aggrieved, as though your comment was taken out of context; it was absurd regardless of context - even in a context where I agreed with the rest of what you were saying. Context is not the issue here. The issue here is the way that you, in your classic "I teach at MIT" arrogance, have refused to accept that anything you say could have been in error even when the error is waved in front of your face. I pity your students.
IMO both Rik's code (RVM) and Andrea's (AVM) were accepted prematurely, and Linus's ADD is the root of the problem here. Everyone thought the 2.2 VM was broken, so he jumped on RVM when it really hadn't received adequate testing with various workloads. Then, when that didn't work out, he did something even worse by jumping on AVM in the middle of a "stable" kernel series when it was totally undocumented and even less thoroughly tested than RVM. That's just bad software engineering, regardless of the quality of Rik's or Andrea's work.
Ideally, an "old-fashioned" alternative to RVM would have been maintained throughout the 2.3 process, as a fallback in case RVM turned out not to be ready for 2.4 - which was in fact the case. But this wasn't done, there was no alternative, and so RVM became the basis for 2.4. Once that decision was made it should not have been unmade by replacing RVM with AVM. Andrea's work should have been in the 2.5 tree, which should have been opened a long time ago to deal with precisely this sort of situation. 2.4 is not the last Linux kernel that will ever exist. We don't need to make it perfect. It would be far better to admit its imperfections, band-aid them as best we can, and try to get a head start on creating something better for 2.6. What we have instead is error on top of error, "not ready" replaced with "even less ready".
To clarify, I have nothing but the highest regard for both Rik's and Andrea's work. Obviously they have different ideas and attitudes. Rik has drawn on many sources in his design, resulting in a system that is both very advanced and very complicated. The process of reining in the complexity is still incomplete, but I still have hope that some day Rik will be able to come up with something that's really awesome, and he has always documented his ideas thoroughly. Andrea, by contrast, is much more pragmatic; he wants something that works now even if it's somewhat more limited in scope (e.g. by being almost impossible to reconcile with NUMA). The dark side of that "pragmatism" is that Andrea has skimped on non-code activities such as documenting or explaining the basic ideas on which his system is based. Nonetheless, both have done great work and should continue to do great work...in the 2.5 tree.
There was an interesting thread on this a while back, rooted at this comment. Unfortunately, the article's old enough that it's only available as a static page, and the oh-so-wonderful Slashdot code that generated the page seems to've done so with the comments in basically random order, so it's almost impossible to follow the thread. Maybe I'll try to recreate its original structure and put the result on my website.
In brief, I think it's a great idea. Competition is good; let individuals and teams compete on the basis of the quality of their work, and bless the "winner" as part of the official tree. The "loser" is always free to try again in the next round. The only problem is that this all should have occurred in the 2.3.xx and/or 2.5.xx series; 2.4.xx should not be changing horses in midstream.