Have you seen the Office code base? No? Then stop talking out of your ass. There's no reason to believe that Microsoft's code base is any more "convoluted" than OO.o's (which is derived from the years-old closed code of the old StarOffice).
In short, two lines of code caused an error in Mac Word that preventing saving data entirely in some cases. It took them years to fix this bug even though not being able to save your data should be a pretty high priority fix.
The reason was "the overall complexity ofthe software". The author was talking about the number of features Word has, but he works for Microsoft (like he's actually going to say the code is a mess and risk getting fired?). In any case if you read on you'll see the description of their document format, and how there could be plenty of problems loading another format.
I have seen lots of posts saying it is some scheme for dividing and conquering, or creating more work for open source people, etc, but the real story is that the Office codebase is so convoluted and fragile that they need a document format that favorable to how Office works... friendly to its data structures and whatnot.
Basically the only innovation to Office in the last 4+ years has been in the UI, and I don't think that is an accident. An interface just issues commands to the document engine, so it's fairly simple to rework. But loading a new document format is much more closely tied to the actual engine. For example, if the structures are not defined the same way it may be necessary to create caches (hashtables say) of elements during loading. And also their code is designed around a format where a document is not written out completely, but is document with a set of changes (so that saves and timed backups are immediate without having to regen the whole doc).
So I think it is very likely that the real reason Microsoft is so adamant against the open formats is that they've talked to their engineers who have said it will take 5 years to fully support the new format (for ex, make backup saves happen in background so user isn't annoyed). Or they've got developers that have just said "f'that I'll f'ing leave before touching that crap".
Fox News: They're trying to criminalize astrometrics.
Bush: I mean some people are actually saying Neptune shouldn't have gotten involved in the Kuiper Belt. I disagree. The danger to the solar system from rogue celestial bodies is immense. It must be dealt with. And Neptune has been making a lot of progress in the war on asteroids, but there's a lot of work left to be done. Neptunians must understand that this is a difficult issue. It is going to take time. In a few millenia and there will be stable orbits in kuiper belt. I mean what kind of message would that send to its moons if Neptune just pulled back its gravity? It just can't do that. Neptune has to support its moons....
Parent poster is completely wrong when he says there is an infinite supply (in terms of market forces). The reality is that supply is always identical to demand.
Digital supply == Digital demand.
That's the key to understanding Apple's success with iTunes; the magic 99 cent is what people will pay for a song. The price won't necessarily go down since market forces will tend to keep the price the same, at the product's real value. So if songs are worth 99 cents to consumers, that's what the price will be. If the songs are worth more by being popular or hyped then their value and so their prices will naturally increase. You can think of it like this, where if you were to re-sell iTunes songs for less you would be losing money since people value them higher then you are selling for.
What really confuses the issue is the non-market forces, the primary one being altruism. Your friend lets you copy his 5tb music collection because he likes you and wants you to have it; otherwise he could make considerable cash from it. Same with the p2p sharer... he shares things he wants other people to listen to. These forces are the ones the companies really are scared of, because that's supposed to be their job.
With the oil fields being so old, did you ever wonder what is in them? I suppose not much would survive so much pressure and time, but couldn't there be vast amounts of prehistoric dna floating around in there?
From the responses it sounds like he did an honest attempt at this study. I think the conclusion however should be that stupid admins cost a lot, so taking away things they could mess up is the key to lowering costs. If it turned out that the windows admins had to actually do anything, I bet the results would have been just as bad or worse for Windows.
If I understand the study correctly, the windows side had to do nothing but set up a server to do a few different tasks over time and run windows update. The linux side had to have have multiple incompatible versions of their database server running simultaneously on a single system and had to run unsupported versions of software to do it.
Why wasn't the windows side required to run multiple versions of IIS or SQL server simultaneously? In real life if you need to run multiple database versions you use virtualization or multiple systems, especially if one requires untested software. You don't run some hokie unstable branch on the same system as everything else. Why was a linux solution picked that required this level of work? My other related question is, did any of the unix administrators question why there were being asked to do such a thing? For example, did they come back and say they need a license for vmware? If they did not they do not seem like very competent administrators in my opinion.
The link to the study is for a different one, comparing RHEL to Windows. Here is the actual study and slashdot article for the right one, comparing to SUSE.
C: The old interface is complicated D: They ran out of actual features to add E: The code base is too hacked so non-cosmetic changes are too difficult F:... G: profit!
Seriously their old interface has dozens of toolbars with rows and rows of icons, some of which come and go as you click on things. *If* you spent hours customizing it you could get something minimal and/or usable *for you*. It was complicated and ugly.
The new interface has all the actions for a particular user-centric task. Yes, you have to keep flipping tabs to do things but it's clear which tab you should be on, and on each tab it's easy to find the action you want. Most people probably had to hunt around in the menus anyway to find obscure things, now they just stay open as a big fat tabbed-toolbar area instead.
I think it's a great change for something so complicated and with so many actions. I would also add a small global area for the last N tools/actions used though, to gracefully handle the case of when you do something that would have you switching back and forth tabs.
Well you probably want it to come back again too... if it was in two parts you could just eject one part the opposite direction with a giant cord attached to it. After the asteroid course was changed you could just reel the parts back together again. With some kind of 'cord' that could become rigid you could use solar power or nuclear power push/pull the pieces and so deflect any number of asteroids. And if there was some emergency you could also project one half into the path of the asteroid to break it up a bit.
Instead of a binary kernel layer what linux needs is a bytecode interpreter layer... a Java-esque langage for running processes in the kernel address space.
For a simple "find ~ |..." over 20% of the real time is wasted just between system call overhead (~1200 cycles) and actually copying data in/out of kernel mode. That doesn't even include the time setting up the copyin/out (it has to add the instruction address to a list for the interrupt handler in case there's a fault, which might have to do a lock I didn't check). And that doesn't even include overhead of context switching time (ie 2 context switches every 4k or 16k for the pipe read/write)! There's no reason a context switch should be taking milliseconds on a modern system. It should be microseconds.
MS Singularity is just their version of jxos - pure Java OS. Their version is actually somewhat worse than jxos, since that at least includes a functional AWT user interface, simple network stack, nfs server, ext filesystem, and minesweeper (you can even try it in vmware, just download the boot disk image). Last I checked singularity had a command-line only interface. It is equivalent to a school project, but that doesn't mean the approach is wrong... it isn't.
Of course neither are as advanced or usable as Sun's JavaOS... I wish they would open source that! Monolithic unsafe kernels are old hat. They suck in so many ways it isn't even funny.
Yes but the guy said he had to turn off smoothing to get it to look okay. OO.o is probably using a different rendering library that doesn't honor the desktop setting, so then OO.o in particular would really look bad on his system. Also I've seen gnome programs lose their settings when run from kde, so for instance the toolbars use the default settings (which look ugly imo).
I agree that a "-1 ignorant" mod would help out in a lot of topics... intelligent design, bush, java...
Bring up the blurry fonts on Linux and you get modded troll because 'they look fine to me'. But on some systems the *do* look *much* worse than Windows' fonts. For example, the Dell 1703FP monitor uses v-shaped pixels (they literally look like this: >>>>>>... for RGBRGB...). The linux fonts look like crap on this monitor no matter what unless the smoothing is turned off, in which case they look okay but have hard, jagged edges.
I have another linux system with a viewsonic monitor and the fonts look okay on it so I know where the mod's are coming from, but the point is that the Windows fonts look good on both monitors. I think the main difference is that fonts in windows are rendered to pixels instead of points, so they can tweak the hinting and whatnot to always produce a crisp image regardless of monitor.
Anyway I just wanted to point out that people complaining about linux fonts are not always retards and whiners.
Yes, but what Blizzard is doing far worse than most spyware. If you are playing the game, every patch requires you do agree to several EULAs all over again. Sometimes a server reset also causes this. Typically you need to click "I agree" to a 20+ page agreement several times a week. Furthermore, there is no indication given that the agreement changed; there certainly isn't a promenint "changes since previous agreement" at the top or a version number.
It's the same thing any of those repeated questions, like "Do you really want to delete this file?". People just click yes out of habit and end up deleting the file they wanted to save. So in this respect not only is Blizzard trying to slip one past you by writing a long and complicated EULA, but also they are actively using your human nature against you.
Every speed test where they try to proove that Java or.Net is faster than C or C++ uses allocation and freeing of memory in some loop. Just take any test where Java was faster and test loop to make 2^32 instead of 1000 or 10000 calls.
Wrong. Java typically wins the FFT microbenchmarks where there is *zero* memory allocation. Making the test run over and over actually improves Java's performance. Typically in microbenchmarks that involve memory, Java recognizes that the objects are short-lived and deletes them with almost no work involved. It's not that the GC isn't running at the end, because if you do -verbose:gc you'll see it runs hundreds of times in these tests (ie so it could only make 1/100th of a difference by not runnning at the end). But for most naive microbenchmarks you really want to be comparing Java "new" to C's stack-based variables.
Take for example the 'language shootout'. Java does poorly because a) they try to correct for startup time by running the test with 0 iterations, but this means Java won't even load classes used inside the actual test. b) the tests are rigged, for example in one string processing test the C version uses a byte[256] ascii-only lookup table compared to Java using unicode for 3 method calls and iirc 2 if statements (ie, it's not even remotely comparable). c) so that long-running languages complete they use a low the number of iterations, which magnifies the errors measuring startup time which are not taken into account (profiling, loading classes, etc); they should measure bandwidth for x seconds not time to do x iterations, but even the easy way of just varying the iteractions until it completes in close to a given time is apparently too hard.
If you actually create a program that does the same code (no cheating using lookup tables in C and not Java, do the bounds checks in C) you'll see Java is *much* faster than the equivalent C. So it's not so much about Java being slow as being a really fast, safe version of C.
Start gimp, create a 1024x1024 image. Select gradient tool, disable dithering/sampling Draw black->white gradient top to bottom of image Zoom in a bunch.
You should see a band every 4 "gimp pixels" since 1024 / (2^8) == 4. If you only have 6-bit color you'll get a band every 1024 / (2^6) == 16 pixels.
Anybody know it that's correct or not? Is it that 6 bits of the color settle in 8ms/3ms/whatever and the other 2 bits settle later, or is it just 6bits per color no matter what?
They just didn't want to have to explain the last part so they used the title clause instead of the morality clause. That's why it took so long for somebody to tell him why his name was changed.
why there are so many dupes, grammer (sic) mistakes, and dirth of quality articles: between Zonk and Taco all the slashdot editors are off playing. Maybe we should just "/join slashdot" in WoW to get our news for nerds.
Do you want those people paid 20k less here, where they will spend some of it on cars, food, etc, or do you want them paid 40k less in India/China? It sucks, but about the only thing that stops this race to the bottom is us being better.
We need to invest in schools and teach our kids skills (like how to reason). It's the only realistic way to prevent sliding into mediocrity.
Yes there are weird hardware effects and for that matter difficulty in using any debugger that make kernel programming harder. I've done kernel programming before. I agree with that. But consider that for instance JavaOS runs the same with memory protection hardware and without it; it doesn't suddenly become significantly less stable or less capable. Drivers don't break.
Perhaps your idea of a mix might work. But isn't that going in the microkernel direction with the microkernel being the " few parts of the kernel that require running in fixed time windows or direct hardware access" and the rest being a protected or managed language?
Yes, exactly. JavaOS is built on a small (several k) microkernel that gives access to the hardware. Same with jxos and surely Microsoft's C# kernel research project. It's not the microkernel that's a bad idea, it's the C/asm implementation and using separate address spaces that necessarily follow from that.
I am curious how much of most running O/S kernels are devoted to O/S services and how much are handling specific hardware (NIC, storage card, video card, etc).
Drivers usually take more code since they often have large tables in the code, and a running system only needs a small fraction of that (most will be modules that are never loaded). So I'd say it's a pretty safe bet that the vast majority of the code in a running kernel is not drivers.
The classic response of someone who has never actually done any serious kernel work.
Maybe so, but if you are trying to imply I don't know what I'm talking about then that's bullshit. I've had no problems writing complicated code in FreeBSD and Linux kernels -- other than it being in C.
There's plenty of "performance-robbing intermediation" in safe languages AND in C, because of the extraordinary lengths that have to be gone to for simple problems (unnecessarily copying buffers, no callbacks, maintaining complicated memory maps, having to maintain manual memory ownership). You say safe languages don't have direct access to the hardware, but that's misleading. For example, if your driver accesses memory through an object (ie, memory.write(location, abyte)) this would get compiled to just an "if (location >= min || location <= max) *(mem+location)=abyte" for example. Or you replace it with an object that does nothing and it gets completely removed, so there is no check and no overhead at all per write (and no safety).
Also you say "there is no someone else in the kernel". Of course there is. You have 4k or so of assembly that gives access to the hardware-specific stuff (memory space registers, page table flush instruction, interrupts). How much of the "someone else" do you think something like Java uses anyway? The core is pretty much *all* written in java. Check our jxos.org's Java operating system. Run it in vmware and you get a simple network stack, *GUI*, processes, etc. It was written by like 2 guys instead of watching TV. This stuff is doable and plenty fast; that's why I describe you as a "naysayer".
What you propose might be good for application space, but part of the reason those tools and applications work is because of the support they get from the kernel and other parts of the base system on which they run.
The vast majority of what a monolithic kernel does *is* application-like. Keeping track of lists and hashtables of sockets, files, processes. Accessing them in O(1) time. Allocating and deallocating memory for those. Keeping track of buffers and balancing cache sizes. These are all the things that object-oriented, managed languages are good at and where C/asm sucks big time.
C is suited for the few parts of the kernel that require running in fixed time windows or direct hardware access. But those places are very few. The fact that the rest of it is in C is because a) that's how it's always been done, b) people are short-sighted and lazy so don't mix safe/unsafe code because it takes more up-front work c) the people writing the kernel code couldn't understand for example the hotspot optimizer if they tried. Hell these people optimize the freakin caches lines to save a few nanoseconds but don't give a crap that you have to run at least 1000 user-space instruction per system call or half the processor time is completely wasted.
You safe-kernel naysaysers act like writing kernel code is hard. It isn't. It just takes a lot of patience and diligence (mostly because it's in C). It's not like there's anything CS-hard in the linux kernel.
It's because traditional microkernels solve the wrong problem. The goal is reliability and flexibility (user-space drivers and whatnot). The wrong problem is using separate memory spaces to achieve the goals. They are just too clumsy... they are ridiculously slow, are coarse grained (4k page is the smallest unit), and you cannot apply a filter to memory accesses.
If the microkernel was combined with a safe language, like Java or C#, then the problems would go away. You wouldn't need to change the page table, so that massive penalty is not there. Accessing memory through a memory object would allow any arbitrary range (down to single bits). You could also apply a filter, so the driver could implement the commands to the disk but the hardware access object would only allow valid use of the bus; this wouldn't be perfect but would greatly increase reliability over microkernels, which are already much more reliable than monolithic.
And speed? It could be faster than C-based code for various reasons (using the dirty bit to accellerate garbage collection, no context switches, etc). It's not like there isn't precendent: the berkely packet filter is actually an interpreted bytecode that is run inside the kernel. It has a number of restrictions to ensure safety (like only branching forwards), but basically in all unix operating systems it is a giant switch statement that interprets the bytecode. This is plenty fast enough to handle the packets, orders of magnitude faster than sending the packets into user-space.
If Tanenbaum really cared about reliability or safety or simplicity he would make a managed microkernel, not more of this C/asm based crap.
It seems to me that blurry interfaces are a very bad idea. If you look at something blurry your eye automatically tries to put it in focus. But that's impossible since when it's in focus it is still blurry. Seems to me all this blurriness in the new Windows interface will cause problems with eyesight, kind of like carpal tunnel, where the body isn't meant to work that way.
If you look you'll see Mac OS X's interface there is nothing blurry. Their default wallpapers are not blurry and the only thing even close to blurry is the window shadows, which aren't really blurry but are gradients. Once again Apple did 3d the right way and Microsoft is a bad copy.
Slashdot Mirror
Have you seen the Office code base? No? Then stop talking out of your ass. There's no reason to believe that Microsoft's code base is any more "convoluted" than OO.o's (which is derived from the years-old closed code of the old StarOffice).
/ 19/135315.aspx
Anatomy of a Software Bug:
http://blogs.msdn.com/rick_schaut/archive/2004/05
In short, two lines of code caused an error in Mac Word that preventing saving data entirely in some cases. It took them years to fix this bug even though not being able to save your data should be a pretty high priority fix.
The reason was "the overall complexity ofthe software". The author was talking about the number of features Word has, but he works for Microsoft (like he's actually going to say the code is a mess and risk getting fired?). In any case if you read on you'll see the description of their document format, and how there could be plenty of problems loading another format.
I have seen lots of posts saying it is some scheme for dividing and conquering, or creating more work for open source people, etc, but the real story is that the Office codebase is so convoluted and fragile that they need a document format that favorable to how Office works... friendly to its data structures and whatnot.
Basically the only innovation to Office in the last 4+ years has been in the UI, and I don't think that is an accident. An interface just issues commands to the document engine, so it's fairly simple to rework. But loading a new document format is much more closely tied to the actual engine. For example, if the structures are not defined the same way it may be necessary to create caches (hashtables say) of elements during loading. And also their code is designed around a format where a document is not written out completely, but is document with a set of changes (so that saves and timed backups are immediate without having to regen the whole doc).
So I think it is very likely that the real reason Microsoft is so adamant against the open formats is that they've talked to their engineers who have said it will take 5 years to fully support the new format (for ex, make backup saves happen in background so user isn't annoyed). Or they've got developers that have just said "f'that I'll f'ing leave before touching that crap".
Fox News: They're trying to criminalize astrometrics.
...
Bush: I mean some people are actually saying Neptune shouldn't have gotten involved in the Kuiper Belt. I disagree. The danger to the solar system from rogue celestial bodies is immense. It must be dealt with. And Neptune has been making a lot of progress in the war on asteroids, but there's a lot of work left to be done. Neptunians must understand that this is a difficult issue. It is going to take time. In a few millenia and there will be stable orbits in kuiper belt. I mean what kind of message would that send to its moons if Neptune just pulled back its gravity? It just can't do that. Neptune has to support its moons.
Parent poster is completely wrong when he says there is an infinite supply (in terms of market forces). The reality is that supply is always identical to demand.
Digital supply == Digital demand.
That's the key to understanding Apple's success with iTunes; the magic 99 cent is what people will pay for a song. The price won't necessarily go down since market forces will tend to keep the price the same, at the product's real value. So if songs are worth 99 cents to consumers, that's what the price will be. If the songs are worth more by being popular or hyped then their value and so their prices will naturally increase. You can think of it like this, where if you were to re-sell iTunes songs for less you would be losing money since people value them higher then you are selling for.
What really confuses the issue is the non-market forces, the primary one being altruism. Your friend lets you copy his 5tb music collection because he likes you and wants you to have it; otherwise he could make considerable cash from it. Same with the p2p sharer... he shares things he wants other people to listen to. These forces are the ones the companies really are scared of, because that's supposed to be their job.
With the oil fields being so old, did you ever wonder what is in them? I suppose not much would survive so much pressure and time, but couldn't there be vast amounts of prehistoric dna floating around in there?
From the responses it sounds like he did an honest attempt at this study. I think the conclusion however should be that stupid admins cost a lot, so taking away things they could mess up is the key to lowering costs. If it turned out that the windows admins had to actually do anything, I bet the results would have been just as bad or worse for Windows.
If I understand the study correctly, the windows side had to do nothing but set up a server to do a few different tasks over time and run windows update. The linux side had to have have multiple incompatible versions of their database server running simultaneously on a single system and had to run unsupported versions of software to do it.
Why wasn't the windows side required to run multiple versions of IIS or SQL server simultaneously? In real life if you need to run multiple database versions you use virtualization or multiple systems, especially if one requires untested software. You don't run some hokie unstable branch on the same system as everything else. Why was a linux solution picked that required this level of work? My other related question is, did any of the unix administrators question why there were being asked to do such a thing? For example, did they come back and say they need a license for vmware? If they did not they do not seem like very competent administrators in my opinion.
The link to the study is for a different one, comparing RHEL to Windows. Here is the actual study and slashdot article for the right one, comparing to SUSE.
or because...
...
C: The old interface is complicated
D: They ran out of actual features to add
E: The code base is too hacked so non-cosmetic changes are too difficult
F:
G: profit!
Seriously their old interface has dozens of toolbars with rows and rows of icons, some of which come and go as you click on things. *If* you spent hours customizing it you could get something minimal and/or usable *for you*. It was complicated and ugly.
The new interface has all the actions for a particular user-centric task. Yes, you have to keep flipping tabs to do things but it's clear which tab you should be on, and on each tab it's easy to find the action you want. Most people probably had to hunt around in the menus anyway to find obscure things, now they just stay open as a big fat tabbed-toolbar area instead.
I think it's a great change for something so complicated and with so many actions. I would also add a small global area for the last N tools/actions used though, to gracefully handle the case of when you do something that would have you switching back and forth tabs.
Well you probably want it to come back again too... if it was in two parts you could just eject one part the opposite direction with a giant cord attached to it. After the asteroid course was changed you could just reel the parts back together again. With some kind of 'cord' that could become rigid you could use solar power or nuclear power push/pull the pieces and so deflect any number of asteroids. And if there was some emergency you could also project one half into the path of the asteroid to break it up a bit.
Instead of a binary kernel layer what linux needs is a bytecode interpreter layer... a Java-esque langage for running processes in the kernel address space.
..." over 20% of the real time is wasted just between system call overhead (~1200 cycles) and actually copying data in/out of kernel mode. That doesn't even include the time setting up the copyin/out (it has to add the instruction address to a list for the interrupt handler in case there's a fault, which might have to do a lock I didn't check). And that doesn't even include overhead of context switching time (ie 2 context switches every 4k or 16k for the pipe read/write)! There's no reason a context switch should be taking milliseconds on a modern system. It should be microseconds.
For a simple "find ~ |
MS Singularity is just their version of jxos - pure Java OS. Their version is actually somewhat worse than jxos, since that at least includes a functional AWT user interface, simple network stack, nfs server, ext filesystem, and minesweeper (you can even try it in vmware, just download the boot disk image). Last I checked singularity had a command-line only interface. It is equivalent to a school project, but that doesn't mean the approach is wrong... it isn't.
Of course neither are as advanced or usable as Sun's JavaOS... I wish they would open source that! Monolithic unsafe kernels are old hat. They suck in so many ways it isn't even funny.
Yes but the guy said he had to turn off smoothing to get it to look okay. OO.o is probably using a different rendering library that doesn't honor the desktop setting, so then OO.o in particular would really look bad on his system. Also I've seen gnome programs lose their settings when run from kde, so for instance the toolbars use the default settings (which look ugly imo).
I agree that a "-1 ignorant" mod would help out in a lot of topics... intelligent design, bush, java...
Bring up the blurry fonts on Linux and you get modded troll because 'they look fine to me'. But on some systems the *do* look *much* worse than Windows' fonts. For example, the Dell 1703FP monitor uses v-shaped pixels (they literally look like this: >>>>>>... for RGBRGB...). The linux fonts look like crap on this monitor no matter what unless the smoothing is turned off, in which case they look okay but have hard, jagged edges.
I have another linux system with a viewsonic monitor and the fonts look okay on it so I know where the mod's are coming from, but the point is that the Windows fonts look good on both monitors. I think the main difference is that fonts in windows are rendered to pixels instead of points, so they can tweak the hinting and whatnot to always produce a crisp image regardless of monitor.
Anyway I just wanted to point out that people complaining about linux fonts are not always retards and whiners.
Yes, but what Blizzard is doing far worse than most spyware. If you are playing the game, every patch requires you do agree to several EULAs all over again. Sometimes a server reset also causes this. Typically you need to click "I agree" to a 20+ page agreement several times a week. Furthermore, there is no indication given that the agreement changed; there certainly isn't a promenint "changes since previous agreement" at the top or a version number.
It's the same thing any of those repeated questions, like "Do you really want to delete this file?". People just click yes out of habit and end up deleting the file they wanted to save. So in this respect not only is Blizzard trying to slip one past you by writing a long and complicated EULA, but also they are actively using your human nature against you.
Every speed test where they try to proove that Java or .Net is faster than C or C++ uses allocation and freeing of memory in some loop. Just take any test where Java was faster and test loop to make 2^32 instead of 1000 or 10000 calls.
Wrong. Java typically wins the FFT microbenchmarks where there is *zero* memory allocation. Making the test run over and over actually improves Java's performance. Typically in microbenchmarks that involve memory, Java recognizes that the objects are short-lived and deletes them with almost no work involved. It's not that the GC isn't running at the end, because if you do -verbose:gc you'll see it runs hundreds of times in these tests (ie so it could only make 1/100th of a difference by not runnning at the end). But for most naive microbenchmarks you really want to be comparing Java "new" to C's stack-based variables.
Take for example the 'language shootout'. Java does poorly because a) they try to correct for startup time by running the test with 0 iterations, but this means Java won't even load classes used inside the actual test. b) the tests are rigged, for example in one string processing test the C version uses a byte[256] ascii-only lookup table compared to Java using unicode for 3 method calls and iirc 2 if statements (ie, it's not even remotely comparable). c) so that long-running languages complete they use a low the number of iterations, which magnifies the errors measuring startup time which are not taken into account (profiling, loading classes, etc); they should measure bandwidth for x seconds not time to do x iterations, but even the easy way of just varying the iteractions until it completes in close to a given time is apparently too hard.
If you actually create a program that does the same code (no cheating using lookup tables in C and not Java, do the bounds checks in C) you'll see Java is *much* faster than the equivalent C. So it's not so much about Java being slow as being a really fast, safe version of C.
Start gimp, create a 1024x1024 image.
Select gradient tool, disable dithering/sampling
Draw black->white gradient top to bottom of image
Zoom in a bunch.
You should see a band every 4 "gimp pixels" since 1024 / (2^8) == 4.
If you only have 6-bit color you'll get a band every 1024 / (2^6) == 16 pixels.
Anybody know it that's correct or not? Is it that 6 bits of the color settle in 8ms/3ms/whatever and the other 2 bits settle later, or is it just 6bits per color no matter what?
CmdrTaco -> Command Her Taco
They just didn't want to have to explain the last part so they used the title clause instead of the morality clause. That's why it took so long for somebody to tell him why his name was changed.
License plate 101.
why there are so many dupes, grammer (sic) mistakes, and dirth of quality articles: between Zonk and Taco all the slashdot editors are off playing. Maybe we should just "/join slashdot" in WoW to get our news for nerds.
Do you want those people paid 20k less here, where they will spend some of it on cars, food, etc, or do you want them paid 40k less in India/China? It sucks, but about the only thing that stops this race to the bottom is us being better.
We need to invest in schools and teach our kids skills (like how to reason). It's the only realistic way to prevent sliding into mediocrity.
A very reasonable response. Thank you.
Yes there are weird hardware effects and for that matter difficulty in using any debugger that make kernel programming harder. I've done kernel programming before. I agree with that. But consider that for instance JavaOS runs the same with memory protection hardware and without it; it doesn't suddenly become significantly less stable or less capable. Drivers don't break.
Perhaps your idea of a mix might work. But isn't that going in the microkernel direction with the microkernel being the " few parts of the kernel that require running in fixed time windows or direct hardware access" and the rest being a protected or managed language?
Yes, exactly. JavaOS is built on a small (several k) microkernel that gives access to the hardware. Same with jxos and surely Microsoft's C# kernel research project. It's not the microkernel that's a bad idea, it's the C/asm implementation and using separate address spaces that necessarily follow from that.
I am curious how much of most running O/S kernels are devoted to O/S services and how much are handling specific hardware (NIC, storage card, video card, etc).
Well in latest linux kernel:
1,133,377 lines: fs/ crypto/ ipc/ kernel/ lib/ mm/ net/ security/
2,747,365 lines: drivers/
Drivers usually take more code since they often have large tables in the code, and a running system only needs a small fraction of that (most will be modules that are never loaded). So I'd say it's a pretty safe bet that the vast majority of the code in a running kernel is not drivers.
The classic response of someone who has never actually done any serious kernel work.
Maybe so, but if you are trying to imply I don't know what I'm talking about then that's bullshit. I've had no problems writing complicated code in FreeBSD and Linux kernels -- other than it being in C.
There's plenty of "performance-robbing intermediation" in safe languages AND in C, because of the extraordinary lengths that have to be gone to for simple problems (unnecessarily copying buffers, no callbacks, maintaining complicated memory maps, having to maintain manual memory ownership). You say safe languages don't have direct access to the hardware, but that's misleading. For example, if your driver accesses memory through an object (ie, memory.write(location, abyte)) this would get compiled to just an "if (location >= min || location <= max) *(mem+location)=abyte" for example. Or you replace it with an object that does nothing and it gets completely removed, so there is no check and no overhead at all per write (and no safety).
Also you say "there is no someone else in the kernel". Of course there is. You have 4k or so of assembly that gives access to the hardware-specific stuff (memory space registers, page table flush instruction, interrupts). How much of the "someone else" do you think something like Java uses anyway? The core is pretty much *all* written in java. Check our jxos.org's Java operating system. Run it in vmware and you get a simple network stack, *GUI*, processes, etc. It was written by like 2 guys instead of watching TV. This stuff is doable and plenty fast; that's why I describe you as a "naysayer".
What you propose might be good for application space, but part of the reason those tools and applications work is because of the support they get from the kernel and other parts of the base system on which they run.
The vast majority of what a monolithic kernel does *is* application-like. Keeping track of lists and hashtables of sockets, files, processes. Accessing them in O(1) time. Allocating and deallocating memory for those. Keeping track of buffers and balancing cache sizes. These are all the things that object-oriented, managed languages are good at and where C/asm sucks big time.
C is suited for the few parts of the kernel that require running in fixed time windows or direct hardware access. But those places are very few. The fact that the rest of it is in C is because a) that's how it's always been done, b) people are short-sighted and lazy so don't mix safe/unsafe code because it takes more up-front work c) the people writing the kernel code couldn't understand for example the hotspot optimizer if they tried. Hell these people optimize the freakin caches lines to save a few nanoseconds but don't give a crap that you have to run at least 1000 user-space instruction per system call or half the processor time is completely wasted.
You safe-kernel naysaysers act like writing kernel code is hard. It isn't. It just takes a lot of patience and diligence (mostly because it's in C). It's not like there's anything CS-hard in the linux kernel.
It's because traditional microkernels solve the wrong problem. The goal is reliability and flexibility (user-space drivers and whatnot). The wrong problem is using separate memory spaces to achieve the goals. They are just too clumsy... they are ridiculously slow, are coarse grained (4k page is the smallest unit), and you cannot apply a filter to memory accesses.
If the microkernel was combined with a safe language, like Java or C#, then the problems would go away. You wouldn't need to change the page table, so that massive penalty is not there. Accessing memory through a memory object would allow any arbitrary range (down to single bits). You could also apply a filter, so the driver could implement the commands to the disk but the hardware access object would only allow valid use of the bus; this wouldn't be perfect but would greatly increase reliability over microkernels, which are already much more reliable than monolithic.
And speed? It could be faster than C-based code for various reasons (using the dirty bit to accellerate garbage collection, no context switches, etc). It's not like there isn't precendent: the berkely packet filter is actually an interpreted bytecode that is run inside the kernel. It has a number of restrictions to ensure safety (like only branching forwards), but basically in all unix operating systems it is a giant switch statement that interprets the bytecode. This is plenty fast enough to handle the packets, orders of magnitude faster than sending the packets into user-space.
If Tanenbaum really cared about reliability or safety or simplicity he would make a managed microkernel, not more of this C/asm based crap.
It seems to me that blurry interfaces are a very bad idea. If you look at something blurry your eye automatically tries to put it in focus. But that's impossible since when it's in focus it is still blurry. Seems to me all this blurriness in the new Windows interface will cause problems with eyesight, kind of like carpal tunnel, where the body isn't meant to work that way.
If you look you'll see Mac OS X's interface there is nothing blurry. Their default wallpapers are not blurry and the only thing even close to blurry is the window shadows, which aren't really blurry but are gradients. Once again Apple did 3d the right way and Microsoft is a bad copy.