Seriously, when the editor of a site that bears advertising gratuitously trolls the readership (as opposed to raising legitimate alternate views, playing devil's advocate, suggesting topics for discussion) it does look like they're trying to generate more ad revenue through bad journalism.
The editors aren't under any obligation to not submit trollish arcticles. The readers aren't under any obligation not to block ads when browsing those threads. Just a thought...
You seem to be the first one to remember the gist of it. The 8086 had 16 bit pointers (I think there was another term) and 16 bit segments. The physical address was Segment*16 + pointer, meaning only the four least significant bits were identified entirely by the simple pointer and there was effectively 20 bit addressing, for 1MB of addressable memory.
Ah, thanks for that. Yes, that's what I was remembering but you remembered it better:-)
FWIW, I suspect the "pointers" were probably called something like "logical addresses" or "linear addresses", I can't remember which... x86 has some funny addressing terminology of its own and I think those terms come up when talking about protected mode; I suspect they come up with a slightly different meaning in 8086 as well.
According to my x86 assembler teacher (this is the guy who taught us to time delays by calculating cycles and clock speed, so take it with a grain of salt), the idea was to allow programs to use hard-coded pointer values, while the segment would let the program be put wherever in memory it actually fit. I was taking x86 assembler from the EE department at the time, and when I asked my SPARC assembler teacher in the CS department how SPARC did it, he said that everything there used relative pointers.
For some reason I genuinely expected you to say "when I asked my SPARC teacher how that CPU did it, he laughed" - I suspect SPARC would have done something somewhat more sane from the start;-) That's only a guess though, maybe I'm being optimistic! SPARC has it's own crazy functionality, as do all chips but it's still hard to beat x86 for general across-the-board insanity (in my opinion!).
I turn 32 in three weeks. I should not be filling in details that were before everyone else's time.
It's quite nice to give this knowledge a dust off once in a while - it was really interesting to have this discussion even though I don't really need to know it.
A nice bit of trivia is that modern x86 processors support something called "big real mode". In real mode on an x86, you can only load segment descriptors that make sense in real mode. So it won't let you, for instance, load a segment descriptor that addresses memory above real mode's normal limit (1MB, I suppose from your description). However, you can switch to protected mode and load that segment descriptor, no problem, as it's valid there. The scary thing is that you can switch back to real mode and leave the segment descriptor in place - and it works, at least for some cases. Big real mode involves pulling that stunt so that you end up with real mode execution but able to access all the machine's memory. And apparently that's a feature, not a bug - some OSes / bootloaders actually expect this.
Anyhow, this stuff may be before everyone else's time. I'm turning 26 at around the time you turn 32 but I've had to grub through it a fair bit in the past few years. In another 10 years I expect either you and I will be sitting back and trying to explain to the young kids of today how computers used to be....... or, we'll still all be using some future x86 chips that will still support all this in hardware. I shudder to think!
I don't think it will probably help if I now remind you that all x86 CPUs, even your spiffy new multicore multi-GHz 64-bit gaming rig boot up believing they are an 8086. Your PC relives that memory management hell every time you switch it on until the software comes along and sets the "you're not a stupid old CPU" flag.
For this reason, it's important to remember not to touch the PC case whilst it's booting, otherwise you might get some real mode ectoplasm on you and be contaminated with insane memory models.
If you are stuck with the original Pentium or older then that is what happens. The Intel Pentium Pro, Pentium II, and whatever AMD and VIA came out with around the same time can address more memory than that. The problem you are describing is no solely due to software. There is much argument over who is responsible for drivers in the home and workstation versions of Microsoft operating systems being written in such a way as to make the full 4GB and above unusable - however MS Server 2003 and a variety of non-Microsoft operating systems do not have this problem at all due to having proper support of the Pentium Pro and later. That is where a misconception about "server grade" hardware creeps in when it's really about server grade software. I really do not understand why this behaviour was carried into 32 bit Vista since there was no requirement to run old drivers.
Actually, the problem I'm describing is specifically a hardware problem. There are similar issues involving software too but that's not the limitation in all cases...
Part of the problem is that it's a horrible confusing area. In my case, the chipset only allows the CPU 32-bit physical addresses, even though the CPU itself can support 36-bit through PAE support. That immediately means that the chipset can't map the PCI MMIO regions without losing some RAM, on a 4G machine. This is what shoots me in the foot, unfortunately.
Another hardware issue is that some cards can only DMA into certain parts of memory. This is particularly a problem with 32-bit PCI cards on machine with > 4G of memory. There are ways of working round this but they hurt performance.
The software issue I've run most often into is typically that if your OS doesn't support PAE then it can't handle more than a 4GB / 32-bit physical address space, so you can't support > 4GB RAM. In fact, due to the mapping of PCI MMIO regions into that low 4GB, if your OS can't do PAE you get a software problem of the original hardware problem I described above - the RAM can't be addressed by the OS even though it's there.
Overall it's a horribly complicated area that I've had to have a bit too much to do with in the past. That said, it's nice to dust off the knowledge for a discussion such as this once in a while! I'm glad I read this article now:-)
Also you can get to more than 4GB of memory in 32 bit mode using Intel's PAE mode, but that requires some app and os awareness. The apps are still limited to 4GB virtual address space though, it's just that the OS has more physical address space to locate the apps in.
An interesting hack I heard suggested by an AMD representative when AMD64 first came out: 32-bit legacy apps can access more memory, he said. This is unintuitive because the 32-bit apps are still stuck with 32-bit addressing and it took me a while to figure out what he meant.
It turned out that what he was advocating was that the 32-bit app could get the use of all of that 32-bit address space for itself because the kernel would not have to be mapped in that 32-bit address space with it. Tthat, as far as I can tell, is an artifact of the way they implemented 32-bit compatibility mode so it's not necessarily true for non-x86 architectures - I believe the kernel's mappings are high in the 64-bit address space, which the processor's compatibility mode renders invisible to the 32-bit app. If there's an interrupt or syscall, the transition back to kernel mode switches back to 64-bit mode and makes the kernel's permanent mappings visible again...
Anyhow, I'm not sure if getting a 32-bit app to use that extra virtual memory space actually required any library modifications or anything (it seemed to me like it might require modifications to the malloc implementation, for instance) - I don't really understand the implications to libc. However the idea was cool. Don't know if that behaviour is available on any systems, though...
The alternative on x86 is to use PSE (Page Size Extension, or something like that). AFAIK, this is not quite the same as "superpages", where a range of virtual memory backed by contiguous physical memory can be represented with an extra-large page to reduce pagetable size and TLB footprint. PSE (if I recall correctly) actually makes the basic page size for all pages on an x86 system bigger (2MB as opposed to 4KB, if I recall correctly).
The end result of the PSE pagetable structures is that it can also address a larger physical space (on IA32 this was the same size as PAE36, IIRC) but through a different mechanism. I can't say I've ever heard of PSE being used in this way though; commodity operating systems (Linux, Windows, FreeBSD, etc) all seem to use PAE. Still, the support is there.
Actually, I recall x86's real mode pages actually overlapped in the bus address ranges that they mapped to. So in this case number of pages * page size doesn't give total addressable real memory. Can't remember the actual numbers, however.
Second, the 640k limit was due to the video ram being mapped in the memory region between 640k and 1 MB, at address A000:0000. Which is why DOS extenders could get you that memory back in 386+, by remapping the memory to other addresses. Here's a memory map: http://www.infokomp.no/techinfo/doc/DosMemory.htm
Third, your 32bit/4GB ram stuff is garbage as well. Most OSs claim address space at the end (the upper 1/2GB) for the kernel. That makes it harder to use. It's not a hardware problem at all, OSs tend to have simplistic userland/kernel memory address space mappings. CPUs went to 64 bit before 4GB was cheap enough for this to be a problem, so no work was done to really reduce the kernel address space footprint (or to separate the address spaces altogether).
Actually, although what you say is true, the OP was also entirely correct in noting that hardware sometimes makes large regions of memory unavailable, even in relatively recent computers. The situation in question is independent of the OS memory model, although that has its own implications for memory use.
PCI memory mapped IO needs to be put somewhere at a physical address that the CPU is able to access. Although since the Pentium Pro it's been possible for x86 machines to address 36 bits of physical address space, some motherboards only actually give them 32 address lines to use.
If you stick 4GB of RAM in such a box then the memory mapped IO regions need to go somewhere that the CPU can still address them using only 32 address lines. Since the CPU has only 2^32 bytes = 4GB addressable this necessarily means that they have to alias real RAM regions. Those RAM regions are rendered inaccessible. There's nothing you can do to get them back, either - you can't remap them to a different place because you're limited by the 32 physical address lines. This is sometimes called a "memory hole".
This is compounded by the fact that some BIOSes are worse at allocating memory mapped IO spaces than others. They sometimes seem to use up hundreds of megabytes for these IO regions. I think that's more a case of the allocation policies being stupid than that quantity of addressable memory actually being needed. The problem isn't entirely trivial, though, since I think PCI devices can request certain alignments of their memory regions, so they can't just be placed anywhere.
Event 32-bit server grade hardware typically offers support for the CPU physically to address more than 32-bits of physical memory, enabling these systems to play games with remapping memory to make all 4G (or more) of RAM be accessible, whilst providing the necessary MMIO regions. Those of us who are using lower grade hardware (me, for instance!) are limited to smaller memory sizes by the motherboard, regardless of what the CPU chip and OS are capable of addressing.
I was not pleased when I discovered my own machines suffered from this "feature" but equally well I was pleased when I got this machine cheap. I guess you can't have everything!
I'd like to note that aside from the Core series of chips actually developing in terms of the microarchitecture, rather than just process shrinking an old design, the Atom is an all-new core from the ground up. It's a very different microarchitecture from the Core 2.
[quote]Is it possible that any mathematical function can evaluate itself,[/quote]
Well, a Turing Machine can simulate a Turing Machine. Moreover, any Turing Powerful means of computation can both simulate and be simulated by a Turing Machine..
Maybe we really have got to the stage where a cool-sounding concept and a pretty website is an indicator of an imaginary product... But a little research before publically labelling a young company a vapor vendor might be nice.
If you like the paradigm QT provides, then it's very very nice to program with, simple and powerful. KDE adds some infrastructure on top of that.
Functionally there's nothing your QT app will do that you couldn't make an Xlib app do; but functionally there's nothing you can make an Xlib app do that you can't make assembler running on the bare hardware without an OS do either... A large part of the "bloat" in QT/KDE is in implementing library functionality and abstraction layers for you so that you don't have to reinvent the wheel or open code common operations.
On top of that, the KDE libraries in particular add a load of powerful stuff, some of which is desktop-related; if you don't want to program desktop apps then you may as well just use QT.
I've played with QT from C++ and from Python and it was very pleasant in both languages. Python + QT is an awesome rapid development environment with the full power of Unix behind it.
> The third world needs a lot more than a cheap laptop. They have to figure out agriculture first!!!
Agriculture is an important aspect of a country's development. However, when talking about the OLPC project people often seem to forget that the 3rd world doesn't just consist of poor subsistence farmers, but also (for instance) poor manufacturing workers in sprawling cities. What about the children who grow up miles from affordable farmland? Or children who grow up in subsistence farming but would like to get a more skilled job to provide for their own children.
You're right of course that laptops shouldn't be prioritised above the basic needs for people to just survive. It's just that the 3rd world citizens who can provide their most basic needs and are already "just surviving" are sometimes left out of these discussions, but they're still legitimate candidates for this sort of aid. If the laptops are used to increase the welfare and education of citizens whilst their basic needs are provided for, this could be an awesome tool for world development. If governments start providing laptops at the expense of ensuring food supplies and sanitation, that would be very worrying.
Although the GPL gives RH some obligations, they go beyond the requirements therein. The key point is that: the GPL requires you to distribute source to people you distribute the binaries to. Red Hat goes beyond this by making their source available online to all, not just to RHEL customers (which is all they were strictly obliged to do). To the best of my knowledge, they make proper Source RPMs available (rather than a less convenient format from the point of view of rebuilders like CentOS) on their FTP servers and they do so at their own expense.
In short, RH go beyond mere due diligence and strict adherence to the GPL. They really do make an effort.
To me this looks like healthy symbiosis: CentOS don't name RH as their upstream, so they don't trade off Red Hat's advertising. Folks who want a free-as-in-beer OS weren't going to buy the RHEL license anyhow. But people who are used to CentOS will be more inclined to favour RHEL as a product. By creating a user community, it also stimulates the creation of repositories of RHEL-compatible third party RPM repositories. I doubt there'd be such a volume of RHEL-compatible RPMs (as currently provided by various CentOS repositories) if it wasn't for the existance of a freely available derivative of RHEL.
A combination of collaboration in development, free advertising, ease of customisation and mutual benefits, whilst still making money - sounds like a fine example of the Open Source game being played well, as long as they can make it pay for them long term!
The interesting point of your comment is that Veropedia leaches from Wikipedia, just like Ubuntu leaches from Debian. Ubuntu has only had a minimal positive impact on Debian, and I won't keep my hopes up that Veropedia will actually produce anything useful.
Well, I'd say it's not "just like" that. Ubuntu doesn't have a policy of implementing all improvements in the upstream source as part of the process of importing those improvements to Ubuntu. Veropedia apparently does, which means Wikipedia (should) automatically benefit from any useful work they do.
Your analogy is only valid as long as Veropedia is sponsored by a space-loving billionaire. Canonical is nowhere near break-even, and likely never will be.
Well, I'd say it's equally valid when applied to e.g. Debian as the downstream of Linux + glibc + gcc + openssh... The point I really wanted to make was that having a downstream distributor of code / media / encyclopedia articles isn't an inherently bad thing if they produce some kind of value-add and they act as good citizens in contributing appropriate resources (information, proof reading, bugfixes, server hardware, new users) to the upstream. It's possible in principle for both sides to benefit and we've already seen this happen in OSS software many times.
Of course, whether Veropedia live up to their lofty claims or turn out to be leeches and bad citizens (or even whether they're successful longterm or not) still remains to be seen. But I think the idea of downstream "distributions" based on wikipedia should eventually be sustainable and beneficial to both end-users and the wikipedia upstream.
In summary, what I really meant to say was: leeches are inherent in Free information, be it software projects or an encyclopedia. But what you get in compensation (aside from freely available information) is the potential to specialise and collaborate on that information with other parties who have different goals. This is what Linux distributors do for the upstream code, and it's what I hope we'll see people doing with wikipedia. Maybe I'm just an idealist, but I think it's doable - a guy can dream;-)
Whilst the concerns that Veropedia are just vampires / leeches who will suck the goodness from Wikipedia for their own profit, I'd like to suggest an alternative point of view. I'm going to set out my viewpoint in some detail, so please indulge me and bear with me;)
As I write this, I'm using Kubuntu. It's made by a for-profit corporation (Canonical) who have pieced together a number of GNU (and other) licensed packages that were freely available to create a distribution. And people love it, they rave about it.
It does the job people want from an OS.
Sure, you could piece this stuff all together yourself. You could gather all the pieces of software you need, you could build them. You could check for outstanding bugs and backport fixes from the CVS version. You could integrate them nicely together to create a useable system. You could create an installable live CD to whack this down onto your computers when required. And you could continue to monitor all the upstream Free-licensed packages you've used to backport further security updates and bugfixes. But who wants to do all that work? The Free-licensed upstream is there alright - and it's valuable that you could access it directly - that anybody could do this if they wanted to, or if they needed to. But getting all the upstream packages in a good state; doing QA on them; checking they all work well together - that's a lot of work that you don't want to do unless you have specific needs. Thanks to the efforts of Canonical, I largely don't need to deal with upstream. If I want, I can send them patches, compile new versions from CVS, etc - but mostly I just leave the minutiae to the package maintainers.
The beauty of it is, If I don't like the job they do, I can still go upstream. I'm still Free because everything I'm using is open to me. I'm just getting someone else to do the grunt work. If they don't do a good enough job for me, I have options. I can choose to do it myself - I can compile apps on my Ubuntu system if I don't like the Ubuntu packages. I can build my own distro from scratch. Or I can switch to another distribution. I could switch to OpenSuse, say - it's also put together largely by a corporation in a similar manner. Or I could switch to something largely community driven like Debian. They have different focuses: up-to-date vs very strictly QA-ed, general purpose vs specialised. I'm spoilt for choice!
What's this got to do with Wikipedia vs Veropedia? Well, how about we substitute "package" with "article"? Wikipedia is the "upstream" provider of Free licensed content. What people are calling "vampire" sites are actually distributions of Wikipedia, just as Ubuntu is a distribution of GNU/Linux and related code. Some of them are just repackaging Wikipedia content in a more-or-less friendly UI and raising money through advertising. They have the right to do that, just as they have the right not to contribute anything back upstream themselves: the Free licenses don't force you to be a very good citizen. This situation is familiar from Free Software - we might not all approve of Xandros or Novell's deals with MS but they're still free to use the Free code as long as they stick to the license.
Which brings us to Veropedia. It's a new up-and-coming distribution of Wikipedia. It's small at the moment but growing. They're taking Wikipedia content and attempting to add value by doing some of the QA and integration work themselves, rather than leaving you to do it: they're trying to ensure quality articles are immediately available to users, without their having to check references, do mental sanity checks on the information, be generally skeptical. Just like the Linux distributions, they're doing some of the work that Freedom allows you to do, on your behalf. They're taking something you could already get for Free and they're making money (from ads in this case) in order to cover their costs - but they're trying to add something on the way. Doe
Why would one assert that the NIV is a "superiour" translation? The King James Version was the dominant guide to Christian thought for English speaking people for more than 300 years. It would be curious to argue that the people who adhered to the guidance in the King James version were not (and are not) "inferiour" Christians to those who now use the New International Version which has only existed for (almost) the past 30 years. Given the short history of this new translation, its value, for better of for worse, is yet to be proven. I'd argue there's a case for judging whether something is a "superior" translation strictly on the basis of the quality of source materials available for the translator to work with (more direct translation vs a translation of a translation of a...) and better understanding of the nuances of ancient language that are made possible by more recent academic research. I'd say this is fairly independent of how the book was received as a religious text. It doesn't necessarily mean that the people who used that translation were inferior Christians but it may mean the texts they were using corresponded less closely to the older versions in ancient languages.
Whether the quality of the translation in terms of closeness to the original actually matters to the KJV as a holy book will doubtless be debated. I have friends who are convinced that the KJV is the one correct translation and I imagine they believe this on the basis of the content and on the basis of how they've been taught to interpret it - independently of what translators may describe as being technically the best. I'd say that it rather depends whether you believe you should follow the original texts as best understood academically, or whether you believe in a specific interpretation of the texts which you may feel to be superior spiritually somehow.
Personally I think it's very important to realise that all translations are likely imperfect, but that alternative translations could offer valuable insights into the subject matter and the process of how modern versions were arrived at.
It'd be awesome if you could get direct access to the acoustic pickups and connect them to the guitar's output for a warm, natural sound. You've long been able to purchase piezo-based acoustic pickups as an add-on - if they're adding these pickups for tuning purposes anyhow, why not connect them to the output too? That said, maybe it would sound funny; acoustic pickups are usually attached to the guitar body to pick up the resonance - looks like maybe these are built into the bridge so that they can sense individual strings; probably wouldn't sound so good, I guess.
*however* since they can accurately detect the frequency of each string individually *anyhow* another obvious thing to do would be to drive a MIDI synth. Again, connecting a pickup for a MIDI system is often ugly, involving a great big pickup being stuck to the body under the strings. It'd be much nicer if this sort of thing could be integrated. Really, it'd be nice to see a more modular approach taken to guitar electronics - even a PC-style approach (!!! I just said that?). If a bit of spare space could be provided in the body to fit a few modules that connect to the conventional or acoustic pickups, it'd be easy to "upgrade" your guitar to acoustic / midi / whatever outputs.
It's interesting to see a large traditional manufacturer taking on a task like this. Their instruments already command such a large premium that the cost involved isn't prohibitive. I must say I'm surprised to see Gibson taking on this task as opposed to one of the more progressive companies (Parker, Steinburger, and other purveyors of space-age looking guitars). Not many people realise, due to their modern image, but the most popular electric guitar designs are about fifty years old and so were in existence before many of our favourite rock stars were out of short pants.
It's awful that you had to go through that experience. I can't even imagine how you must have felt, but you have my deepest sympathies. Please take no notice of the anonymous replies to your comment - they're really not even worth reading. Some idiots actually think they're being clever by displaying their ignorance.
I'm no doctor, but I guess this technology would not be suitable for use in all cases, and that some patients still require more conventional treatment by other means - but hopefully that will keep advancing too. It's amazing to see progress like this being made in medicine and I too hope that it can help many more people.
I extend my sincere condolences for your loss and my best wishes for you.
Slashdot Mirror
Seriously, when the editor of a site that bears advertising gratuitously trolls the readership (as opposed to raising legitimate alternate views, playing devil's advocate, suggesting topics for discussion) it does look like they're trying to generate more ad revenue through bad journalism. The editors aren't under any obligation to not submit trollish arcticles. The readers aren't under any obligation not to block ads when browsing those threads. Just a thought...
Ah, thanks for that. Yes, that's what I was remembering but you remembered it better :-)
FWIW, I suspect the "pointers" were probably called something like "logical addresses" or "linear addresses", I can't remember which... x86 has some funny addressing terminology of its own and I think those terms come up when talking about protected mode; I suspect they come up with a slightly different meaning in 8086 as well.
According to my x86 assembler teacher (this is the guy who taught us to time delays by calculating cycles and clock speed, so take it with a grain of salt), the idea was to allow programs to use hard-coded pointer values, while the segment would let the program be put wherever in memory it actually fit. I was taking x86 assembler from the EE department at the time, and when I asked my SPARC assembler teacher in the CS department how SPARC did it, he said that everything there used relative pointers.For some reason I genuinely expected you to say "when I asked my SPARC teacher how that CPU did it, he laughed" - I suspect SPARC would have done something somewhat more sane from the start ;-) That's only a guess though, maybe I'm being optimistic! SPARC has it's own crazy functionality, as do all chips but it's still hard to beat x86 for general across-the-board insanity (in my opinion!).
I turn 32 in three weeks. I should not be filling in details that were before everyone else's time.It's quite nice to give this knowledge a dust off once in a while - it was really interesting to have this discussion even though I don't really need to know it.
A nice bit of trivia is that modern x86 processors support something called "big real mode". In real mode on an x86, you can only load segment descriptors that make sense in real mode. So it won't let you, for instance, load a segment descriptor that addresses memory above real mode's normal limit (1MB, I suppose from your description). However, you can switch to protected mode and load that segment descriptor, no problem, as it's valid there. The scary thing is that you can switch back to real mode and leave the segment descriptor in place - and it works, at least for some cases. Big real mode involves pulling that stunt so that you end up with real mode execution but able to access all the machine's memory. And apparently that's a feature, not a bug - some OSes / bootloaders actually expect this.
Anyhow, this stuff may be before everyone else's time. I'm turning 26 at around the time you turn 32 but I've had to grub through it a fair bit in the past few years. In another 10 years I expect either you and I will be sitting back and trying to explain to the young kids of today how computers used to be ....... or, we'll still all be using some future x86 chips that will still support all this in hardware. I shudder to think!
Just quit sleeping, it'll be fine ;-)
I don't think it will probably help if I now remind you that all x86 CPUs, even your spiffy new multicore multi-GHz 64-bit gaming rig boot up believing they are an 8086. Your PC relives that memory management hell every time you switch it on until the software comes along and sets the "you're not a stupid old CPU" flag.
For this reason, it's important to remember not to touch the PC case whilst it's booting, otherwise you might get some real mode ectoplasm on you and be contaminated with insane memory models.
PS, don't have nightmares.
If you are stuck with the original Pentium or older then that is what happens. The Intel Pentium Pro, Pentium II, and whatever AMD and VIA came out with around the same time can address more memory than that. The problem you are describing is no solely due to software. There is much argument over who is responsible for drivers in the home and workstation versions of Microsoft operating systems being written in such a way as to make the full 4GB and above unusable - however MS Server 2003 and a variety of non-Microsoft operating systems do not have this problem at all due to having proper support of the Pentium Pro and later. That is where a misconception about "server grade" hardware creeps in when it's really about server grade software. I really do not understand why this behaviour was carried into 32 bit Vista since there was no requirement to run old drivers.
Actually, the problem I'm describing is specifically a hardware problem. There are similar issues involving software too but that's not the limitation in all cases...
Part of the problem is that it's a horrible confusing area. In my case, the chipset only allows the CPU 32-bit physical addresses, even though the CPU itself can support 36-bit through PAE support. That immediately means that the chipset can't map the PCI MMIO regions without losing some RAM, on a 4G machine. This is what shoots me in the foot, unfortunately.
Another hardware issue is that some cards can only DMA into certain parts of memory. This is particularly a problem with 32-bit PCI cards on machine with > 4G of memory. There are ways of working round this but they hurt performance.
The software issue I've run most often into is typically that if your OS doesn't support PAE then it can't handle more than a 4GB / 32-bit physical address space, so you can't support > 4GB RAM. In fact, due to the mapping of PCI MMIO regions into that low 4GB, if your OS can't do PAE you get a software problem of the original hardware problem I described above - the RAM can't be addressed by the OS even though it's there.
Overall it's a horribly complicated area that I've had to have a bit too much to do with in the past. That said, it's nice to dust off the knowledge for a discussion such as this once in a while! I'm glad I read this article now :-)
An interesting hack I heard suggested by an AMD representative when AMD64 first came out: 32-bit legacy apps can access more memory, he said. This is unintuitive because the 32-bit apps are still stuck with 32-bit addressing and it took me a while to figure out what he meant.
It turned out that what he was advocating was that the 32-bit app could get the use of all of that 32-bit address space for itself because the kernel would not have to be mapped in that 32-bit address space with it. Tthat, as far as I can tell, is an artifact of the way they implemented 32-bit compatibility mode so it's not necessarily true for non-x86 architectures - I believe the kernel's mappings are high in the 64-bit address space, which the processor's compatibility mode renders invisible to the 32-bit app. If there's an interrupt or syscall, the transition back to kernel mode switches back to 64-bit mode and makes the kernel's permanent mappings visible again...
Anyhow, I'm not sure if getting a 32-bit app to use that extra virtual memory space actually required any library modifications or anything (it seemed to me like it might require modifications to the malloc implementation, for instance) - I don't really understand the implications to libc. However the idea was cool. Don't know if that behaviour is available on any systems, though...
The end result of the PSE pagetable structures is that it can also address a larger physical space (on IA32 this was the same size as PAE36, IIRC) but through a different mechanism. I can't say I've ever heard of PSE being used in this way though; commodity operating systems (Linux, Windows, FreeBSD, etc) all seem to use PAE. Still, the support is there.
Actually, I recall x86's real mode pages actually overlapped in the bus address ranges that they mapped to. So in this case number of pages * page size doesn't give total addressable real memory. Can't remember the actual numbers, however.
Second, the 640k limit was due to the video ram being mapped in the memory region between 640k and 1 MB, at address A000:0000. Which is why DOS extenders could get you that memory back in 386+, by remapping the memory to other addresses. Here's a memory map: http://www.infokomp.no/techinfo/doc/DosMemory.htm Third, your 32bit/4GB ram stuff is garbage as well. Most OSs claim address space at the end (the upper 1/2GB) for the kernel. That makes it harder to use. It's not a hardware problem at all, OSs tend to have simplistic userland/kernel memory address space mappings. CPUs went to 64 bit before 4GB was cheap enough for this to be a problem, so no work was done to really reduce the kernel address space footprint (or to separate the address spaces altogether).Actually, although what you say is true, the OP was also entirely correct in noting that hardware sometimes makes large regions of memory unavailable, even in relatively recent computers. The situation in question is independent of the OS memory model, although that has its own implications for memory use.
PCI memory mapped IO needs to be put somewhere at a physical address that the CPU is able to access. Although since the Pentium Pro it's been possible for x86 machines to address 36 bits of physical address space, some motherboards only actually give them 32 address lines to use.
If you stick 4GB of RAM in such a box then the memory mapped IO regions need to go somewhere that the CPU can still address them using only 32 address lines. Since the CPU has only 2^32 bytes = 4GB addressable this necessarily means that they have to alias real RAM regions. Those RAM regions are rendered inaccessible. There's nothing you can do to get them back, either - you can't remap them to a different place because you're limited by the 32 physical address lines. This is sometimes called a "memory hole".
This is compounded by the fact that some BIOSes are worse at allocating memory mapped IO spaces than others. They sometimes seem to use up hundreds of megabytes for these IO regions. I think that's more a case of the allocation policies being stupid than that quantity of addressable memory actually being needed. The problem isn't entirely trivial, though, since I think PCI devices can request certain alignments of their memory regions, so they can't just be placed anywhere.
Event 32-bit server grade hardware typically offers support for the CPU physically to address more than 32-bits of physical memory, enabling these systems to play games with remapping memory to make all 4G (or more) of RAM be accessible, whilst providing the necessary MMIO regions. Those of us who are using lower grade hardware (me, for instance!) are limited to smaller memory sizes by the motherboard, regardless of what the CPU chip and OS are capable of addressing.
I was not pleased when I discovered my own machines suffered from this "feature" but equally well I was pleased when I got this machine cheap. I guess you can't have everything!
I'd like to note that aside from the Core series of chips actually developing in terms of the microarchitecture, rather than just process shrinking an old design, the Atom is an all-new core from the ground up. It's a very different microarchitecture from the Core 2.
There, fixed that for you.
[quote]Is it possible that any mathematical function can evaluate itself,[/quote] Well, a Turing Machine can simulate a Turing Machine. Moreover, any Turing Powerful means of computation can both simulate and be simulated by a Turing Machine..
http://blogs.technet.com/hhh_comic/default.aspx
Maybe we really have got to the stage where a cool-sounding concept and a pretty website is an indicator of an imaginary product... But a little research before publically labelling a young company a vapor vendor might be nice.
If you like the paradigm QT provides, then it's very very nice to program with, simple and powerful. KDE adds some infrastructure on top of that.
Functionally there's nothing your QT app will do that you couldn't make an Xlib app do; but functionally there's nothing you can make an Xlib app do that you can't make assembler running on the bare hardware without an OS do either... A large part of the "bloat" in QT/KDE is in implementing library functionality and abstraction layers for you so that you don't have to reinvent the wheel or open code common operations.
On top of that, the KDE libraries in particular add a load of powerful stuff, some of which is desktop-related; if you don't want to program desktop apps then you may as well just use QT.
I've played with QT from C++ and from Python and it was very pleasant in both languages. Python + QT is an awesome rapid development environment with the full power of Unix behind it.
> The third world needs a lot more than a cheap laptop. They have to figure out agriculture first!!!
Agriculture is an important aspect of a country's development. However, when talking about the OLPC project people often seem to forget that the 3rd world doesn't just consist of poor subsistence farmers, but also (for instance) poor manufacturing workers in sprawling cities. What about the children who grow up miles from affordable farmland? Or children who grow up in subsistence farming but would like to get a more skilled job to provide for their own children.
You're right of course that laptops shouldn't be prioritised above the basic needs for people to just survive. It's just that the 3rd world citizens who can provide their most basic needs and are already "just surviving" are sometimes left out of these discussions, but they're still legitimate candidates for this sort of aid. If the laptops are used to increase the welfare and education of citizens whilst their basic needs are provided for, this could be an awesome tool for world development. If governments start providing laptops at the expense of ensuring food supplies and sanitation, that would be very worrying.
In short, RH go beyond mere due diligence and strict adherence to the GPL. They really do make an effort.
To me this looks like healthy symbiosis: CentOS don't name RH as their upstream, so they don't trade off Red Hat's advertising. Folks who want a free-as-in-beer OS weren't going to buy the RHEL license anyhow. But people who are used to CentOS will be more inclined to favour RHEL as a product. By creating a user community, it also stimulates the creation of repositories of RHEL-compatible third party RPM repositories. I doubt there'd be such a volume of RHEL-compatible RPMs (as currently provided by various CentOS repositories) if it wasn't for the existance of a freely available derivative of RHEL.
A combination of collaboration in development, free advertising, ease of customisation and mutual benefits, whilst still making money - sounds like a fine example of the Open Source game being played well, as long as they can make it pay for them long term!
Never has that program name been so fitting.
There, fixed that for you.
Well I did something very interesting with quote tags there. Ah well :) I hope somebody finds it worth while to puzzle through all the blocking :-)
Well, I'd say it's not "just like" that. Ubuntu doesn't have a policy of implementing all improvements in the upstream source as part of the process of importing those improvements to Ubuntu. Veropedia apparently does, which means Wikipedia (should) automatically benefit from any useful work they do.
Your analogy is only valid as long as Veropedia is sponsored by a space-loving billionaire. Canonical is nowhere near break-even, and likely never will be.Well, I'd say it's equally valid when applied to e.g. Debian as the downstream of Linux + glibc + gcc + openssh ... The point I really wanted to make was that having a downstream distributor of code / media / encyclopedia articles isn't an inherently bad thing if they produce some kind of value-add and they act as good citizens in contributing appropriate resources (information, proof reading, bugfixes, server hardware, new users) to the upstream. It's possible in principle for both sides to benefit and we've already seen this happen in OSS software many times.
Of course, whether Veropedia live up to their lofty claims or turn out to be leeches and bad citizens (or even whether they're successful longterm or not) still remains to be seen. But I think the idea of downstream "distributions" based on wikipedia should eventually be sustainable and beneficial to both end-users and the wikipedia upstream.
In summary, what I really meant to say was: leeches are inherent in Free information, be it software projects or an encyclopedia. But what you get in compensation (aside from freely available information) is the potential to specialise and collaborate on that information with other parties who have different goals. This is what Linux distributors do for the upstream code, and it's what I hope we'll see people doing with wikipedia. Maybe I'm just an idealist, but I think it's doable - a guy can dream ;-)
As I write this, I'm using Kubuntu. It's made by a for-profit corporation (Canonical) who have pieced together a number of GNU (and other) licensed packages that were freely available to create a distribution. And people love it, they rave about it.
It does the job people want from an OS.
Sure, you could piece this stuff all together yourself. You could gather all the pieces of software you need, you could build them. You could check for outstanding bugs and backport fixes from the CVS version. You could integrate them nicely together to create a useable system. You could create an installable live CD to whack this down onto your computers when required. And you could continue to monitor all the upstream Free-licensed packages you've used to backport further security updates and bugfixes. But who wants to do all that work? The Free-licensed upstream is there alright - and it's valuable that you could access it directly - that anybody could do this if they wanted to, or if they needed to. But getting all the upstream packages in a good state; doing QA on them; checking they all work well together - that's a lot of work that you don't want to do unless you have specific needs. Thanks to the efforts of Canonical, I largely don't need to deal with upstream. If I want, I can send them patches, compile new versions from CVS, etc - but mostly I just leave the minutiae to the package maintainers.
The beauty of it is, If I don't like the job they do, I can still go upstream. I'm still Free because everything I'm using is open to me. I'm just getting someone else to do the grunt work. If they don't do a good enough job for me, I have options. I can choose to do it myself - I can compile apps on my Ubuntu system if I don't like the Ubuntu packages. I can build my own distro from scratch. Or I can switch to another distribution. I could switch to OpenSuse, say - it's also put together largely by a corporation in a similar manner. Or I could switch to something largely community driven like Debian. They have different focuses: up-to-date vs very strictly QA-ed, general purpose vs specialised. I'm spoilt for choice!
What's this got to do with Wikipedia vs Veropedia? Well, how about we substitute "package" with "article"? Wikipedia is the "upstream" provider of Free licensed content. What people are calling "vampire" sites are actually distributions of Wikipedia, just as Ubuntu is a distribution of GNU/Linux and related code. Some of them are just repackaging Wikipedia content in a more-or-less friendly UI and raising money through advertising. They have the right to do that, just as they have the right not to contribute anything back upstream themselves: the Free licenses don't force you to be a very good citizen. This situation is familiar from Free Software - we might not all approve of Xandros or Novell's deals with MS but they're still free to use the Free code as long as they stick to the license.
Which brings us to Veropedia. It's a new up-and-coming distribution of Wikipedia. It's small at the moment but growing. They're taking Wikipedia content and attempting to add value by doing some of the QA and integration work themselves, rather than leaving you to do it: they're trying to ensure quality articles are immediately available to users, without their having to check references, do mental sanity checks on the information, be generally skeptical. Just like the Linux distributions, they're doing some of the work that Freedom allows you to do, on your behalf. They're taking something you could already get for Free and they're making money (from ads in this case) in order to cover their costs - but they're trying to add something on the way. Doe
Whether the quality of the translation in terms of closeness to the original actually matters to the KJV as a holy book will doubtless be debated. I have friends who are convinced that the KJV is the one correct translation and I imagine they believe this on the basis of the content and on the basis of how they've been taught to interpret it - independently of what translators may describe as being technically the best. I'd say that it rather depends whether you believe you should follow the original texts as best understood academically, or whether you believe in a specific interpretation of the texts which you may feel to be superior spiritually somehow.
Personally I think it's very important to realise that all translations are likely imperfect, but that alternative translations could offer valuable insights into the subject matter and the process of how modern versions were arrived at.
It'd be awesome if you could get direct access to the acoustic pickups and connect them to the guitar's output for a warm, natural sound. You've long been able to purchase piezo-based acoustic pickups as an add-on - if they're adding these pickups for tuning purposes anyhow, why not connect them to the output too? That said, maybe it would sound funny; acoustic pickups are usually attached to the guitar body to pick up the resonance - looks like maybe these are built into the bridge so that they can sense individual strings; probably wouldn't sound so good, I guess.
*however* since they can accurately detect the frequency of each string individually *anyhow* another obvious thing to do would be to drive a MIDI synth. Again, connecting a pickup for a MIDI system is often ugly, involving a great big pickup being stuck to the body under the strings. It'd be much nicer if this sort of thing could be integrated. Really, it'd be nice to see a more modular approach taken to guitar electronics - even a PC-style approach (!!! I just said that?). If a bit of spare space could be provided in the body to fit a few modules that connect to the conventional or acoustic pickups, it'd be easy to "upgrade" your guitar to acoustic / midi / whatever outputs.
It's interesting to see a large traditional manufacturer taking on a task like this. Their instruments already command such a large premium that the cost involved isn't prohibitive. I must say I'm surprised to see Gibson taking on this task as opposed to one of the more progressive companies (Parker, Steinburger, and other purveyors of space-age looking guitars). Not many people realise, due to their modern image, but the most popular electric guitar designs are about fifty years old and so were in existence before many of our favourite rock stars were out of short pants.
It's awful that you had to go through that experience. I can't even imagine how you must have felt, but you have my deepest sympathies. Please take no notice of the anonymous replies to your comment - they're really not even worth reading. Some idiots actually think they're being clever by displaying their ignorance.
I'm no doctor, but I guess this technology would not be suitable for use in all cases, and that some patients still require more conventional treatment by other means - but hopefully that will keep advancing too. It's amazing to see progress like this being made in medicine and I too hope that it can help many more people.
I extend my sincere condolences for your loss and my best wishes for you.
Sincerely,
Mark Williamson
heh - no, just kidding
Yep, confirmed - I just tried this and was surprised to see it worked fine.