You have a good point about the massive number of states, but you logic is sloppy. You assume that every byte of the heap can have any value, but this is just not true. In a reasonable language there are a great number of states that are simply not possible.
Just because the language is turing complete does not mean that it produces processor complete binaries. In Java there is no way to refer to an illegal address, so you can emulate a tape machine and you can produce a binary with gcj, but that binary will never issue an illegal reference (either to unmapped memory or to the wrong address). If a variable is a protected field then only the object's operations can affect it, so the number of combinations of states it can take is greatly reduced. In fact, the real problem is not the number of states at all but that the way they are interrelated. You could have only a hundred variables and still not be able to tell whether the program operated correctly.
If you program your application in Java or Ruby or Python or basically not-C/C++, then you have a whole huge category of mistake and bugs that are simply not possible no matter what the skill level is of the developers. The choice of language is the greatest factor in reducing bugs.
The fundamental problem with all of these crappy gimmicks to improve efficiency and usability is that they don't solve the problem. When I'm writing I always have something I am trying to do and this usually involved only a few actions of the thousands available to choose from and I usually do it over and over again.
So I have N actions I am doing over and over again and to be efficient I want them all on the screen at the same time so I can click once per action. These actions will often not be easily categorized or grouped, and will change from time to time. For example, I may be accepting changes then putting the changed text in a different color/font/style and adding a footnote explaining the change (maybe to make a public release of a reviewed document). Then I am using three completely separate actions and with *any* of the existing attempts such as disappearing menus, context toolbars, or ribbons I have to jump through hoops to do it.
The solution I think is just have a thin bar with the last N actions the user performed. This means for *any* task requiring N or fewer actions, they are all on the screen at once so are easy to find and only need 1 mouse click each. When the user performs a new action, the most unused on the bar gets pushed off. Yes it can be as confusing as the other methods, but for a expert it means that it is always 1 click to perform the actions they need and they are always grouped together in one place. For instance, one could have a menubar and a thin, 1-action high toolbar and the rest of the screen could actually show the text and this would be perfectly usable if not more so.
Well if you actually RTFA, Red Hat wants to hack the JVM so that it supports real-time features. So in other words, they want their own Red Hat Realtime Java fork. Wtf up with that? Sun gives them a distributable Java and they say they also need to hack up their own version of it.
It sounds like Red Hat has it's cake, now it wants to eat Sun's too. Me, I just want emerge not to bail when it gets to java.
I give Windows, Apple, and Linux as prototypical examples of different approaches and where they can lead. Apple threw out their system almost entirely. Linux makes their code better and rewrites whatever gets broken by it. Windows just continues on with what they have, trying to tack onto it. Note that Windows model is not "backwards compatible at all costs", for example WINE has better support for older programs than Windows.
I point these models out to note that a complete rewrite can work well and produce the best end result. Another good approach is the continual rewrite as exemplified by Linux. What they currently have is like Windows.
I am not mistaking the point, which is good in general, but rather pointing out that you are assuming that they have somewhat separate modules that can be re-written or replaced one at at time. You're assuming that they can write test cases, when the reality may be (and my guess is) that they have outputs that they are not even sure are correct. And lots of vestiges that shouldn't be carried over into anything new.
My one suggestion for the story poster for going forward is to take the linux model in the future, regardless of whether this particular software is scrapped or not. Don't let the code stagnate, keep taking a little bit of time here and there to rewriting parts to be 'better' (not a huge amount of time, but enough). This is where parent's unit testing, iterative changes, etc come into play and are a good idea. If you "waste" 10% of your time all along making the code better, but then get new features added in 1/2 the time you way ahead of the game.
Microsoft and SONY probably thought they had an implicit kind of understanding that often happens these days when there are only a few companies in a market. They probably thought everybody wins if they each overcharge or make a too-expensive product. People are still going to buy, so if they all have high prices they all benefit.
It's like on Jeopardy when the person in 3rd place bets $0 instead of all their money then wins because nobody expected them to do that and it was a question nobody knew. Nintendo basically bet nothing, just updating their system to current tech instead of expensive future tech, and is going to win big time because the other guessed wrong. Even without their new controller they would win this round.
Six years of C++ development, and all the corresponding skill development.... That's a shitload of stuff to just throw away to be buzzword compliant.... The key word is incremental. Incremental might succeed.
Let me be the lone voice to call bullshit. Story poster is obviously inexperienced and trying to be diplomatic (if for no other reason than pride). What we have here is almost certainly a big steaming pile of crap.
Their development has slowed to the point where they are going to ditch the whole thing. It's too late to save this code. Putting a nice interface on it will just exacerbate the problem because anything you try to do will either expose the underlying crap and bugs (ie mfc,.net forms) or be as much work as a re-write.
Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult. Meanwhile both Apple and Linux have made leaps and bounds, Apple by ditching their massive investment in OS 9 and Linux by shunning backwards compatibility. Linux doesn't have binary kernel drivers because mapping better stuff to old mistakes is even harder than keeping a zillion drivers up-to-date. I'm always getting "kernel too old" messages trying to make binaries that run everywhere. It sucks, but imho it's a huge reason why Linux is advancing instead of stagnating. The only reason Microsoft is still around is because of lock-in; if poster's company doesn't have a lock on the market and given their codebase they will fail if taking the incremental approach.
I think it's painfully obvious that whatever it is they are doing (I'm guessing some database + COBRA junk) is something that shouldn't be written in C++ in the first place. For example, poster does not mention performance at all. C++ *can* be a lot faster than Java at some things and is a pretty good choice for those (action games for instance), but if you are not even slightly concerned about it then that's a pretty big tell that using C++ for it is a huge mistake. Ideally they would write most of their code in Python or Ruby or similar, but it sounds like this could be out because of client issues. So Java or C# is probably the only realistic language to code in.
I like Peter Lada's design best because it works with the mouse gesture plugin for firefox. Since the switch to CSS the gestures on/. are so slow they can't be used. This slowness is also on Mr. Johnson's design, but strangely the Lada design works perfectly with gestures.
I'm using All-in-One Gestures 0.17.4 (and adblock and user-agent-switcher as only other extensions).
The add-ons can be loaded as modules because they are compiled against the specific kernel you are running, not because the separation is so good. Try taking a driver from 2.4 linux and getting it to run on each kernel since then. You'll re-write significant parts of it at least a half-dozen times.
If you have been using vmware on the bleeding edge kernel you'll know this from experience (and vmware is *really* good at maintaining their linux drivers). For a while I had to run a ridiculously old 2.6 kernel because the Intel video driver would not work on later kernels. End-users don't understand this because there is a lot of effort and patching going on so the latest Ubuntu or whatever distro "just works".
That is so true. I got up to iirc 94% in topcoder doing just a few competitions when unemployed. Maybe I could have gotten to 97% or 98% if I had prepared (getting a bunch of templates set up for common solution types, etc) and kept at it for a while. Who knows.
Instead I get home at 7pm after coding all day and I am tired of coding. I'd rather play a game or watch tv. Add to this that the regular prizes are not a lot of money. I think topcoder when went dark I even had $125 in money I never even claimed. I'm not filthy rich, but I liked the competition and considered it a donation in hopes it would come back again.;-P
But if I was in poland, unemployed or in college, coding basically only for fun, and poor I would definitely be in there for every competition even if it was 4am local time. So really I don't think this has all that much to do with the quality of coders out there in America.
It's fun that you mention that, because such things have been already done.
Yes, in FUSE, and within kde and withing gnome. Zip archive != zip disk.
The reality is that seeks and fragmentation matters....when things are not in cache. Real world does care about the real world, you know.
I guess that's why USB filesystem are implemented in user mode in linux, huh? They are memory and the moral equivalent of 'l2 cache' compared to disks, which is why Vista will reportedly swap through them. But in linux they are user-mode whereas disk filesystems are in the kernel for performance? Boggle.
No. Linux systems can't even boot on NTFS filesystems.
Earlier you said linux gets "all the advantages of a microkernel without any of the disadvantages" but yet it can't boot? Lol.
Nobody is going to go to the level of effort required to make anything but a general purpose file-system in the kernel. Can you even imagine what would be involved in making a.zip filesystem in the linux kernel? Even a read-only one would require maybe 6 months of study for an average developer. A read-write one would be extremely difficult if done in the linux kernel.
What you have not shown is that these filesystems are in the kernel because they must be because of performance. Take the FUSE's Captive NTFS filesystem for instance. Is NTFS not performance critical? Maybe a kernel-mode NTFS would be a bit faster but the problem is that after more than 5 years in development it still barely works even for reading.
The reality is that "performance critical" filesystem for a disk means that it has low fragmentation and few seeks for the index. It must be able to read multiple blocks at once. That's pretty much it. Whether it is running as a microkernel driver, or a monolithic driver, or a user-mode driver matters very little compared to this. Yes, linux can be used like a microkernel and this is being done, but it is far from "without any disadvantages". The overhead of making protected drivers in linux is about twice that of a fast microkernel (see wikipedia on l4 for instance).
The real advantage of a *good* microkernel is that normal people can write drivers and modules to extend it. If you compare the filesystems available for FUSE compared to what's available by compiling into the kernel you get a good idea:
FunFS: network filesystem, KIO Fuse Gateway: mount anything kde can talk to as a filesystem Bluetooth FS: bluetooth functions as files mcachefs: caches files locally from another filesystem ie nfs/smb Fusedav: mounts WebDAV shares as fs GmailFS: uses gmail for storage CvsFS: view a version as fs SshFS: mount sftp as fs WikipediaFS: edit wikipedia articles as files FuseCompres: transparent compression FuseFTP: ftp filesystem (written in perl) GnomeVFS2: mount anything nautilus can view archivemount: mount tar, cpio, tar.gz archives read/write...
Notice any difference? In the kernel, everything is pretty much either some long-standing standard or developed by some large corporation. The user-mode ie microkernel-style ones are developed by single people because they saw a need -- and so they actually do something useful like mounting ftp or zip files, or using gmail. These things are useful and different whereas once I've picked the fs for my drives I couldn't give a crap about any other fs in the kernel. None of them do anything even remotely interesting.
So that's the real advantage of a microkernel. Somebody wrote a useable filesystem in perl for heaven's sake. Yes, you can get some of the same benefits by turning a monolithic kernel like linux into basically a big/slow/ugly microkernel in certain areas like fs for instance. But with a good microkernel or safe kernel you get these same benefits everywhere with the advantage that your "archive filesystem" is much, much faster.
It could also be memory errors. Even good memory can flip bits when overheated or in the presence of some radiation source. There was a paper not too long ago about bypassing Java's type system using memory errors, like half the time the os would crash and the other half they would get access to what was supposed to be protected by the type system. So if you have normal PC memory with no or weak error correction try cleaning the case fan and moving away from other equipment.
The real question though is if it is worth it to put in all this effort in all parts of the kernel to make them completely free of bugs that could eventually stomp memory (pretty much all bugs). For user space we say certainly not because the things done in user-space are "so complicated" that it's impractical. It gets in the way of doing it the best way that it has to also be 100% bug free. Even something as "complicated" as grep runs in user space on the offchance that regex goes bad and kills something. And yet parts of the kernel are much more complex than grep.
I say no, it's not worth for the whole kernel to be able to kill the machine. Just look at the creative things done with user-space filesystems like FUSE. We finally get something in Linux that can mount a freakin' zip file as a filesystem. This would never happen if this also had to be 100% bug-free.
I'm glad tannenbaum actually mention's Microsoft's singularity "safe kernel" project, only I wish he had given credit to Sun for their Self operating system or jxos for their Java one that was booting on vmware before singularity was even started. "Safe kernels" aka ones written in and running Java or C# are the future.
{ Lock(someMutex); do stuff; }// not locked { Lock lock(someMutex); exit thread; }// deadlock { Lock lock(obj->mutex); delete obj; }// crash { subclassed->method(); }// subclass forgot to synchronize... etc.
In Java, Smalltalk, Ruby, and pretty much any language that isn't C/C++ there is basically no way to screw up in any way except making a deadlock or not locking something important. Of course C++ gives you the 'power' to screw up locking, you know in case you *really* need to have fast but undefined results.
No, Java does not give every structure a mutex (as if Java even had structures). It only creates a mutex if synchronization is used on an object, so if you never use locking there are no locks. And no, it is actually perfectly fine for 2 or more threads to have read or write access to the same variable as long as it's atomic read/write... you just have to know what that means for your program.
Batman was right that after using Java's threading this NTPL trace looks pretty lame. Not only is the threading and locking in Java braindead simple, but the JVM actually tells you what is wrong. For instance it detects deadlocks and gives you the complete call trace of each deadlocked thread.
Other languages have good locking too (ruby for instance), so it's more that everything is difficult and crappy in C and its kind. I guess if you are stuck writing a threaded application in C in the first place this tracing library could be useful. Of course if you use the heap you're going to also want to replace malloc/free with a fast multithreaded version and then do a bunch of hacks so that it isn't ridiculously slow (locking on every free()... now *that's* inefficient).
As long as I'm paying my virtual tax in virtual currency. I'm sure the creative folks at the IRS will be able to figure out what to do with 1 billion gold. Maybe we can even get a bridge from Alaska to Kalimdor out of it.
This would be perfect for touch screens since the software would be able to tell where the center was. Even though your finger may be very large, it approaches a specific point as you touch the screen. So you might 'touch' several on-screen buttons, but the mac would know (or at least have a better idea) which one you were trying for. It could also let you move things without actually touching the screen, so dragging wouldn't need constant pressure.
"Communications Opportunity, Promotion and Enhancements Act of 2006."
When will people just stop using their "Clear Skies" aka "Clearly Incorrect" propoganda labels attached to the bills? Just say the bill introduced yesterday which legalizes a tiered internet and removes consumer rights to resell internet services, which from a quick glance seems far more accurate a description. Once they actually introduce it refer to it as HR1126 or whatever its id is. With some alphanumeric id people don't automatically get an opinion without RTFA.
At least put a "so-called" in from of the title. Of course it is kinda handy to just apply "!(Title)" and know what the bill is actually for...
The *only* thing I leared from preparing and winning the regionals was dynamic programming. But I actually learned that in class.
The problems are such that there are two skills involved in winning: 1) writing bug-free small programs and 2) understanding the wording of the problem. The first favors asian cultures which teach more by rote and are higher pressure and more exacting.
I don't think that the internationals are translated into the team's native language, but if so that would definitely be a huge bonus for them. English is very vague but also very expressive (or at least how they write the problems is). Chinese for example is not, for instance you don't say 'have you eaten yet?' you say 'eat, no eat?' and you are supposed to understand from context what that means. So, if translated, the problems would really have to explain exactly what was meant instead of being close enough.
I think the loss of Dr. Henry also had something to do with the showing this year. We'll all miss her, that knew her. =(
>Typically the overhead (descriptors that say the same thing?) isn't all that nasty even with 4k pages since you don't *have* to map the full 4MB that a complete 2 level page table would need.
All physical memory in the system is in use at all times with a good os, if only for caching data. Thus it has a page table entry. Pretty much all linux distros use 4k pages. So yes, you don't need a page table entry for memory you don't physically have, big deal.
If you really don't think this is 'not that nasty' explain why an app can't use more than ~80% of the physical memory on a typical linux distro? It's trivial to write a program that keeps growing an array and touching the pages. Once you get near 80% it's dead from swapping even with nothing else running at all.
>>It takes ~1200 cycles just to enter a system call because of using vm for process separation >How's that? There's no context switch. The kernel is mapped into every user process.
I know this from actually timing it (ie sysenter), of course it varies slightly depending mostly on the processor. Duh. With a single memory space this equates to a function call to a known address, so is basically instant.
>So you're taking less of a hit doing JIT than managing separate address spaces? How's that work?
Not all safe code has to be JIT compiled, for example it can be compiled by a trusted compiler as in libmo/dis. Second, JITs work very well. Java raw numerics code is sometimes equal to C speed despite its limitations like no unsigned types, array bounds, no pointer arithmetic, etc. Java heap is significantly faster than malloc/free. Now take off all the time for tlb flushes, interrupts, multiple-copied memory, page table magic, etc in a system like linux. Replace the heap with a vm-optimized garbage collector (using dirty bit, etc) and it gets even faster.
>I sincerely hope you don't believe what you're saying.
Yeah and I hope what I'm saying isn't the case, because it's freakin sad a) that uninformed people like you AC exist and b) that we're stuck with this crap we call unix / nt / osx because of inertia.
Well in general wind farms suck. They actually take enough energy out of the air to make a difference to the environment. That shouldn't be a big surprise, after all wind doesn't really have that much energy in it in the first place compared to water, geothermal, etc.
Nuclear is great if done right, like reactors that cannot melt down. If only the administration's nuclear policy was promoting those. Nope, they want the crappy ones that can poison everything for hundreds of miles so they can get more corporate welfare and tax breaks maintaining them.
It would be pretty good if we liquified coal and removed the sulfur and other pollutants, but instead we are just relax the quality standards so we can put even more murcury into the air to poison us.
So green energy is not really about the source, it's how it is done. You can put some windmills in, but not a freakin million of them. But I can tell you, if we spend 500 billion dollars on any kinds of green energy we would be in a much better place than we are now.
Parent poster was correct in this case, Linux is talking about using COW for data passed to system calls like write. Ie so you call write with a 1 gig buffer and instead of copying 1 gig of memory before writing it out to disk/network/etc it just makes the 1 gig read only (or copy on write) and then it can just write it out, in-place.
So with this syscall glibc could for instance make a fast_write call that has the same api, but it tells the kernel that the memory can be made read-only until the kernel is finished with it.
I claim that Mach people (and apparently FreeBSD) are incompetent idiots. Playing games with VM is bad. memory copies are _also_ bad, but quite frankly, memory copies often have _less_ downside than VM games,
I totally agree with that, I just go one step further and say that Torvalds is also a total idiot: VM games are bad, so use copying instead because that's less bad. But copying is also bad, so why it at all? Neither are good solutions.
The problem is that linux and bsd are using "virtual memory" to protect processes from each other, but it is designed to run programs that use more memory than is available. Does it sound right that to protect one process from another you are going to use hundreds of thousands of descriptors for each 4k that all say the same thing? It's pretty stupid actually. 4k is too fine-grained for virtual memory these days as disks have grown. It's both too small and too large for process separation.
The better solution is to use vm for virtual memory and run all code in the same memory space, but only run code that cannot access memory illegally (ie no pointer arithmetic, only references). This code could be written in Java, or libmo, or D, or maybe other 'safe' languages and run at much faster speeds than they do now as traditional linux processes. The code could be straight C that is JIT recompiled/checked to prevent illegal accesses. That's right, I claim that an average Java program would run faster in such a system than a C program does under a linux/bsd-like system.
Linus is right, there is massive overhead from doing vm games -- like what is done in linux for instance to separate processes. Did you even wonder why you can't use more than about 80% of the physical memory simultaneously (ie walk an array of 80% physical mem size and see what happens)? That's right, the kernel is using that much as overhead and about 7% of that is page tables for *physical memory*. It takes ~1200 cycles just to enter a system call because of using vm for process separation vs maybe 5 using a single memory space. Unix kernels do not give fine-grained access to anything because it's simply not possible with process separation based on vm to do so, not in practice.
The main problem is that the CPUs are only designed for high-level parallelism. So you don't get much benefit from Haskell of Erlang because they could theoretically say "run this loop of 1..10 as two loops 1..5 and 6..10", but in practice doing so would be much slower on today's multi-core multiprocessors due to the setup overhead.
I actually have a brand new dual-core box and the gnome System Monitor shows both cpu's separately. The only time I've seen both cpu's used by a single program it was a Java program. So I don't really understand where you are coming from. Today's multiprocessors are designed for high-level parallelism that the programmer has to declare in some way, and Java is excellent for this (C# to a somewhat lesser degree).
Now a language like Erlang or Scheme could get a huge performance boost from processors like the now-outdated Tera MTA (aka Cray), which was the inspiration for Sun's MAJC processor. These have hardware threading, so the language compiler can break loops out into multiple threads with next to no overhead. This also benefits Java to some extent since it has moderately better rules regarding aliasing for instance than C#. C/C++ can also benefit automatically with 'loose' compilers, macros, and generally a lot of work on the programmer's side.
Slashdot Mirror
You have a good point about the massive number of states, but you logic is sloppy. You assume that every byte of the heap can have any value, but this is just not true. In a reasonable language there are a great number of states that are simply not possible.
Just because the language is turing complete does not mean that it produces processor complete binaries. In Java there is no way to refer to an illegal address, so you can emulate a tape machine and you can produce a binary with gcj, but that binary will never issue an illegal reference (either to unmapped memory or to the wrong address). If a variable is a protected field then only the object's operations can affect it, so the number of combinations of states it can take is greatly reduced. In fact, the real problem is not the number of states at all but that the way they are interrelated. You could have only a hundred variables and still not be able to tell whether the program operated correctly.
If you program your application in Java or Ruby or Python or basically not-C/C++, then you have a whole huge category of mistake and bugs that are simply not possible no matter what the skill level is of the developers. The choice of language is the greatest factor in reducing bugs.
The fundamental problem with all of these crappy gimmicks to improve efficiency and usability is that they don't solve the problem. When I'm writing I always have something I am trying to do and this usually involved only a few actions of the thousands available to choose from and I usually do it over and over again.
So I have N actions I am doing over and over again and to be efficient I want them all on the screen at the same time so I can click once per action. These actions will often not be easily categorized or grouped, and will change from time to time. For example, I may be accepting changes then putting the changed text in a different color/font/style and adding a footnote explaining the change (maybe to make a public release of a reviewed document). Then I am using three completely separate actions and with *any* of the existing attempts such as disappearing menus, context toolbars, or ribbons I have to jump through hoops to do it.
The solution I think is just have a thin bar with the last N actions the user performed. This means for *any* task requiring N or fewer actions, they are all on the screen at once so are easy to find and only need 1 mouse click each. When the user performs a new action, the most unused on the bar gets pushed off. Yes it can be as confusing as the other methods, but for a expert it means that it is always 1 click to perform the actions they need and they are always grouped together in one place. For instance, one could have a menubar and a thin, 1-action high toolbar and the rest of the screen could actually show the text and this would be perfectly usable if not more so.
Well if you actually RTFA, Red Hat wants to hack the JVM so that it supports real-time features. So in other words, they want their own Red Hat Realtime Java fork. Wtf up with that? Sun gives them a distributable Java and they say they also need to hack up their own version of it.
It sounds like Red Hat has it's cake, now it wants to eat Sun's too. Me, I just want emerge not to bail when it gets to java.
I give Windows, Apple, and Linux as prototypical examples of different approaches and where they can lead. Apple threw out their system almost entirely. Linux makes their code better and rewrites whatever gets broken by it. Windows just continues on with what they have, trying to tack onto it. Note that Windows model is not "backwards compatible at all costs", for example WINE has better support for older programs than Windows.
I point these models out to note that a complete rewrite can work well and produce the best end result. Another good approach is the continual rewrite as exemplified by Linux. What they currently have is like Windows.
I am not mistaking the point, which is good in general, but rather pointing out that you are assuming that they have somewhat separate modules that can be re-written or replaced one at at time. You're assuming that they can write test cases, when the reality may be (and my guess is) that they have outputs that they are not even sure are correct. And lots of vestiges that shouldn't be carried over into anything new.
My one suggestion for the story poster for going forward is to take the linux model in the future, regardless of whether this particular software is scrapped or not. Don't let the code stagnate, keep taking a little bit of time here and there to rewriting parts to be 'better' (not a huge amount of time, but enough). This is where parent's unit testing, iterative changes, etc come into play and are a good idea. If you "waste" 10% of your time all along making the code better, but then get new features added in 1/2 the time you way ahead of the game.
Microsoft and SONY probably thought they had an implicit kind of understanding that often happens these days when there are only a few companies in a market. They probably thought everybody wins if they each overcharge or make a too-expensive product. People are still going to buy, so if they all have high prices they all benefit.
It's like on Jeopardy when the person in 3rd place bets $0 instead of all their money then wins because nobody expected them to do that and it was a question nobody knew. Nintendo basically bet nothing, just updating their system to current tech instead of expensive future tech, and is going to win big time because the other guessed wrong. Even without their new controller they would win this round.
Six years of C++ development, and all the corresponding skill development. ... That's a shitload of stuff to just throw away to be buzzword compliant. ... The key word is incremental. Incremental might succeed.
.net forms) or be as much work as a re-write.
Let me be the lone voice to call bullshit. Story poster is obviously inexperienced and trying to be diplomatic (if for no other reason than pride). What we have here is almost certainly a big steaming pile of crap.
Their development has slowed to the point where they are going to ditch the whole thing. It's too late to save this code. Putting a nice interface on it will just exacerbate the problem because anything you try to do will either expose the underlying crap and bugs (ie mfc,
Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult. Meanwhile both Apple and Linux have made leaps and bounds, Apple by ditching their massive investment in OS 9 and Linux by shunning backwards compatibility. Linux doesn't have binary kernel drivers because mapping better stuff to old mistakes is even harder than keeping a zillion drivers up-to-date. I'm always getting "kernel too old" messages trying to make binaries that run everywhere. It sucks, but imho it's a huge reason why Linux is advancing instead of stagnating. The only reason Microsoft is still around is because of lock-in; if poster's company doesn't have a lock on the market and given their codebase they will fail if taking the incremental approach.
I think it's painfully obvious that whatever it is they are doing (I'm guessing some database + COBRA junk) is something that shouldn't be written in C++ in the first place. For example, poster does not mention performance at all. C++ *can* be a lot faster than Java at some things and is a pretty good choice for those (action games for instance), but if you are not even slightly concerned about it then that's a pretty big tell that using C++ for it is a huge mistake. Ideally they would write most of their code in Python or Ruby or similar, but it sounds like this could be out because of client issues. So Java or C# is probably the only realistic language to code in.
I like Peter Lada's design best because it works with the mouse gesture plugin for firefox. Since the switch to CSS the gestures on /. are so slow they can't be used. This slowness is also on Mr. Johnson's design, but strangely the Lada design works perfectly with gestures.
I'm using All-in-One Gestures 0.17.4 (and adblock and user-agent-switcher as only other extensions).
The add-ons can be loaded as modules because they are compiled against the specific kernel you are running, not because the separation is so good. Try taking a driver from 2.4 linux and getting it to run on each kernel since then. You'll re-write significant parts of it at least a half-dozen times.
If you have been using vmware on the bleeding edge kernel you'll know this from experience (and vmware is *really* good at maintaining their linux drivers). For a while I had to run a ridiculously old 2.6 kernel because the Intel video driver would not work on later kernels. End-users don't understand this because there is a lot of effort and patching going on so the latest Ubuntu or whatever distro "just works".
That is so true. I got up to iirc 94% in topcoder doing just a few competitions when unemployed. Maybe I could have gotten to 97% or 98% if I had prepared (getting a bunch of templates set up for common solution types, etc) and kept at it for a while. Who knows.
;-P
Instead I get home at 7pm after coding all day and I am tired of coding. I'd rather play a game or watch tv. Add to this that the regular prizes are not a lot of money. I think topcoder when went dark I even had $125 in money I never even claimed. I'm not filthy rich, but I liked the competition and considered it a donation in hopes it would come back again.
But if I was in poland, unemployed or in college, coding basically only for fun, and poor I would definitely be in there for every competition even if it was 4am local time. So really I don't think this has all that much to do with the quality of coders out there in America.
It's fun that you mention that, because such things have been already done.
Yes, in FUSE, and within kde and withing gnome. Zip archive != zip disk.
The reality is that seeks and fragmentation matters....when things are not in cache. Real world does care about the real world, you know.
I guess that's why USB filesystem are implemented in user mode in linux, huh? They are memory and the moral equivalent of 'l2 cache' compared to disks, which is why Vista will reportedly swap through them. But in linux they are user-mode whereas disk filesystems are in the kernel for performance? Boggle.
No. Linux systems can't even boot on NTFS filesystems.
Earlier you said linux gets "all the advantages of a microkernel without any of the disadvantages" but yet it can't boot? Lol.
Nobody is going to go to the level of effort required to make anything but a general purpose file-system in the kernel. Can you even imagine what would be involved in making a .zip filesystem in the linux kernel? Even a read-only one would require maybe 6 months of study for an average developer. A read-write one would be extremely difficult if done in the linux kernel.
What you have not shown is that these filesystems are in the kernel because they must be because of performance. Take the FUSE's Captive NTFS filesystem for instance. Is NTFS not performance critical? Maybe a kernel-mode NTFS would be a bit faster but the problem is that after more than 5 years in development it still barely works even for reading.
The reality is that "performance critical" filesystem for a disk means that it has low fragmentation and few seeks for the index. It must be able to read multiple blocks at once. That's pretty much it. Whether it is running as a microkernel driver, or a monolithic driver, or a user-mode driver matters very little compared to this. Yes, linux can be used like a microkernel and this is being done, but it is far from "without any disadvantages". The overhead of making protected drivers in linux is about twice that of a fast microkernel (see wikipedia on l4 for instance).
The real advantage of a *good* microkernel is that normal people can write drivers and modules to extend it. If you compare the filesystems available for FUSE compared to what's available by compiling into the kernel you get a good idea:
...
Kernel: ext2/3, reiser3/4, jfs, xfs, minix, romfs, cdrom, fat, ntfs, proc, sysfs, adfs, ffs, hfs, BeFS, jffs (flash), cramfs, qnx4 fs, smb, cifs, andrew fs, plan 9
FUSE:
FunFS: network filesystem,
KIO Fuse Gateway: mount anything kde can talk to as a filesystem
Bluetooth FS: bluetooth functions as files
mcachefs: caches files locally from another filesystem ie nfs/smb
Fusedav: mounts WebDAV shares as fs
GmailFS: uses gmail for storage
CvsFS: view a version as fs
SshFS: mount sftp as fs
WikipediaFS: edit wikipedia articles as files
FuseCompres: transparent compression
FuseFTP: ftp filesystem (written in perl)
GnomeVFS2: mount anything nautilus can view
archivemount: mount tar, cpio, tar.gz archives read/write
Notice any difference? In the kernel, everything is pretty much either some long-standing standard or developed by some large corporation. The user-mode ie microkernel-style ones are developed by single people because they saw a need -- and so they actually do something useful like mounting ftp or zip files, or using gmail. These things are useful and different whereas once I've picked the fs for my drives I couldn't give a crap about any other fs in the kernel. None of them do anything even remotely interesting.
So that's the real advantage of a microkernel. Somebody wrote a useable filesystem in perl for heaven's sake. Yes, you can get some of the same benefits by turning a monolithic kernel like linux into basically a big/slow/ugly microkernel in certain areas like fs for instance. But with a good microkernel or safe kernel you get these same benefits everywhere with the advantage that your "archive filesystem" is much, much faster.
It could also be memory errors. Even good memory can flip bits when overheated or in the presence of some radiation source. There was a paper not too long ago about bypassing Java's type system using memory errors, like half the time the os would crash and the other half they would get access to what was supposed to be protected by the type system. So if you have normal PC memory with no or weak error correction try cleaning the case fan and moving away from other equipment.
The real question though is if it is worth it to put in all this effort in all parts of the kernel to make them completely free of bugs that could eventually stomp memory (pretty much all bugs). For user space we say certainly not because the things done in user-space are "so complicated" that it's impractical. It gets in the way of doing it the best way that it has to also be 100% bug free. Even something as "complicated" as grep runs in user space on the offchance that regex goes bad and kills something. And yet parts of the kernel are much more complex than grep.
I say no, it's not worth for the whole kernel to be able to kill the machine. Just look at the creative things done with user-space filesystems like FUSE. We finally get something in Linux that can mount a freakin' zip file as a filesystem. This would never happen if this also had to be 100% bug-free.
I'm glad tannenbaum actually mention's Microsoft's singularity "safe kernel" project, only I wish he had given credit to Sun for their Self operating system or jxos for their Java one that was booting on vmware before singularity was even started. "Safe kernels" aka ones written in and running Java or C# are the future.
Compare that to corresponding C++ code:
// not locked // deadlock // crash // subclass forgot to synchronize ... etc.
Or how about these:
{ Lock(someMutex); do stuff; }
{ Lock lock(someMutex); exit thread; }
{ Lock lock(obj->mutex); delete obj; }
{ subclassed->method(); }
In Java, Smalltalk, Ruby, and pretty much any language that isn't C/C++ there is basically no way to screw up in any way except making a deadlock or not locking something important. Of course C++ gives you the 'power' to screw up locking, you know in case you *really* need to have fast but undefined results.
No, Java does not give every structure a mutex (as if Java even had structures). It only creates a mutex if synchronization is used on an object, so if you never use locking there are no locks. And no, it is actually perfectly fine for 2 or more threads to have read or write access to the same variable as long as it's atomic read/write... you just have to know what that means for your program.
Batman was right that after using Java's threading this NTPL trace looks pretty lame. Not only is the threading and locking in Java braindead simple, but the JVM actually tells you what is wrong. For instance it detects deadlocks and gives you the complete call trace of each deadlocked thread.
Other languages have good locking too (ruby for instance), so it's more that everything is difficult and crappy in C and its kind. I guess if you are stuck writing a threaded application in C in the first place this tracing library could be useful. Of course if you use the heap you're going to also want to replace malloc/free with a fast multithreaded version and then do a bunch of hacks so that it isn't ridiculously slow (locking on every free()... now *that's* inefficient).
As long as I'm paying my virtual tax in virtual currency. I'm sure the creative folks at the IRS will be able to figure out what to do with 1 billion gold. Maybe we can even get a bridge from Alaska to Kalimdor out of it.
This would be perfect for touch screens since the software would be able to tell where the center was. Even though your finger may be very large, it approaches a specific point as you touch the screen. So you might 'touch' several on-screen buttons, but the mac would know (or at least have a better idea) which one you were trying for. It could also let you move things without actually touching the screen, so dragging wouldn't need constant pressure.
"Communications Opportunity, Promotion and Enhancements Act of 2006."
When will people just stop using their "Clear Skies" aka "Clearly Incorrect" propoganda labels attached to the bills? Just say the bill introduced yesterday which legalizes a tiered internet and removes consumer rights to resell internet services, which from a quick glance seems far more accurate a description. Once they actually introduce it refer to it as HR1126 or whatever its id is. With some alphanumeric id people don't automatically get an opinion without RTFA.
At least put a "so-called" in from of the title. Of course it is kinda handy to just apply "!(Title)" and know what the bill is actually for...
The *only* thing I leared from preparing and winning the regionals was dynamic programming. But I actually learned that in class.
The problems are such that there are two skills involved in winning: 1) writing bug-free small programs and 2) understanding the wording of the problem. The first favors asian cultures which teach more by rote and are higher pressure and more exacting.
I don't think that the internationals are translated into the team's native language, but if so that would definitely be a huge bonus for them. English is very vague but also very expressive (or at least how they write the problems is). Chinese for example is not, for instance you don't say 'have you eaten yet?' you say 'eat, no eat?' and you are supposed to understand from context what that means. So, if translated, the problems would really have to explain exactly what was meant instead of being close enough.
I think the loss of Dr. Henry also had something to do with the showing this year. We'll all miss her, that knew her. =(
>Typically the overhead (descriptors that say the same thing?) isn't all that nasty even with 4k pages since you don't *have* to map the full 4MB that a complete 2 level page table would need.
All physical memory in the system is in use at all times with a good os, if only for caching data. Thus it has a page table entry. Pretty much all linux distros use 4k pages. So yes, you don't need a page table entry for memory you don't physically have, big deal.
If you really don't think this is 'not that nasty' explain why an app can't use more than ~80% of the physical memory on a typical linux distro? It's trivial to write a program that keeps growing an array and touching the pages. Once you get near 80% it's dead from swapping even with nothing else running at all.
>>It takes ~1200 cycles just to enter a system call because of using vm for process separation
>How's that? There's no context switch. The kernel is mapped into every user process.
I know this from actually timing it (ie sysenter), of course it varies slightly depending mostly on the processor. Duh. With a single memory space this equates to a function call to a known address, so is basically instant.
>So you're taking less of a hit doing JIT than managing separate address spaces? How's that work?
Not all safe code has to be JIT compiled, for example it can be compiled by a trusted compiler as in libmo/dis. Second, JITs work very well. Java raw numerics code is sometimes equal to C speed despite its limitations like no unsigned types, array bounds, no pointer arithmetic, etc. Java heap is significantly faster than malloc/free. Now take off all the time for tlb flushes, interrupts, multiple-copied memory, page table magic, etc in a system like linux. Replace the heap with a vm-optimized garbage collector (using dirty bit, etc) and it gets even faster.
>I sincerely hope you don't believe what you're saying.
Yeah and I hope what I'm saying isn't the case, because it's freakin sad a) that uninformed people like you AC exist and b) that we're stuck with this crap we call unix / nt / osx because of inertia.
Unfortunately it is, and we are.
Well in general wind farms suck. They actually take enough energy out of the air to make a difference to the environment. That shouldn't be a big surprise, after all wind doesn't really have that much energy in it in the first place compared to water, geothermal, etc.
Nuclear is great if done right, like reactors that cannot melt down. If only the administration's nuclear policy was promoting those. Nope, they want the crappy ones that can poison everything for hundreds of miles so they can get more corporate welfare and tax breaks maintaining them.
It would be pretty good if we liquified coal and removed the sulfur and other pollutants, but instead we are just relax the quality standards so we can put even more murcury into the air to poison us.
So green energy is not really about the source, it's how it is done. You can put some windmills in, but not a freakin million of them. But I can tell you, if we spend 500 billion dollars on any kinds of green energy we would be in a much better place than we are now.
Parent poster was correct in this case, Linux is talking about using COW for data passed to system calls like write. Ie so you call write with a 1 gig buffer and instead of copying 1 gig of memory before writing it out to disk/network/etc it just makes the 1 gig read only (or copy on write) and then it can just write it out, in-place.
So with this syscall glibc could for instance make a fast_write call that has the same api, but it tells the kernel that the memory can be made read-only until the kernel is finished with it.
I totally agree with that, I just go one step further and say that Torvalds is also a total idiot: VM games are bad, so use copying instead because that's less bad. But copying is also bad, so why it at all? Neither are good solutions.
The problem is that linux and bsd are using "virtual memory" to protect processes from each other, but it is designed to run programs that use more memory than is available. Does it sound right that to protect one process from another you are going to use hundreds of thousands of descriptors for each 4k that all say the same thing? It's pretty stupid actually. 4k is too fine-grained for virtual memory these days as disks have grown. It's both too small and too large for process separation.
The better solution is to use vm for virtual memory and run all code in the same memory space, but only run code that cannot access memory illegally (ie no pointer arithmetic, only references). This code could be written in Java, or libmo, or D, or maybe other 'safe' languages and run at much faster speeds than they do now as traditional linux processes. The code could be straight C that is JIT recompiled/checked to prevent illegal accesses. That's right, I claim that an average Java program would run faster in such a system than a C program does under a linux/bsd-like system.
Linus is right, there is massive overhead from doing vm games -- like what is done in linux for instance to separate processes. Did you even wonder why you can't use more than about 80% of the physical memory simultaneously (ie walk an array of 80% physical mem size and see what happens)? That's right, the kernel is using that much as overhead and about 7% of that is page tables for *physical memory*. It takes ~1200 cycles just to enter a system call because of using vm for process separation vs maybe 5 using a single memory space. Unix kernels do not give fine-grained access to anything because it's simply not possible with process separation based on vm to do so, not in practice.
The main problem is that the CPUs are only designed for high-level parallelism. So you don't get much benefit from Haskell of Erlang because they could theoretically say "run this loop of 1..10 as two loops 1..5 and 6..10", but in practice doing so would be much slower on today's multi-core multiprocessors due to the setup overhead.
I actually have a brand new dual-core box and the gnome System Monitor shows both cpu's separately. The only time I've seen both cpu's used by a single program it was a Java program. So I don't really understand where you are coming from. Today's multiprocessors are designed for high-level parallelism that the programmer has to declare in some way, and Java is excellent for this (C# to a somewhat lesser degree).
Now a language like Erlang or Scheme could get a huge performance boost from processors like the now-outdated Tera MTA (aka Cray), which was the inspiration for Sun's MAJC processor. These have hardware threading, so the language compiler can break loops out into multiple threads with next to no overhead. This also benefits Java to some extent since it has moderately better rules regarding aliasing for instance than C#. C/C++ can also benefit automatically with 'loose' compilers, macros, and generally a lot of work on the programmer's side.