Name a single real world problem that doesn't parallelize. I've asked this question on slashdot on several occasions and I've never received a positive reply. GUIs (main event loop) for word processors, web browsers, etc. (Java feels slow because GUI code in Java is slower than human perception). Compilation (see below - it's a serial problem with a just-good-enough parallel solution). State machine simulations like virtualization or emulation. Basically, any task where the principle unit of work is either processing human input or complex state transitions. Only numerical simulations - problems with simple state transitions - parallelize well.
Real world problems like search, FEA, neural nets, compilation, database queries and weather simulation all parallelize well. Problems like orbital mechanics don't parallelize as easily but then they don't need parallelism to achieve bounded answers in faster than real time. FEA, neural nets, and weather simulation are almost entirely number crunching - a small set of initial data plus a very large number of matrix multiplications. These are embarrassingly parallel, are well-understood and easy to optimize. The tradeoffs, in terms of locking / memory sharing / communication overheads, are documented by the past 40 years of literature; innovation is in new memory architectures or locking schemes or access patterns that tweak the costs of a small part of the program a little. And only ~1% of programmers out there even work on these sorts of problems.
Search and database queries do parallelize well, but not because of multiple processors. These two operations are fundamentally I/O bound - the data sets are too large to fit into memory, so you switch to an event model and do processing when data arrives. More raw CPU speed helps only a little (maybe 1% of the processing can overlap) - the actual gain is in larger caches and memory hierarchies. I doubt the original articles meant to call "overlapping I/O" parallel programming.
Compilation is expressly NOT a parallelizable problem. You may think it is - you fire off make / distcc and a whole storm of compilation happens - but you accept this only because compilers skip even the easiest inter-file optimizations because even attempting them serializes the problem so thoroughly that it becomes single-threaded. All the gains of JIT compilers are possible with static compilation too - but the cost of doing so is too high, so static compilers do very little optimization and JIT compilers get impressive gains with very simple optimizations on hot-paths despite terrible type-checking overheads. Compilation is in a mediocre state now - and we have dozens of languages prospering at different points on the cost curves - because it is an intrinsically SERIAL problem of fantastic complexity. I could write the most complex neural network algorithms on a single sheet of paper; even the parsing tree for the simplest languages won't fit on that page, much less optimization passes.
Most computers in this world are running code to solve inherently serial problems. Saying that numerical methods' sort of parallel programming has broader applicability is ignorant of all the problems outside that narrow area. Sorry.
And OpenMP is completely useless outside of the narrow field of embarrassingly-parallel numeric computation for which it was developed. OpenMP assumes the only thing worth spreading across processors are tight kernels of code, so OpenMP only produces gains when very large fractions of code are exactly identical. OpenMP is nothing more than a thin wrapper around five or so common scatter-gather paradigms. OpenMP makes scientific code easier to write, and never claimed to do more.
Pthreads is a more useful parallel API for any task outside scientific computing. But if you want the high-level overview, David Patterson's (yes, the David Patterson of The Book on computer architecture) multicore talk is quite good. (I think I found the right slide deck...)
Friend, everything you say sounds fine and great, but as an employee of a company that DOES have a successful closed-source Linux app, I assure you that it is far more complicated than you realize. These solutions you mention are both the only way, and quite painful.
The first big issue is bug compatibility of all those Linux libraries. Every major dynamic library has regressions, new versions are NOT bug compatible with older ones. E.g. libssl has a 50/50 chance of being compatible (slightly older systems use a highly-patched 0.9.7, newer systems a less-patched 0.9.8, and if you linked against the wrong one your binary fails to load). The libstdc++ ABI mess is still not quite sorted out. Static linking or shipping custom dynamic libraries are usable solutions - but you have to deal with patches for all those binaries, or get flamed across the internet for using a several-month-old version of some library (e.g. the Android beta).
Linux dynamic linking is great when all your binaries come from the same source (e.g. your distro builds them all from source); anytime you have multiple sources for those binaries, Windows DLL Hell looks like paradise. The ONLY sane way to distribute an app that dynamically links against a distro's libraries is to work with the distro to have the distro build your app (game) from source.
The second big issue is backwards compatibility. If you ship a Linux game, what are your minimum requirements? Ubuntu 7.10? 7.04? Fedora 7, 8, 9? Once you pick a few distros, this gives you a fixed set of library calls you can use - no Linux kernel calls from the past year, nothing newer than about a year (and add in 2-3 months to get through QA and reach the market). New distro switches to a different launcher interface? Tough - you don't get that API unless you write a LOT of fragile custom dynamic library loader code. Even the Oracle approach requires lock-in to old APIs. "GNU/Linux" API stability is nearly non-existent: kernel APIs are fine, but the set of system libraries changes faster than even MSFT issues patches, and with far less testing. The "Linux (userlevel) way" is to add a new API for a new feature, instead of exposing a new feature through existing APIs. For all its flaws, MSFT has done very well with backwards compatibility and API stability in a way no Linux distro has ever matched.
The truth is, Linux system library design favors building all installed apps from a single source base (or at least common headers), which is why distros are so important to the Linux ecosystem - they build from source so you don't have to. This is also why a distro update tends to update half the binaries on the system when a core library changes (especially libgtk2), and why distros have major releases yearly (or more often) to refresh core libraries. The design is very unfavorable to closed-source binaries. I'm not saying this to gripe - it is merely a statement of fact, and an observation that closed source on Linux will not become common unless Linux distros start making efforts to make the environment less unpleasant for closed-source software. Until that happens, closed source software (like games) will stay on Windows - where the free software people prefer it.
B3 Opterons are shipping. I know a few people who just got nice 8-core Barcelona boxes - one guy was too busy setting it up to do my code reviews, can't say I blame him!
Anyway... Core2's are 1.86-2.6 GHz (Xeons tend to be 2.0 and 2.2) and a few rare 2.9GHz parts on a 65nm process, and look to be 2.6-3.0 GHz on the 45nm process (Penryn, Wolfdale). Barcelona is 2.0-2.4 GHz on a 65nm process (probably 2.6 GHz for Phenom parts), I expect it will get the same speed boost once AMD goes 45nm later this year. Clock for clock, the architectures are quite close and probably about at the practical maximum for IPC on x86; Intel does better now because they are 6 months ahead on the die shrink and get a higher top speed.
Agree entirely. The key question here is "but can it run Vista?"
This isn't sarcasm - the whole point of a cheap CPU/GPU combo is the corporate desktop, where the goal is to run Windows but not to install the high-end processor or graphics card. Right now, Vista plus Aero graphics means installing at least a mid-range graphics card add-in ($100, roughly) - the range Fusion looks to integrate. Intel... without specs, it is hard to guess what they are planning, but Intel doesn't even have a high-end GPU, and I don't really see them integrating their best GPU. I expect Intel to come up with a server-class GPU (e.g. 2D only).
I'm also very bothered by the link above describing this Nehelam CPU/GPU combo. It talks about a 8-CPU die and a mem-controller/GPU die, which sounds like the same old Core2 architecture (moving northbridge on-chip) instead of the new CSI Nehelam is supposed to bring. Hint to Intel: AMD scales better because their (local) memory traffic and cache coherence traffic travel on independent buses, and because at ~4-8 cores you can saturate any interconnect with cache coherence traffic!
It's obvious today, in 2008. Looking back to 1997, I'm not entirely sure it was obvious. Windows 95 ruled, Linux was still in the 1.0 era. Netscape 4.0 came out in 1997. Sure, a 1997 UNIX sysadmin could have written a quick script that did what this patent describes - but I suspect very few did (non-obvious), and none (except Trend Micro) saw the business opportunity to do so.
Hate to say it, but this patent (1) seems non-obvious, (2) is by a company doing useful work in the area, and (3) seems cheap enough that Symantec / MacAfee pay the fees. Open-source is NOT a blanket license to break the law; giving away your code does not entitle you to steal somebody else's good ideas.
I lie slightly - yes, the original Core Solo/Duo CPUs (used only in a single generation of Macs) runs in 32-bit mode (I think PAE). All Core 2 chips run in 64-bit compat mode. All kernel/driver code (except page table manipulation code) is binary compatible between these two - the differences between real 32-bit and compat-32-bit are in 16-bit compatibility layers that nobody uses. So all Apple drivers are exactly the same, except for the few bits of mach kernel code that touch page tables and never show up in drivers. (And many of them are the same... L1 and L2 of PAE page tables are the same as 64-bit).
x86 mac kernels ALL run in 64-bit addressing mode, with code compiled to 32-bit compatibility mode. This means the page tables are 64-bit but the actual code is 32-bit. No other OS runs in this mode. The issues described in this slashdot article apply only to the addressing problems... so Mac OS doesn't have them.
XP uses PAE for any processor that has no-execute bit support or more than 2GB of memory. I've filed bugs against MSFT specific to that kernel (PAE BSODs, non-PAE handles error). Try looking at your kernel next time... the file specifically says PAE;-)
Oh, no worries, they're using Windows Vista Despot Edition. Unlimited processors, support for WMD simulation* (* = linear speed-up not guaranteed on Microsoft products), a new World Domination Wizard, and a customizable anti-American slogan at startup.
Because it *can* cause a circular include dependency which is extremely difficult to detect. FooClass instantiates BarClass instantiates FooClass... kaboom. And it really does cause a large increase in preprocessing times to pull in all those headers, even simple files end up 10,000-40,000 lines after preprocessing.
That said, I and my coworkers use includes in headers all the time. (ONLY include a header if you need the full definitions; if it's just a FooClass pointer, forward declarations are far better. And don't be afraid to split a header into "foo.h" (struct definitions" and "foo_types.h" (forward decls, typedefs, enums); most clients of the header only need the latter). Writing good code truly is an art form.
I tend to agree, AT&T gives Apple some $$$ from exclusivity and a bunch of bad PR. Hmm... wild guess, but maybe Apple has already made (but not yet announced) a decision to go elsewhere, and this announcement is AT&T's way of saying "we're screwing you before you screw us"?
I know, probably wishful thinking on my part. Still, it is a nice wish...
Microsoft publishes and maintains a networking API (six revisions of it, actually) to make it easy for my manufacturer to provide a working driver on a CD when I buy my laptop. Which is far more work than Linux ever did.
Sure, Linux is the best when you only look at what is installed out-of-the-box. Which is about as useful as saying Windows is the best because it comes on a pretty CD. To the rest of us, usability matters; a Windows system is upgradeable (that is, install new apps), while a Linux system requires several months of admin experience to perform even a simple upgrade. (And before anyone talks about the "ease-of-use" of apt-get, think hard about how many years YOU have run Linux to be that familiar with apt-get.) A few distros make upgrades easy (RedHat, Ubuntu), BUT do so by not providing new features in upgrades (e.g. Ubuntu has no.deb for Firefox2 on my 6.10 system, only Firefix1.5.0.x, and by the way updating 1.5.0.7->1.5.0.15 requires a 100-package update)
You have just (re-)discovered reason #1 for a stable kernel API. Unfortunately, "smart" Linux kernel community leaders have decided they are smarter than you. I long since gave up on this debate after realizing the other side was not interested in debate. Believe me, I want ease-of-installation (for complex kernel-integrated apps like VMware, or simple apps like gcc) just as bad as you.
Windows is designed by marketing. Linux is designed by F/OSS politics. Neither one cares about users. (Mac OS X does care about users, but it is still immature by kernel standards, *sigh*.)
I'm in the common-name category... search for my Firstname Lastname and you'll get a naturalist advocate (read: nudist). Followed by a bunch of hits in encyclopedias where my last name is also a common middle name. Fortunately, I've never had problems interviewing...
Or, as Scott McNealy said, "You have no privacy. Get over it." Funny how nobody liked the comment when he made it, yet he was completely right.
Yes, somebody out there is going to store every bit of data they can because it just MIGHT be useful. Data storage is extremely cheap: if a marketer can get one lead from 1GB of web server access logs, he's making a profit. The feds want to cross-index databases because some analyst thinks terrorists would obscure online activities by using one account to communicate with like-minded people and another account to do research for some attack - and if 500TB of data stops an attack, it's cheap. (The idiot analyst is grossly underestimating the difficulty of cross-indexing databases - hint, names are NOT good primary keys - and it's his manager's fault for approving the idea, but you can't stop idiots with poor management from doing stupid things.)
Worse, no amount of government laws will protect your "public" data. Oh, laws can keep the government from using it... somewhat. (In the US, warrentless searches are inadmissible in court - but they aren't illegal, the police can use such evidence to decide to watch you more closely in hopes of getting real, admissible evidence). But laws are not going to keep private companies from using your data. Privacy policies are great, but (IANAL) probably flimsier than EULAs that everybody here on Slashdot derides. And there is always an immoral company willing to violate its own privacy policy for a business advantage. Example ineffective law: in the US, you aren't supposed to use SSNs for personal identification (except for the IRS). So everyone just starts using the last four digits of the SSN, which technically complies but, when combined with just a little more data, is just as invasive. (Hint: there are 300 million people in the US. 30,000 have the same four-digits as you, 600 are in the same state (in California), 5 are in the same city, and none use the same set of banks you do). The law will not protect your privacy. Sorry.
But what are the effects of this invasion of privacy? A private company could refuse service to you - most companies can already do that for any number of reasons, maybe they don't like your credit history or your choice in web browsers. The government could arrest you - they can already do that for any reason, it's the court that will order your release, and the court is unbiased enough to not care about anything except the charge. Maybe you'll find out your neighbor has a thing for horse porn and think less of him. Well, it's your own fault, if you don't want to know about horse porn fetishes, then don't go looking for them.
Virtualization is NOT intended for security. Period, end of story, full stop. Security is a secondary effect from having smaller interfaces, and you DO get smaller interfaces with inherent security advantages.
Here's the first truth of security: your ability to secure a system is INVERSELY PROPORTIONAL to the size of the interface to that system. Every interface point is a potential attack vector, whether direct (an attacker can exploit the interface) or indirect (something outside your control is loaded at interface A, then an attacker at interface B causes A to exploit something). Most security products try to reduce the size of interfaces (e.g. a firewall limits the number of open ports, then further excludes some types of traffic from those ports).
Look at a general purpose operating system kernel. There are hundreds of system calls (direct attack vectors), hundreds more driver interfaces (indirect attack vectors - driver interfaces are privileged and thus drivers must be bug-free), a few thousand more configuration points (Windows Registery, Linux/sys and/proc trees). Add the libraries that make up the rest of the operating system, and the number of APIs has exploded to thousands, if not tens of thousands.
Now look at a hypervisor stack. The hypervisor::guest interface is the CPU instruction set (extremely well documented and easy to programatically verify, especially when 99% of instructions can be verified to have no side effects!). Much narrower interface than a general-purpose API. The driver::hypervisor interface is narrower too, since the hypervisor only uses a lower-level interface (e.g. Xen's block device interface, VMware's SCSI interface) that happens to be simpler and better documented. Configuration API is smaller, since it only needs to manage virtual machines, not every possible combination of user-level program and device.
It's the old microkernel / monolithic kernel debate all over again, where a hypervisor is a microkernel and a general-purpose OS is a monolithic kernel, and the performance loss is small enough that companies are using it in production today. Microkernel have advantages in being easier to secure, more robust in the face of bugs... monolithic kernels are faster. Is the smaller API (and increased security) worth the loss in performance?
Here's some security thoughts, based on actual experience with virtualization bugs.
The largest number of security vulnerabilities appear in user-level servers, e.g. NAT, DHCP, ssh, apache. Potential commands to these services are unlimited (wide API), often involve text-parsing in C code (inherently difficult), and so they are hardest to secure.
A moderate number of security vulnerabilities appear in paravirtualized device emulations. Paravirtual devices are less well specified (medium-width API), so the implementations have more bugs, often from ways the paravirtual device spec doesn't anticipate. (Yes, hardware folks write more complete specs than software folks).
Extremely few security vulnerabilities appear in the hypervisor::guest boundary. This boundary is extremely well specified via data sheets and architectural manuals. (narrow API).
If the guest can take over the host, this is an EXTREME vulnerability. VMs are used for security research sandboxes, intrusion containment... hosting providers tend to sell root access to Xen guests. The Xen privilaged parts (e.g. dom0) tend to run within trusted networks. This is as bad as a remote root hole - probably worse, because it can affect a lot more machines. See a write-up about a Gartner report fearing exactly this sort of hole.
Compare "lots of holes, usually fixed quickly" with "very few holes". Vulnerabilities should not exist in this sort of software, no matter how quickly fixed. Would you use SSH if vulnerabilities "happen almost daily, and are usually fixed quickly"? The rate of occurrence of bugs like this is indicative of code quality. Don't be an apologist where security software is concerned.
Virtual Machine Monitor and Hypervisor are NOT synonymous - they usually come in the same package, but this is not required.
An example Virtual Machine Monitor without a Hypervisor is VMware Workstation: a small VMM is loaded to run the guest OS, but it is not complete enough to run the system - it has no task switcher, no memory manager, etc. The host OS acts as the hypervisor here - it is the source of highly-privileged operations unavailable to the guest. Another no-hypervisor VMM is KVM: KVM just runs a virtual machine, but depends on the rest of Linux to run more-privileged operations (and Linux itself becomes the hypervisor).
An example Hypervisor without a Virtual Machine Monitor is the partitioning software on high-end IBM, Sun, etc. machines, which allows you to physically partition the processors of the system into several actual machines - partitioned machiens with zero run-time interdependencies. Literally, a "hypervisor" is something which runs at a privilege level higher than the "supervisor" (the OS).
Hypervisors and virtual machine monitors have existed since the 1960s. Nobody confused the terms then. IBM started the confusion with a whitepaper"inventing" the type 1 / type 2 taxonomy to distinguish between 1960s-modern IBM mainframe architectures (low-end = hypervisor only, high-end = combination hypervisor/vmm) and the VMware Workstation architecture (host OS loads vmm; host OS acts as hypervisor). Note that VMware never claimed Workstation was a hypervisor! Certain communities (Wikipedia, the press) have accepted IBM's whitepaper as gospel truth, thus the prolifieration of "type 1" and "type 2" terms the past several years. (The same community has chosen to ignore academic research in the 1960s and 1996-2005 which used VMM and Hypervisor correctly.)
With apologies to many individuals who are legitimately using correct terminology, some poorly-informed folks are propagating the "type 2 hypervisor" meme to attempt to equate the abilities of a hypervisor/VMM with a VMM. This is not correct: a combination hypervisor/vmm ALWAYS can achieve better performance than separating the hypervisor and VMM - at the cost of creating a more complex hypervisor (ESX requires custom drivers; Xen requires a customized dom0). The fault for this confusion really rests with Intel: their VT extensions (and AMD's SVM response) have made it so easy to create a VMM that some folks are creating a VMM, then marketing it as a hypervisor in a misguided attempt to compete with existing hypervisors (ESX, Xen) instead of competing with other VMMs (VMware Workstation/Fusion, KVM, Parallels Desktop)
To understand what a VMM is, read this ACM article by Mendel Rosenblum. Academic research generally looks at VMMs (ways to run a virtual machine), not hypervisors (ways to run something with less privileges than the hypervisor). A rough gage of the quality of academic work is whether they manage say Hypervisor when they mean Virtual Machine Monitor. Anyone who thinks the two are the same is ignorant of the past ten years of academic research - and anyone ignorant of ten years of research is doing very poor-quality work. (Alas, Wikipedia chose to use the IBM whitepaper for defining terms instead of many years of published, peer-reviewed papers. Great "neutrality", folks!)
This blogger did something quite insidious and quite stupid: she chose only examples that support her claim. Let's look at all her ugly/evil/l3me closed-source whipping boys:
Diebold
The poster child for make-a-buck quick. Diebold saw a "need" for electronic voting software, lobbied a few politicians to get sweetheart deals, and came up with substandard, shoddy software. Same moral as always: you get what you pay for, and the gov't paid for the lowest bidder.
Samsung's Linux rootkit
So Samsung wrote some truly crappy Linux drivers? Well, Samsung's printer driver looks like it was written by a college intern on his first assignment - which probably means it was written by a college intern on his first assignment. Do you really thing Samsung is going to assign their best developers to writing a Linux driver, especially when Linux folks will just reverse-engineer it anyway because they don't like something about it? No, Samsung is going to give the project to the lowest-level code monkey they can find. OF COURSE the code looks crappy.
BIOSes
Did you know there are exactly two major BIOS vendors out there? That there are no more than a hundred or so professional BIOS developers in the world? Yet there are more copies of BIOS software out there than Windows; everybody expects BIOS to support new whiz-bang features (boot from USB, PXE boot, boot device ordering, processor errata, microcode updates). There simply aren't enough people to make BIOS code look good. BIOS programming is hard - harder than writing a kernel. It's understaffed, and the code quality shows. You think BIOS vendors stick with BIOS because they want lock-in? Ha. How about they don't have enough people to create a replacement, they are too busy patching up last year's code with this year's features.
Netscape
Yup, the Netscape codebase is an ugly mess. You'd think they implemented features without planning months ahead, almost like they were competing with some other major web browser... the Netscape mess is a result of competition. I know enough former Netscape engineers to know they don't write crappy code. But when your schedule gets cut from 1 year to 3 months to compete with Redmond, crap will result. Remember, Open Source has the luxury of not having schedule competition - if a company delivers a feature late, developers will find themselves out of a job.
StarOffice/OpenOffice
Isn't the revisionist history here fun? Do you really think Sun was proud of the StarOffice codebase? No, Sun released it because the Open Source community begged for it (and Sun was the most likely to give in), and Sun wanted an office suite competitor to have SOMETHING to start from. No one ever claimed StarOffice code was any good; the only claim here is that StarOffice was better than nothing. You think Sun's best engineers worked on StarOffice? No, they worked on Solaris and Java. (With apologies to anyone who did work on StarOffice.)
So... we look at five projects that have every right to contain crappy code, and therefore conclude that companies keep code closed to hide crappy code? Pick crap and you will see crap. How about some successful projects: Microsoft Windows (kernel), Adobe Photoshop, VMware?
Focus and intensity - keeping on task, not reading slashdot when you should work - these are what increase your output. Lots of extra hours at your desk per week isn't it You assume that the engineer who stays up all night working on a project is unfocused and lax. Wrong. A good engineer is staying up all night working on the project because the moment of focused, intense activity finally arrived - and is a rare event. A good engineer knows all-nighters for the sake of all-nighters is stupid. Treasuring the moment of intense activity is the joke; glorifying an all-nighter is not, but is the common misconception of people who don't get the joke.
Consider Mr. Family Man, who gets a good idea at 4:45pm, but leaves at 5pm exactly and manages to forget his idea the next day. He's far more wasteful of productivity. A good engineer will call home, apologize for missing dinner, be extremely productive, then take the next day off to make it up to his family. A good manager supports this. Amazingly, this good engineer has managed to both do more work and spend more time with his family. Astonishing.
Sorry, you're both wrong, but the GP is more right. Symmetry isn't power-of-two numbers, it's memory arrangements.
The symmetry in SMP means that all processors share the same memory image - that they actually run the same kernel, with all the same memory available at the same physical addresses. ASMP has different and mutually inaccessible memory banks between processors (e.g. same kernel, but some memory isn't shared, so communication MUST occur via message-passing). An example would be if the first 1GB is shared between all processors and the next 1GB is per-processor. Most supercomputers (like Cray) are ASMP because non-shared memory banks don't have to be memory-coherent, which is faster, cheaper, and easier to manufacture but harder to program. Some ASMP configurations could run different kernels on each node, too - e.g. a dedicated I/O processor - or different architectures at each node (e.g. the relation between the CPU and GPU is an ASMP relationship).
Parent is thinking about the difference between UMA - Uniform Memory Access - and NUMA - Non-Uniform Memory Access, which ONLY has to do with the access speed of memory. ASMP implies a component that is neither UMA nor NUMA. On SMP there is an additional level, ccNUMA (Cache-Coherent NUMA), which guarantees that both caches and memory share coherency; the alternative is to ensure that shared cache lines are never kept in cache. AMD uses ccNUMA; I don't remember if Intel's upcoming NUMA arch is cache-coherent or not, but it probably is. Non cache-coherent NUMA archs are useful in supercomputers, where memory sharing is rare enough that keeping shared lines in main memory instead of cache doesn't impose as much of a performance burden.
And the knowledge nugget of the day: OSes prefer power-of-two processor counts because it's easier to perform bit tricks with them. E.g. when you assign each processor a number, the validity check is a bitmask instead of a comparison or modulo. It's not MUCH easier, so a good OS uses other tricks (like single-bit-set bitmaps) that waste some more space but don't have these edge-cases.
Very nice argument. I mean this quite seriously - this is one of the better posts I've seen on Slashdot in a while.
The right of the people to be secure Here's the one part missing from your argument. The US Constitution enumerates the rights of people - that is, citizens (and, by courtesy, resident aliens), NOT of human beings. It does NOT enumerate any rights for non-citizens. If a foreign national visited the US, the government could imprison and execute him without trial, without once violating the Constitution. (It would violate a mess of treaties and the foreigner's government ought call this an act of war, of course!) For the rights of non-citizens, you'd have to look to treaty arrangements, and treaties are explicitly subordinate to Constitutional law.
International phone calls, etc. are carried by non-US companies over non-US property and usually involve non-citizens. The Bill of Rights does not apply; the government can examine or seize foreign property all it wants (at risk of offending foreigners). Immoral, arrogant, stupid, provocative, yes. Illegal, no.
But the original work allowed choosing one license (or the other) for subsequent changes. No. The original work allowed choosing one license (or the other) for distribution.
Subsequent changes must either (1) be explicitly re-licensed (by adding a statement to that effect, e.g. "function foo is GPLv2", or a broad statement, "changes to this file after [today] are GPLv2"), or (2) they default to the original license of the file (dual BSD/GPL). The problem here is that the patches in question sought to change (1) but actually changed (2); you cannot change (2) without being the copyright holder.
I read the article and understand it perfectly well - we're making exactly the same point:
"What is impossible in user space driver is kernel space features". Alas, 40% of the posts in this discussion fail to realize that the binary-only drivers people WANT to see (3D gfx, wireless) are necessarily kernel-space, and are already anticipating Nvidia/ATI non-kernel drivers. Ha.
The stable user driver API can replace the drivers that were already GPL-able (because they do nothing IP-worthy) but aren't yet. It won't do anything for you or I or anyone outside the embedded market.
Slashdot Mirror
Search and database queries do parallelize well, but not because of multiple processors. These two operations are fundamentally I/O bound - the data sets are too large to fit into memory, so you switch to an event model and do processing when data arrives. More raw CPU speed helps only a little (maybe 1% of the processing can overlap) - the actual gain is in larger caches and memory hierarchies. I doubt the original articles meant to call "overlapping I/O" parallel programming.
Compilation is expressly NOT a parallelizable problem. You may think it is - you fire off make / distcc and a whole storm of compilation happens - but you accept this only because compilers skip even the easiest inter-file optimizations because even attempting them serializes the problem so thoroughly that it becomes single-threaded. All the gains of JIT compilers are possible with static compilation too - but the cost of doing so is too high, so static compilers do very little optimization and JIT compilers get impressive gains with very simple optimizations on hot-paths despite terrible type-checking overheads. Compilation is in a mediocre state now - and we have dozens of languages prospering at different points on the cost curves - because it is an intrinsically SERIAL problem of fantastic complexity. I could write the most complex neural network algorithms on a single sheet of paper; even the parsing tree for the simplest languages won't fit on that page, much less optimization passes.
Most computers in this world are running code to solve inherently serial problems. Saying that numerical methods' sort of parallel programming has broader applicability is ignorant of all the problems outside that narrow area. Sorry.
Pthreads is a more useful parallel API for any task outside scientific computing. But if you want the high-level overview, David Patterson's (yes, the David Patterson of The Book on computer architecture) multicore talk is quite good. (I think I found the right slide deck...)
The first big issue is bug compatibility of all those Linux libraries. Every major dynamic library has regressions, new versions are NOT bug compatible with older ones. E.g. libssl has a 50/50 chance of being compatible (slightly older systems use a highly-patched 0.9.7, newer systems a less-patched 0.9.8, and if you linked against the wrong one your binary fails to load). The libstdc++ ABI mess is still not quite sorted out. Static linking or shipping custom dynamic libraries are usable solutions - but you have to deal with patches for all those binaries, or get flamed across the internet for using a several-month-old version of some library (e.g. the Android beta).
Linux dynamic linking is great when all your binaries come from the same source (e.g. your distro builds them all from source); anytime you have multiple sources for those binaries, Windows DLL Hell looks like paradise. The ONLY sane way to distribute an app that dynamically links against a distro's libraries is to work with the distro to have the distro build your app (game) from source.
The second big issue is backwards compatibility. If you ship a Linux game, what are your minimum requirements? Ubuntu 7.10? 7.04? Fedora 7, 8, 9? Once you pick a few distros, this gives you a fixed set of library calls you can use - no Linux kernel calls from the past year, nothing newer than about a year (and add in 2-3 months to get through QA and reach the market). New distro switches to a different launcher interface? Tough - you don't get that API unless you write a LOT of fragile custom dynamic library loader code. Even the Oracle approach requires lock-in to old APIs. "GNU/Linux" API stability is nearly non-existent: kernel APIs are fine, but the set of system libraries changes faster than even MSFT issues patches, and with far less testing. The "Linux (userlevel) way" is to add a new API for a new feature, instead of exposing a new feature through existing APIs. For all its flaws, MSFT has done very well with backwards compatibility and API stability in a way no Linux distro has ever matched.
The truth is, Linux system library design favors building all installed apps from a single source base (or at least common headers), which is why distros are so important to the Linux ecosystem - they build from source so you don't have to. This is also why a distro update tends to update half the binaries on the system when a core library changes (especially libgtk2), and why distros have major releases yearly (or more often) to refresh core libraries. The design is very unfavorable to closed-source binaries. I'm not saying this to gripe - it is merely a statement of fact, and an observation that closed source on Linux will not become common unless Linux distros start making efforts to make the environment less unpleasant for closed-source software. Until that happens, closed source software (like games) will stay on Windows - where the free software people prefer it.
Anyway ... Core2's are 1.86-2.6 GHz (Xeons tend to be 2.0 and 2.2) and a few rare 2.9GHz parts on a 65nm process, and look to be 2.6-3.0 GHz on the 45nm process (Penryn, Wolfdale). Barcelona is 2.0-2.4 GHz on a 65nm process (probably 2.6 GHz for Phenom parts), I expect it will get the same speed boost once AMD goes 45nm later this year. Clock for clock, the architectures are quite close and probably about at the practical maximum for IPC on x86; Intel does better now because they are 6 months ahead on the die shrink and get a higher top speed.
This isn't sarcasm - the whole point of a cheap CPU/GPU combo is the corporate desktop, where the goal is to run Windows but not to install the high-end processor or graphics card. Right now, Vista plus Aero graphics means installing at least a mid-range graphics card add-in ($100, roughly) - the range Fusion looks to integrate. Intel ... without specs, it is hard to guess what they are planning, but Intel doesn't even have a high-end GPU, and I don't really see them integrating their best GPU. I expect Intel to come up with a server-class GPU (e.g. 2D only).
I'm also very bothered by the link above describing this Nehelam CPU/GPU combo. It talks about a 8-CPU die and a mem-controller/GPU die, which sounds like the same old Core2 architecture (moving northbridge on-chip) instead of the new CSI Nehelam is supposed to bring. Hint to Intel: AMD scales better because their (local) memory traffic and cache coherence traffic travel on independent buses, and because at ~4-8 cores you can saturate any interconnect with cache coherence traffic!
Hate to say it, but this patent (1) seems non-obvious, (2) is by a company doing useful work in the area, and (3) seems cheap enough that Symantec / MacAfee pay the fees. Open-source is NOT a blanket license to break the law; giving away your code does not entitle you to steal somebody else's good ideas.
I lie slightly - yes, the original Core Solo/Duo CPUs (used only in a single generation of Macs) runs in 32-bit mode (I think PAE). All Core 2 chips run in 64-bit compat mode. All kernel/driver code (except page table manipulation code) is binary compatible between these two - the differences between real 32-bit and compat-32-bit are in 16-bit compatibility layers that nobody uses. So all Apple drivers are exactly the same, except for the few bits of mach kernel code that touch page tables and never show up in drivers. (And many of them are the same ... L1 and L2 of PAE page tables are the same as 64-bit).
x86 mac kernels ALL run in 64-bit addressing mode, with code compiled to 32-bit compatibility mode. This means the page tables are 64-bit but the actual code is 32-bit. No other OS runs in this mode. The issues described in this slashdot article apply only to the addressing problems ... so Mac OS doesn't have them.
XP uses PAE for any processor that has no-execute bit support or more than 2GB of memory. I've filed bugs against MSFT specific to that kernel (PAE BSODs, non-PAE handles error). Try looking at your kernel next time ... the file specifically says PAE ;-)
Oh, no worries, they're using Windows Vista Despot Edition. Unlimited processors, support for WMD simulation* (* = linear speed-up not guaranteed on Microsoft products), a new World Domination Wizard, and a customizable anti-American slogan at startup.
That said, I and my coworkers use includes in headers all the time. (ONLY include a header if you need the full definitions; if it's just a FooClass pointer, forward declarations are far better. And don't be afraid to split a header into "foo.h" (struct definitions" and "foo_types.h" (forward decls, typedefs, enums); most clients of the header only need the latter). Writing good code truly is an art form.
I know, probably wishful thinking on my part. Still, it is a nice wish...
Sure, Linux is the best when you only look at what is installed out-of-the-box. Which is about as useful as saying Windows is the best because it comes on a pretty CD. To the rest of us, usability matters; a Windows system is upgradeable (that is, install new apps), while a Linux system requires several months of admin experience to perform even a simple upgrade. (And before anyone talks about the "ease-of-use" of apt-get, think hard about how many years YOU have run Linux to be that familiar with apt-get.) A few distros make upgrades easy (RedHat, Ubuntu), BUT do so by not providing new features in upgrades (e.g. Ubuntu has no .deb for Firefox2 on my 6.10 system, only Firefix1.5.0.x, and by the way updating 1.5.0.7->1.5.0.15 requires a 100-package update)
Windows is designed by marketing. Linux is designed by F/OSS politics. Neither one cares about users. (Mac OS X does care about users, but it is still immature by kernel standards, *sigh*.)
I'm in the common-name category ... search for my Firstname Lastname and you'll get a naturalist advocate (read: nudist). Followed by a bunch of hits in encyclopedias where my last name is also a common middle name. Fortunately, I've never had problems interviewing...
Yes, somebody out there is going to store every bit of data they can because it just MIGHT be useful. Data storage is extremely cheap: if a marketer can get one lead from 1GB of web server access logs, he's making a profit. The feds want to cross-index databases because some analyst thinks terrorists would obscure online activities by using one account to communicate with like-minded people and another account to do research for some attack - and if 500TB of data stops an attack, it's cheap. (The idiot analyst is grossly underestimating the difficulty of cross-indexing databases - hint, names are NOT good primary keys - and it's his manager's fault for approving the idea, but you can't stop idiots with poor management from doing stupid things.)
Worse, no amount of government laws will protect your "public" data. Oh, laws can keep the government from using it ... somewhat. (In the US, warrentless searches are inadmissible in court - but they aren't illegal, the police can use such evidence to decide to watch you more closely in hopes of getting real, admissible evidence). But laws are not going to keep private companies from using your data. Privacy policies are great, but (IANAL) probably flimsier than EULAs that everybody here on Slashdot derides. And there is always an immoral company willing to violate its own privacy policy for a business advantage. Example ineffective law: in the US, you aren't supposed to use SSNs for personal identification (except for the IRS). So everyone just starts using the last four digits of the SSN, which technically complies but, when combined with just a little more data, is just as invasive. (Hint: there are 300 million people in the US. 30,000 have the same four-digits as you, 600 are in the same state (in California), 5 are in the same city, and none use the same set of banks you do). The law will not protect your privacy. Sorry.
But what are the effects of this invasion of privacy? A private company could refuse service to you - most companies can already do that for any number of reasons, maybe they don't like your credit history or your choice in web browsers. The government could arrest you - they can already do that for any reason, it's the court that will order your release, and the court is unbiased enough to not care about anything except the charge. Maybe you'll find out your neighbor has a thing for horse porn and think less of him. Well, it's your own fault, if you don't want to know about horse porn fetishes, then don't go looking for them.
Here's the first truth of security: your ability to secure a system is INVERSELY PROPORTIONAL to the size of the interface to that system. Every interface point is a potential attack vector, whether direct (an attacker can exploit the interface) or indirect (something outside your control is loaded at interface A, then an attacker at interface B causes A to exploit something). Most security products try to reduce the size of interfaces (e.g. a firewall limits the number of open ports, then further excludes some types of traffic from those ports).
Look at a general purpose operating system kernel. There are hundreds of system calls (direct attack vectors), hundreds more driver interfaces (indirect attack vectors - driver interfaces are privileged and thus drivers must be bug-free), a few thousand more configuration points (Windows Registery, Linux /sys and /proc trees). Add the libraries that make up the rest of the operating system, and the number of APIs has exploded to thousands, if not tens of thousands.
Now look at a hypervisor stack. The hypervisor::guest interface is the CPU instruction set (extremely well documented and easy to programatically verify, especially when 99% of instructions can be verified to have no side effects!). Much narrower interface than a general-purpose API. The driver::hypervisor interface is narrower too, since the hypervisor only uses a lower-level interface (e.g. Xen's block device interface, VMware's SCSI interface) that happens to be simpler and better documented. Configuration API is smaller, since it only needs to manage virtual machines, not every possible combination of user-level program and device.
It's the old microkernel / monolithic kernel debate all over again, where a hypervisor is a microkernel and a general-purpose OS is a monolithic kernel, and the performance loss is small enough that companies are using it in production today. Microkernel have advantages in being easier to secure, more robust in the face of bugs ... monolithic kernels are faster. Is the smaller API (and increased security) worth the loss in performance?
Here's some security thoughts, based on actual experience with virtualization bugs.
An example Virtual Machine Monitor without a Hypervisor is VMware Workstation: a small VMM is loaded to run the guest OS, but it is not complete enough to run the system - it has no task switcher, no memory manager, etc. The host OS acts as the hypervisor here - it is the source of highly-privileged operations unavailable to the guest. Another no-hypervisor VMM is KVM: KVM just runs a virtual machine, but depends on the rest of Linux to run more-privileged operations (and Linux itself becomes the hypervisor).
An example Hypervisor without a Virtual Machine Monitor is the partitioning software on high-end IBM, Sun, etc. machines, which allows you to physically partition the processors of the system into several actual machines - partitioned machiens with zero run-time interdependencies. Literally, a "hypervisor" is something which runs at a privilege level higher than the "supervisor" (the OS).
Hypervisors and virtual machine monitors have existed since the 1960s. Nobody confused the terms then. IBM started the confusion with a whitepaper"inventing" the type 1 / type 2 taxonomy to distinguish between 1960s-modern IBM mainframe architectures (low-end = hypervisor only, high-end = combination hypervisor/vmm) and the VMware Workstation architecture (host OS loads vmm; host OS acts as hypervisor). Note that VMware never claimed Workstation was a hypervisor! Certain communities (Wikipedia, the press) have accepted IBM's whitepaper as gospel truth, thus the prolifieration of "type 1" and "type 2" terms the past several years. (The same community has chosen to ignore academic research in the 1960s and 1996-2005 which used VMM and Hypervisor correctly.)
With apologies to many individuals who are legitimately using correct terminology, some poorly-informed folks are propagating the "type 2 hypervisor" meme to attempt to equate the abilities of a hypervisor/VMM with a VMM. This is not correct: a combination hypervisor/vmm ALWAYS can achieve better performance than separating the hypervisor and VMM - at the cost of creating a more complex hypervisor (ESX requires custom drivers; Xen requires a customized dom0). The fault for this confusion really rests with Intel: their VT extensions (and AMD's SVM response) have made it so easy to create a VMM that some folks are creating a VMM, then marketing it as a hypervisor in a misguided attempt to compete with existing hypervisors (ESX, Xen) instead of competing with other VMMs (VMware Workstation/Fusion, KVM, Parallels Desktop)
To understand what a VMM is, read this ACM article by Mendel Rosenblum. Academic research generally looks at VMMs (ways to run a virtual machine), not hypervisors (ways to run something with less privileges than the hypervisor). A rough gage of the quality of academic work is whether they manage say Hypervisor when they mean Virtual Machine Monitor. Anyone who thinks the two are the same is ignorant of the past ten years of academic research - and anyone ignorant of ten years of research is doing very poor-quality work. (Alas, Wikipedia chose to use the IBM whitepaper for defining terms instead of many years of published, peer-reviewed papers. Great "neutrality", folks!)
So... we look at five projects that have every right to contain crappy code, and therefore conclude that companies keep code closed to hide crappy code? Pick crap and you will see crap. How about some successful projects: Microsoft Windows (kernel), Adobe Photoshop, VMware?
Consider Mr. Family Man, who gets a good idea at 4:45pm, but leaves at 5pm exactly and manages to forget his idea the next day. He's far more wasteful of productivity. A good engineer will call home, apologize for missing dinner, be extremely productive, then take the next day off to make it up to his family. A good manager supports this. Amazingly, this good engineer has managed to both do more work and spend more time with his family. Astonishing.
The symmetry in SMP means that all processors share the same memory image - that they actually run the same kernel, with all the same memory available at the same physical addresses. ASMP has different and mutually inaccessible memory banks between processors (e.g. same kernel, but some memory isn't shared, so communication MUST occur via message-passing). An example would be if the first 1GB is shared between all processors and the next 1GB is per-processor. Most supercomputers (like Cray) are ASMP because non-shared memory banks don't have to be memory-coherent, which is faster, cheaper, and easier to manufacture but harder to program. Some ASMP configurations could run different kernels on each node, too - e.g. a dedicated I/O processor - or different architectures at each node (e.g. the relation between the CPU and GPU is an ASMP relationship).
Parent is thinking about the difference between UMA - Uniform Memory Access - and NUMA - Non-Uniform Memory Access, which ONLY has to do with the access speed of memory. ASMP implies a component that is neither UMA nor NUMA. On SMP there is an additional level, ccNUMA (Cache-Coherent NUMA), which guarantees that both caches and memory share coherency; the alternative is to ensure that shared cache lines are never kept in cache. AMD uses ccNUMA; I don't remember if Intel's upcoming NUMA arch is cache-coherent or not, but it probably is. Non cache-coherent NUMA archs are useful in supercomputers, where memory sharing is rare enough that keeping shared lines in main memory instead of cache doesn't impose as much of a performance burden.
And the knowledge nugget of the day: OSes prefer power-of-two processor counts because it's easier to perform bit tricks with them. E.g. when you assign each processor a number, the validity check is a bitmask instead of a comparison or modulo. It's not MUCH easier, so a good OS uses other tricks (like single-bit-set bitmaps) that waste some more space but don't have these edge-cases.
International phone calls, etc. are carried by non-US companies over non-US property and usually involve non-citizens. The Bill of Rights does not apply; the government can examine or seize foreign property all it wants (at risk of offending foreigners). Immoral, arrogant, stupid, provocative, yes. Illegal, no.
Subsequent changes must either (1) be explicitly re-licensed (by adding a statement to that effect, e.g. "function foo is GPLv2", or a broad statement, "changes to this file after [today] are GPLv2"), or (2) they default to the original license of the file (dual BSD/GPL). The problem here is that the patches in question sought to change (1) but actually changed (2); you cannot change (2) without being the copyright holder.
The stable user driver API can replace the drivers that were already GPL-able (because they do nothing IP-worthy) but aren't yet. It won't do anything for you or I or anyone outside the embedded market.