I think you missed the enormous amount of work done to try and optimize the ELF linking process on Linux. Profiles of OpenOffice startup showed that the majority of its time was spent inside the dynamic linker. It's no fantasy to say that shared libraries have a cost.
Because it doesn't work. Microsoft did actually try that approach in the (much more disruptive) shift from Win16 to Win32 - they literally ran an emulated DOS/Windows 3.1 in a box inside Windows 95. The problem is that everybody hated it. Nothing worked properly - drag and drop didn't work. Window management was duplicated. Copy and paste didn't work.
Eventually, they realised that what customers actually wanted was seamless integration. So they provided the new API and the old API side by side, with lots of thunks and integration glue to make them feel like one operating system. The approach was amazingly successful and Windows 95 went on to be a best selling product.
Apple did something similar to the first approach. Everybody hated it. The very, very few companies that still made software for MacOS were pressured by Apple and a zealous fan base to rewrite their app so they could avoid Classic. Versions of the old APIs were supplied to try and make the transition easy, but basically it involved a ton of work to get lickable buttons and no new functionality.
The reason it didn't kill MacOS entirely is simple - nobody used OS 9 anymore. Certainly, they didn't use it for business beyond maybe a few holdouts in the graphics department. Nobody was going to complain about the need to upgrade their line-of-business software, or their CAD/CAM software, or their old educational games, because the only people left on MacOS 9 were people who would use Macs until the day they died whatever the cost.
Microsoft has already designed a new OS. It runs in parallel to the regular OS and only relies on the Windows kernel for boring things like file, network and graphics IO that are unlikely to be very different in a rewritten OS. Other than that, apps run against fresh, modern APIs, they have access to advanced facilities. This new OS is processor-independent, has a much improved widget toolkit and excellent developer tools. Its name is.NET/Avalon, and nobody runs apps written with it on the desktop, because ultimately the most compelling desktop software has already been written and evolved over many years. The Photoshops and Microsoft Offices of this world are giant collections of code based on legacy technologies, but they're what users want to run and the value of an OS that can't do that well is extremely low as a result.
That's why, if Microsoft are smart, they won't bother with some new modular refactoring of Windows that isn't compatible with the old one. They did it once already and did a great job, but the impact it had on the desktop market was low.
You misread my post. I said that for desktop applications Java and C# suck rocks. Name me one popular retail desktop application written in Java, that isn't actually related to Java programming in some way. I can't think of any. I quite agree that Java and C# are excellent languages, the right tool for certain domains. But trying to write any serious desktop app in Java is an exercise in pain. The IBM guys managed it with Eclipse, but only by writing a replacement for the entire Java widget toolkit - and it still has "issues" with memory management.
C++ isn't going anywhere. Nearly all serious desktop software outside of Mac-land is written in it because the alternatives (Java? C#?) suck rocks. Large amounts of high performance code is written in C++. I don't know where you got the idea that people who care about performance use C from, that's flat wrong in my experience. I agree that D is a very nice language. It will make great strides in the next five yeras. However, maturity counts for a lot.
My university course spent about half an hour on pointers in a 3 year course. Most of that half hour was factually wrong: the slides were full of code samples that wouldn't compile or would always crash.
They did, however, spend two terms teaching Hoare logic. Or rather, they spent one term teaching it, and then repeated the same material in another term with a different lecturer, because their communication was so poor they never realised they had duplicated their teching.
Friends at other universities reported similar stupidities, though not always on the same scale.
C++ is a rather complex language, but simplifying it won't help. The problem is that low quality education is rampant.
The students viewed images of women on a computer screen and had to categorize each as friendly, sexually interested, sad or rejecting. Each student reported on 280 photographs, which had been sorted previously into one of the categories based on surveys completed by different groups of students.
Wow, that's the most stupid piece of research I ever saw. Not only are they generalizing from a bunch of 20 year olds to "all guys", but the scientific measurement involves trying to derive clues from static photos. Given how much body language is related to motion, timing and so on I'm not really surprised that they found it hard. I'd be interested to know how strong this guys < girls finding really is. Also, if the results change when the photos are replaced with short films... or even actors:)
The students viewed images of women on a computer screen and had to categorize each as friendly, sexually interested, sad or rejecting. Each student reported on 280 photographs, which had been sorted previously into one of the categories based on surveys completed by different groups of students.
Wow, that's the most stupid piece of research I ever saw. Not only are they generalizing from a bunch of 20 year olds to "all guys", but the scientific measurement involves trying to derive clues from static photos. Given how much body language is related to motion, timing and so on I'm not really surprised that they found it hard. I'd be interested to know how strong this guys
I'm not sure what you mean. Windows doesn't use ELF. Its PE format works in a very similar fashion though (scoping aside). They both require that all symbols are available at the startup of the program unless they are lazy linked, but that's an optimisation and using it to delay load code is rather dangerous. Could you give more details?
I'd be surprised if that was the real problem. Assemblies aren't encrypted, nothing stops Mono from just ignoring the signature.
If I had to guess, I'd say the.NET policy is a result of fighting DLL hell for so many years. Modularity based on interfaces is a great principle, and is taught in practically every CS class. It tends to fall over and die when writing something with as many users as an operating system component, because there are too many subtle details users come to rely on which aren't encoded in the interface. Random example: for a function that returns a list, is it sorted or not? Often such things are undocumented. Perhaps it's sorted in version 1 because of how the component was implemented, but isn't in version 2. Whoops, you just broke any program that does a binary search on the result.
If you have 20 users, chances of that being a problem are low. If you have 20 million (easy ballpark figure for Windows) you just broke 100,000 programs and some giant corporation is screaming down the phone at you, asking why your OS upgrade is such a pile of shit.
Linking against exactly the version of the library you tested against is inefficient and prevents incremental bug fixes but is great for stability. Actually.NET doesn't force exact linking, I just read on MSDN that you can redirect assemblies to newer versions if you want, the trick being that it's done with config files at the app or machine level rather than replacing the library on disk as with traditional DLLs.
Actually it's not that great for admin staff (well, it might be, depending on your IT departments policies). At Google it's a major pain for our admin staff, because developers often require or want the latest Firefox for testing against. We use Ubuntu as it's the long term supported edition and thus there are typically not backports for the software we want anymore. It has to be done in house. This is a giant timesuck, and a problem that does not exist on Windows or OS X. This is especially true for Firefox 3 which requires an entirely new GTK stack. Dapper is less than two years old!
It's rare to encounter if you only install software from your distribution, because typically, people will hack around it or simply force everything to compile against the same version of the library. I documented this problem a few years ago: here's a relevant GCC bug and if you want a slightly easier to read explanation read this doc I wrote on writing shared libraries and search for "scoping".
The long and short of it is that in ELF, every symbol exported by a shared library (including internal symbols if you aren't careful!) exists in a global scope. Imagine you have a function called "clear()" defined in your program. Not so unlikely, right? Now imagine that you link against libfoo.so.1, which in turns uses libncurses to implement some of its functionality. Well, now you have a problem. It turns out that the ncurses API dates from before the time when prefixing function names with the library name was common in UNIX, and it also defines a function called clear. In any sane operating system (like Windows - gasp) this is not a problem. Your program doesn't use ncurses directly, so there's no conflict there. And libfoo is not linked "backwards" against your program either. So when libfoo invokes clear(), control should be transferred to libncurses.
However, that's not what happens. What actually happens is that libfoo jumps into your program and then crashes with stack corruption, because clear() was defined there first. The fact that libfoos ELF headers state that it depends on libncurses will cause ncurses to be loaded into memory, but not actually used for this function.
To put it mildly, this is not what most developers expect. The example above may seem contrived, but a far more common case is when a program indirectly uses two versions of the same library. This is what happens when you use mozilla.org provided Firefox binaries. Then, Firefox from upstream is compiled against libstdc++.so.5, because it's more widely available. Firefox loads some plugin.... for instance maybe it loads SCIM if you want to type Chinese as part of the GTK+ input methods framework.... which in turn loads something else written in C++.... which in turn loads libstdc++.so.6 - well, now you lose, because you have the same library defining symbols with different names. The OS has sufficient information to pick the right one, but doesn't, because of the general way in which binary loading on Linux works.
For the specific case of libstdc++ this is "fixed" by using symbol versions which are basically a gross hack... they make the risk of name collisions less likely but do not eliminate them. Except that it wasn't actually fixed, as that bug describes. This is a general problem that affects all libraries on ELF based platforms.
I wouldn't call the bizarre mess of the MacOS kernel "modular". It's certainly not a micro-kernel, if that's what you mean.
All the mainstream operating systems today are somewhat modular, in that you can swap components in and out if they implement the same interface. This is especially true for Windows, in which long-term heavy usage of COM (which was explicitly designed to promote modularity) has meant that you can do things like swap out the IE rendering engine for Firefox, and it'll work. Well, assuming that Firefox supports the features the embedding app in question needs, of course. If you doubt this, feel free to download the Gecko ActiveX plugin and try it... most apps use IE just as a convenient rendering engine and can run when Gecko replaces it.
That might not sound impressive, but try swapping out Gecko for WebKit or Opera on Linux and see what a mess you get into. Hell, just try upgrading Firefox on Ubuntu. You will almost certainly fail. I know, because I've tried it. About the only sane way forward is to leave the old version in place and install a new, parallel copy - but that has its own problems due to general brokenness in the way ELF was designed (it doesn't seal off shared libraries from each other properly, so they can interfere and cause crashes). Although to be fair, Linux (really, unix) does let you swap out your display subsystem for another one thanks to X. So they all have strengths and weaknesses in this area.
I'm not really sure why you think Apple has "specced out its software at a maximum consistent level". Dealing with missing features is just a part of the software development game, and Apple supports that with what they call weak symbols. It's important because not everybody upgrades their OS at once, so even if you only have one edition of your operating system, developers still need to adapt at runtime to things that are missing. The piss-poor support for this in Linux is another reason upgrades are so flaky (it's only done at compile time for most programs).
I'll be interested to see what Windows 7 actually ends up being. I suspect that this whole modularity drive is coming from upper management somewhere, and by the time it reaches the engineers they will say "well.... but windows is already modular!". They'll make some token gestures, clean up some cruft that users won't really notice except in worse app compatibility, marketing will trumpet the changes as meaning that things will Really Be Different This Time! and nothing will really change.
Hey Doc. I work on Maps and sometimes debug weird customer-reported problems like this.
Here's The Real Mikes three step guide to diagnosing and fixing Google Maps problems:
Create a new browser profile, using "firefox -ProfileManager". This effectively clears your cache, cookies, extensions and other settings that can interfere with maps. Does it work? If so, go back to your main profile and (in this order): clear your cache, delete your google.com cookies, revert any changed settings (especially network settings) in about:config, and finally start disabling extensions and then plugins (in particular, RealPlayer if you have it). If you have any web accelerator type mods to your Firefox, revert them too.
If that doesn't work, the next step is to look at your home router. Disable any firewall it may have, in particular, watch out for the "max pending connections" or "synflood protection" settings. Make sure they're either off or set really high. You may need to reset your router after doing these things.
Finally, try loading a satellite tile URL directly in your browser: http://kh0.google.com/kh?n=404&v=25&hl=en&t=trtqttrrttqts - do you see a tile? If you get a connection timeout, but regular google.com works, see step 2 above. If you see an error page talking about viruses, make sure you're only using Google Maps/Earth to view imagery and not any other app.
To be honest, from your description it sounds like the first step will yield the most fruit - I include the other two for completeness (if people see Maps load just fine but you don't see the roadmap or satellite images themselves, those two steps can help). Probably your cache has corrupted somehow, either that or some of the files Maps needs aren't loading. If you can't figure it out and know how, I'd suggest watching what happens with the Live HTTP Headers extension.
You should read the global baby bust. Under-population threatens to be a serious problem to developed economies in future - this is partly why immigration is allowed in such large numbers. I'm not saying it'll happen for sure, but I can well believe that in 30 years we'll look back on worries about over-population the same way we look at 70s worries about global cooling today.
What few people realize, is that the earth can support more people than what is commonly called the "carrying capacity" - temporarily.
You state that as fact, but as far as I know the concept of "carrying capacity" is not defined or even studied. Whilst it makes intuitive sense that there must be some limit, it also makes sense that this limit would itself be fluid - changing with the march of technology and changes in living standards. I've never seen anybody calculate a carrying capacity for 21st century Earth, especially not scientifically. People who use the term invariably assume it must be lower than our current population - how much lower is usually pulled out of thin air.
It becomes clear that the world just can't go on like that forever. It probably can't even go on like that for more than a couple of years. The green revolution has been made possible by oil and gas and both are getting much more expensive each and every year now.
Your list of societies is disingenous - you list a primitive, fully collapsed society like Easter Island right alongside Great Britain, which last time I lived there imported half its food because you can't grow strawberries there year round, not because it was about to collapse. Britain could feed itself tomorrow simply by converting some of its farming capacity from meat production to cereal production.
Also, the green revolution was triggered mostly by the development of nitrogen fertilisers, weed killers and crop varieties that could handle being treated with them. Although we use hydrogen from natural gas to make nitrogen fertilisers today, you can produce it using electrolysis without problem. And whilst it's true that today farm machinery is mostly gasoline powered, that's something independent of the green revolution. If you haven't already read it, I suggest checking out Stanifords Food to 2050 for a data-based analysis of whether the green revolution can be sustained.
And no, it's not a "global problem" like the one-worlders want us to believe. Some countries will be able to manage well (like Iceland which with almost zero immigration and geothermal energy plants is well prepared)
Only a small proportion of Icelands power comes from geothermal. Most of it is hydro. Iceland has much bigger problems than electricity anyway - there's basically nothing there, and whilst it has energy in abundance the economy is mostly based on industrial fishing. Once the fish stocks are exhausted, there'll be little left to sustain it.
I would be very surprised if there will be more than 3 billion people living in 2050.
Ah ha, I knew it. As soon as I read the term "carrying capacity" I was waiting for the ass-pulled number. Why 3 billion? Why not 2, or 4? Or 100 million? I don't see any particular constraints on slow population growth - it's been boringly linear for most of the 20th century in most developed countries, and in large parts of Europe is going to head sharply downwards soon due to natural demographic trends anyway. Whilst places like Africa or Chian might get miserable, Africa is already miserable and there's no obvious reason why in the long term China would see different population trends from other developed countries.
They don't only make reactor vessels but many other things. Given how unstable reactor demand is due to the push/pull from eco-activists, etc, would you want your business to be dominated by it? Or would you diversify and limit the number of orders you accept, to ensure that when you come to collect the money, the order hasn't been cancelled?
The problem is that a lot of regular programs use kernel drivers for parts of their functionality. In particular anything with copy protection (ie, all games) and even apps like iTunes or Picasa (for CD burning). So they would all break as well.
I like Tim, I especially liked his presentation on programming
languages in games, but his comments about 64-bit Vista seem
rather out of touch.
Sweeney: Let's be clear with it. The switch to exclusively 64-bit would clean up all the legacy viruses and spyware programs that have been plaguing us for years. The requirement for much more system memory cannot be an excuse, because most owners of 64-bit processors have at least 1 GB of system memory installed.
Yeah? It'd also have cleaned up all the "legacy" software
people are using. Like iTunes. Not to mention all the actual
legacy software like kids educational software, drivers for old
hardware, etc. I also don't know why he thinks this would have
cleaned up viruses and spyware. These guys adapt fast and the
extra anti-patch systems in 64 Vista aren't all that strong.
Singularity and Linux are so completely different that the chances of successfully prosecuting somebody for "stealing code" or even ideas is zero. Not only is Singularity written in a custom derivative of C# rather than C, but it has very different concepts of what a process is, what a kernel is, how system components communicate, and so on.
I, for one, am very happy to hear this and will definitely be checking it out. Singularity is probably the most interesting research OS out there right now, in multiple dimensions. The main challenge they have to tackle next is one that most microkernels never really reached (because their performance was too poor to make it worth bothering with) - once a component does fail, how can you rewind the system to a safe recovery point? I emailed the Singularity guys about this and got back a very nice reply, which basically said "we don't know, that's still a research problem we need to investigate".
Anyway. Good on MS Research. Let's see if anything interesting comes of this. It doesn't have to be useful, mind you, just interesting.
I don't think it's meant to be taken seriously. I mean, "a giant audio-visual shark"? And look at the picture. Made me laugh and I (very peripherally) have worked on Street View. Other entries in the competition: teledildonics, films on phones and guitar hero.
Slashdot needs to lighten up, oh, and maybe RTFA from time to time:)
Flash isn't hardware accelerated because it risks breaking content already on the net, IIRC. The problem is that drivers may or may not render the same content in the same way, and designers who rely on pixel-perfect rendering will find that their stuff breaks depending on the vagaries of hardware and/or drivers.
Please prove point (d). I worked on Wine for several years and not once did I ever see an undocumented API that would magically speed up somebodies program. Ever. They just don't exist. It's an urban legend, please don't spread it.
Yeah, but that's exactly the same sort of rationale that Microsoft used to use for making IE depend on all kinds of internal stuff. I mean, the APIs usually were available for others to use, they just weren't properly documented, or they were crappy APIs to begin with, or just not all that significant, or IE was released at the same time as the API (thus giving them an advantage over competitors that wanted to use them).
I mean, it's not like the IE devs were cackling evilly to themselves over what a huge advantage having access to some poorly documented interfaces in Explorer would give them. They had exactly the same engineering tradeoffs to make as Apple did. So either it's OK for Apple and Microsoft to do these things (and to be honest, given how mundane most undocumented APIs actually are, I'd say it is) or you decide you do care, and it's not OK for either of them to do that.
Slashdot Mirror
I think you missed the enormous amount of work done to try and optimize the ELF linking process on Linux. Profiles of OpenOffice startup showed that the majority of its time was spent inside the dynamic linker. It's no fantasy to say that shared libraries have a cost.
Because it doesn't work. Microsoft did actually try that approach in the (much more disruptive) shift from Win16 to Win32 - they literally ran an emulated DOS/Windows 3.1 in a box inside Windows 95. The problem is that everybody hated it. Nothing worked properly - drag and drop didn't work. Window management was duplicated. Copy and paste didn't work.
Eventually, they realised that what customers actually wanted was seamless integration. So they provided the new API and the old API side by side, with lots of thunks and integration glue to make them feel like one operating system. The approach was amazingly successful and Windows 95 went on to be a best selling product.
Apple did something similar to the first approach. Everybody hated it. The very, very few companies that still made software for MacOS were pressured by Apple and a zealous fan base to rewrite their app so they could avoid Classic. Versions of the old APIs were supplied to try and make the transition easy, but basically it involved a ton of work to get lickable buttons and no new functionality.
The reason it didn't kill MacOS entirely is simple - nobody used OS 9 anymore. Certainly, they didn't use it for business beyond maybe a few holdouts in the graphics department. Nobody was going to complain about the need to upgrade their line-of-business software, or their CAD/CAM software, or their old educational games, because the only people left on MacOS 9 were people who would use Macs until the day they died whatever the cost.
Microsoft has already designed a new OS. It runs in parallel to the regular OS and only relies on the Windows kernel for boring things like file, network and graphics IO that are unlikely to be very different in a rewritten OS. Other than that, apps run against fresh, modern APIs, they have access to advanced facilities. This new OS is processor-independent, has a much improved widget toolkit and excellent developer tools. Its name is .NET/Avalon, and nobody runs apps written with it on the desktop, because ultimately the most compelling desktop software has already been written and evolved over many years. The Photoshops and Microsoft Offices of this world are giant collections of code based on legacy technologies, but they're what users want to run and the value of an OS that can't do that well is extremely low as a result.
That's why, if Microsoft are smart, they won't bother with some new modular refactoring of Windows that isn't compatible with the old one. They did it once already and did a great job, but the impact it had on the desktop market was low.
You misread my post. I said that for desktop applications Java and C# suck rocks. Name me one popular retail desktop application written in Java, that isn't actually related to Java programming in some way. I can't think of any. I quite agree that Java and C# are excellent languages, the right tool for certain domains. But trying to write any serious desktop app in Java is an exercise in pain. The IBM guys managed it with Eclipse, but only by writing a replacement for the entire Java widget toolkit - and it still has "issues" with memory management.
C++ isn't going anywhere. Nearly all serious desktop software outside of Mac-land is written in it because the alternatives (Java? C#?) suck rocks. Large amounts of high performance code is written in C++. I don't know where you got the idea that people who care about performance use C from, that's flat wrong in my experience. I agree that D is a very nice language. It will make great strides in the next five yeras. However, maturity counts for a lot.
My university course spent about half an hour on pointers in a 3 year course. Most of that half hour was factually wrong: the slides were full of code samples that wouldn't compile or would always crash.
They did, however, spend two terms teaching Hoare logic. Or rather, they spent one term teaching it, and then repeated the same material in another term with a different lecturer, because their communication was so poor they never realised they had duplicated their teching.
Friends at other universities reported similar stupidities, though not always on the same scale.
C++ is a rather complex language, but simplifying it won't help. The problem is that low quality education is rampant.
I love HTML. Let's try that again.
Wow, that's the most stupid piece of research I ever saw. Not only are they generalizing from a bunch of 20 year olds to "all guys", but the scientific measurement involves trying to derive clues from static photos. Given how much body language is related to motion, timing and so on I'm not really surprised that they found it hard. I'd be interested to know how strong this guys < girls finding really is. Also, if the results change when the photos are replaced with short films ... or even actors :)
Wow, that's the most stupid piece of research I ever saw. Not only are they generalizing from a bunch of 20 year olds to "all guys", but the scientific measurement involves trying to derive clues from static photos. Given how much body language is related to motion, timing and so on I'm not really surprised that they found it hard. I'd be interested to know how strong this guys
I'm not sure what you mean. Windows doesn't use ELF. Its PE format works in a very similar fashion though (scoping aside). They both require that all symbols are available at the startup of the program unless they are lazy linked, but that's an optimisation and using it to delay load code is rather dangerous. Could you give more details?
I'd be surprised if that was the real problem. Assemblies aren't encrypted, nothing stops Mono from just ignoring the signature.
If I had to guess, I'd say the .NET policy is a result of fighting DLL hell for so many years. Modularity based on interfaces is a great principle, and is taught in practically every CS class. It tends to fall over and die when writing something with as many users as an operating system component, because there are too many subtle details users come to rely on which aren't encoded in the interface. Random example: for a function that returns a list, is it sorted or not? Often such things are undocumented. Perhaps it's sorted in version 1 because of how the component was implemented, but isn't in version 2. Whoops, you just broke any program that does a binary search on the result.
If you have 20 users, chances of that being a problem are low. If you have 20 million (easy ballpark figure for Windows) you just broke 100,000 programs and some giant corporation is screaming down the phone at you, asking why your OS upgrade is such a pile of shit.
Linking against exactly the version of the library you tested against is inefficient and prevents incremental bug fixes but is great for stability. Actually .NET doesn't force exact linking, I just read on MSDN that you can redirect assemblies to newer versions if you want, the trick being that it's done with config files at the app or machine level rather than replacing the library on disk as with traditional DLLs.
Actually it's not that great for admin staff (well, it might be, depending on your IT departments policies). At Google it's a major pain for our admin staff, because developers often require or want the latest Firefox for testing against. We use Ubuntu as it's the long term supported edition and thus there are typically not backports for the software we want anymore. It has to be done in house. This is a giant timesuck, and a problem that does not exist on Windows or OS X. This is especially true for Firefox 3 which requires an entirely new GTK stack. Dapper is less than two years old!
It's rare to encounter if you only install software from your distribution, because typically, people will hack around it or simply force everything to compile against the same version of the library. I documented this problem a few years ago: here's a relevant GCC bug and if you want a slightly easier to read explanation read this doc I wrote on writing shared libraries and search for "scoping".
The long and short of it is that in ELF, every symbol exported by a shared library (including internal symbols if you aren't careful!) exists in a global scope. Imagine you have a function called "clear()" defined in your program. Not so unlikely, right? Now imagine that you link against libfoo.so.1, which in turns uses libncurses to implement some of its functionality. Well, now you have a problem. It turns out that the ncurses API dates from before the time when prefixing function names with the library name was common in UNIX, and it also defines a function called clear. In any sane operating system (like Windows - gasp) this is not a problem. Your program doesn't use ncurses directly, so there's no conflict there. And libfoo is not linked "backwards" against your program either. So when libfoo invokes clear(), control should be transferred to libncurses.
However, that's not what happens. What actually happens is that libfoo jumps into your program and then crashes with stack corruption, because clear() was defined there first. The fact that libfoos ELF headers state that it depends on libncurses will cause ncurses to be loaded into memory, but not actually used for this function.
To put it mildly, this is not what most developers expect. The example above may seem contrived, but a far more common case is when a program indirectly uses two versions of the same library. This is what happens when you use mozilla.org provided Firefox binaries. Then, Firefox from upstream is compiled against libstdc++.so.5, because it's more widely available. Firefox loads some plugin .... for instance maybe it loads SCIM if you want to type Chinese as part of the GTK+ input methods framework .... which in turn loads something else written in C++ .... which in turn loads libstdc++.so.6 - well, now you lose, because you have the same library defining symbols with different names. The OS has sufficient information to pick the right one, but doesn't, because of the general way in which binary loading on Linux works.
For the specific case of libstdc++ this is "fixed" by using symbol versions which are basically a gross hack ... they make the risk of name collisions less likely but do not eliminate them. Except that it wasn't actually fixed, as that bug describes. This is a general problem that affects all libraries on ELF based platforms.
I wouldn't call the bizarre mess of the MacOS kernel "modular". It's certainly not a micro-kernel, if that's what you mean.
All the mainstream operating systems today are somewhat modular, in that you can swap components in and out if they implement the same interface. This is especially true for Windows, in which long-term heavy usage of COM (which was explicitly designed to promote modularity) has meant that you can do things like swap out the IE rendering engine for Firefox, and it'll work. Well, assuming that Firefox supports the features the embedding app in question needs, of course. If you doubt this, feel free to download the Gecko ActiveX plugin and try it ... most apps use IE just as a convenient rendering engine and can run when Gecko replaces it.
That might not sound impressive, but try swapping out Gecko for WebKit or Opera on Linux and see what a mess you get into. Hell, just try upgrading Firefox on Ubuntu. You will almost certainly fail. I know, because I've tried it. About the only sane way forward is to leave the old version in place and install a new, parallel copy - but that has its own problems due to general brokenness in the way ELF was designed (it doesn't seal off shared libraries from each other properly, so they can interfere and cause crashes). Although to be fair, Linux (really, unix) does let you swap out your display subsystem for another one thanks to X. So they all have strengths and weaknesses in this area.
I'm not really sure why you think Apple has "specced out its software at a maximum consistent level". Dealing with missing features is just a part of the software development game, and Apple supports that with what they call weak symbols. It's important because not everybody upgrades their OS at once, so even if you only have one edition of your operating system, developers still need to adapt at runtime to things that are missing. The piss-poor support for this in Linux is another reason upgrades are so flaky (it's only done at compile time for most programs).
I'll be interested to see what Windows 7 actually ends up being. I suspect that this whole modularity drive is coming from upper management somewhere, and by the time it reaches the engineers they will say "well .... but windows is already modular!". They'll make some token gestures, clean up some cruft that users won't really notice except in worse app compatibility, marketing will trumpet the changes as meaning that things will Really Be Different This Time! and nothing will really change.
Hey Wilmer, beats cleaning the apartment I guess :)
Hey Doc. I work on Maps and sometimes debug weird customer-reported problems like this.
Here's The Real Mikes three step guide to diagnosing and fixing Google Maps problems:
To be honest, from your description it sounds like the first step will yield the most fruit - I include the other two for completeness (if people see Maps load just fine but you don't see the roadmap or satellite images themselves, those two steps can help). Probably your cache has corrupted somehow, either that or some of the files Maps needs aren't loading. If you can't figure it out and know how, I'd suggest watching what happens with the Live HTTP Headers extension.
You should read the global baby bust. Under-population threatens to be a serious problem to developed economies in future - this is partly why immigration is allowed in such large numbers. I'm not saying it'll happen for sure, but I can well believe that in 30 years we'll look back on worries about over-population the same way we look at 70s worries about global cooling today.
You state that as fact, but as far as I know the concept of "carrying capacity" is not defined or even studied. Whilst it makes intuitive sense that there must be some limit, it also makes sense that this limit would itself be fluid - changing with the march of technology and changes in living standards. I've never seen anybody calculate a carrying capacity for 21st century Earth, especially not scientifically. People who use the term invariably assume it must be lower than our current population - how much lower is usually pulled out of thin air.
Your list of societies is disingenous - you list a primitive, fully collapsed society like Easter Island right alongside Great Britain, which last time I lived there imported half its food because you can't grow strawberries there year round, not because it was about to collapse. Britain could feed itself tomorrow simply by converting some of its farming capacity from meat production to cereal production.
Also, the green revolution was triggered mostly by the development of nitrogen fertilisers, weed killers and crop varieties that could handle being treated with them. Although we use hydrogen from natural gas to make nitrogen fertilisers today, you can produce it using electrolysis without problem. And whilst it's true that today farm machinery is mostly gasoline powered, that's something independent of the green revolution. If you haven't already read it, I suggest checking out Stanifords Food to 2050 for a data-based analysis of whether the green revolution can be sustained.
Only a small proportion of Icelands power comes from geothermal. Most of it is hydro. Iceland has much bigger problems than electricity anyway - there's basically nothing there, and whilst it has energy in abundance the economy is mostly based on industrial fishing. Once the fish stocks are exhausted, there'll be little left to sustain it.
Ah ha, I knew it. As soon as I read the term "carrying capacity" I was waiting for the ass-pulled number. Why 3 billion? Why not 2, or 4? Or 100 million? I don't see any particular constraints on slow population growth - it's been boringly linear for most of the 20th century in most developed countries, and in large parts of Europe is going to head sharply downwards soon due to natural demographic trends anyway. Whilst places like Africa or Chian might get miserable, Africa is already miserable and there's no obvious reason why in the long term China would see different population trends from other developed countries.
They don't only make reactor vessels but many other things. Given how unstable reactor demand is due to the push/pull from eco-activists, etc, would you want your business to be dominated by it? Or would you diversify and limit the number of orders you accept, to ensure that when you come to collect the money, the order hasn't been cancelled?
Or you can just bite the bullet and put in the hours, acknowledging that it won't lead to extra revenue but is necessary for the internet to continue.
The problem is that a lot of regular programs use kernel drivers for parts of their functionality. In particular anything with copy protection (ie, all games) and even apps like iTunes or Picasa (for CD burning). So they would all break as well.
I like Tim, I especially liked his presentation on programming languages in games, but his comments about 64-bit Vista seem rather out of touch.
Yeah? It'd also have cleaned up all the "legacy" software people are using. Like iTunes. Not to mention all the actual legacy software like kids educational software, drivers for old hardware, etc. I also don't know why he thinks this would have cleaned up viruses and spyware. These guys adapt fast and the extra anti-patch systems in 64 Vista aren't all that strong.
Singularity and Linux are so completely different that the chances of successfully prosecuting somebody for "stealing code" or even ideas is zero. Not only is Singularity written in a custom derivative of C# rather than C, but it has very different concepts of what a process is, what a kernel is, how system components communicate, and so on.
I, for one, am very happy to hear this and will definitely be checking it out. Singularity is probably the most interesting research OS out there right now, in multiple dimensions. The main challenge they have to tackle next is one that most microkernels never really reached (because their performance was too poor to make it worth bothering with) - once a component does fail, how can you rewind the system to a safe recovery point? I emailed the Singularity guys about this and got back a very nice reply, which basically said "we don't know, that's still a research problem we need to investigate".
Anyway. Good on MS Research. Let's see if anything interesting comes of this. It doesn't have to be useful, mind you, just interesting.
I don't think it's meant to be taken seriously. I mean, "a giant audio-visual shark"? And look at the picture. Made me laugh and I (very peripherally) have worked on Street View. Other entries in the competition: teledildonics, films on phones and guitar hero.
Slashdot needs to lighten up, oh, and maybe RTFA from time to time :)
Flash isn't hardware accelerated because it risks breaking content already on the net, IIRC. The problem is that drivers may or may not render the same content in the same way, and designers who rely on pixel-perfect rendering will find that their stuff breaks depending on the vagaries of hardware and/or drivers.
Please prove point (d). I worked on Wine for several years and not once did I ever see an undocumented API that would magically speed up somebodies program. Ever. They just don't exist. It's an urban legend, please don't spread it.
Yeah, but that's exactly the same sort of rationale that Microsoft used to use for making IE depend on all kinds of internal stuff. I mean, the APIs usually were available for others to use, they just weren't properly documented, or they were crappy APIs to begin with, or just not all that significant, or IE was released at the same time as the API (thus giving them an advantage over competitors that wanted to use them).
I mean, it's not like the IE devs were cackling evilly to themselves over what a huge advantage having access to some poorly documented interfaces in Explorer would give them. They had exactly the same engineering tradeoffs to make as Apple did. So either it's OK for Apple and Microsoft to do these things (and to be honest, given how mundane most undocumented APIs actually are, I'd say it is) or you decide you do care, and it's not OK for either of them to do that.