Im annoyed hearing how the PS3s 2x speed BD drive is slower than the far cheaper Xbox 360 DVD drive. Its about 9MB per second vs the Xbox's 15MB, basically half the speed! For things like loading times, this is not a good thing.
True. This is a bit annoying. The 2x BD driver in the PS3 is slower (72Mbps) than the 12x DVD driver in XBox360 (66--22Mbps) for the most part of the disc.
Geez. I know people love Sony bashing and all that, but does that mean that obvious trolls need to be modded as "insightful". Some comments:
Blu-ray prices shooting up --- You can hardly blame Sony for retailers taking advantage of the situation and increasing their profit margins. I suspect the same would have been true if HD-DVD had emerged as the winning format.
Incompatible early BD players --- You're talking complete and utter rubbish. Older players can still play newer movies. They will just not be able to take advantage of Profile 2.0 features such as viewing online contents related to the movie.
PS3 crippled by Blu-ray --- While people might argue that quality of PS3 games is outshined by its rivals, putting the blame on the Blu-ray drive is wide off target. Do you seriously believe the quality of games would magically get better if they were distributed on DVDs?
Oh, and by the way, it's called "Blu-ray", not "Blue-ray". If you mean to go on a rant about something you should at least have the decency to call it by its proper name.
Right. So (most) bloggers have a strong dislike for Sony and everything they do. How is this news? This is akin to having an analysis of Slashdot postings concluding that most Slashdotters dislike Microsoft. As it turns out, neither bloggers nor Slashdotters give an accurate picture of the demographics of regular consumers. And given that people with a grudge against some idea or company -- in this case Sony -- are always the ones who cry out the loudest, I'm actually surprised that the "analysis" didn't come out even more slanted in HD-DVDs favour.
And what's the deal about 21 percent of the online consumers disliking Blu-ray because Sony included it in the PlayStation 3? I can see several reasons why poeple might resent Blu-ray, but this is definitely not one of them. The only conceivable explanation I can see behind such reasoning is peoples aversion against anything that is Sony.
The problem is that Sony has 27 titles that are close to playable, and none of them are killer apps. Devil May Cry 4 looks like the only decent title that will be available at launch, and the other titles that look good also look like they're a long way off. So what does that leave Sony left to talk about? Yep, they will launch in time for Christmas!
Not suprised. If Sony started up a PS3 marketing hype in August it would probably either 1) cool off before the holiday season, or 2) people would be so fed up with the whole PS3 thing that the marketing might end up working against its purpose. Perfectly understandable that they're doing what they do. It probably opens up up for a much more massive impact once they do go public with the whole deal.
Not to sound pedantic, but many/most people seem to be refering to Blu-ray discs as "BR" or "BR discs". According to the official naming convention the correct abbriviation should be "BD". Again, this is not meant to sound pedantic. It's just annoying to see people (and especially tech savvy people like on Slashdot who really ought to know better) use the wrong abbreviation. Reminds me of the whole "CD disc" thing of the ninetees before people started using CD as a proper noun.
How exactly can a post just containing the subject line "comments I liked" and a quote from the linked article be modded up as "insightful"? I mean, it's not like the poster actually added any actual insight beyond him stating that he liked that particular comment. Just curious.
Because -- depending on how you construct your system -- you don't want to do IPI based messaging to the CPU where the single kernel thread runs whenever you, e.g., get an exception or perform a system call on another CPU. Neither do you want to transfer your cache working set to that CPU.
MkLinux, or L4Linux, or any
pre-virtualization techniques to run Linux on a microkernel, are not considered microkernel versions of Linux. They are simply projects that turn Linux into a monolithic server running on top of the microkernel.
Trying to turn a monolithic kernel into a microkernel has been attempted before. The result was the abomination which is Mach.
Web browsing on the PSP currently leaves a lot to be desired. Are there any plans to port Opera to the PSP? Yes, I know, you've previously said that such a port could easily been done if there was enough demand for it. This was a long time ago, however, and I'm wondering if there have been any recent developments in providing such a port?
You mention security as being an important factor for not choosing IE. Then you mention features, and in particular the possibility of extensions, as a important factor for choosing FF. This doesn't add up. If anything, the extension mechanism in FF should prompt you not to use FF (or at least not use its extensions) if you care about secturity.
You touch upon your problems with high memory usage in FF. Other people around here have complained about this as well, including stories about memory leakage and crashes. The general consensus seems to be that the cause of these problems are the extensions, and not FF itself. It's been said that if you just turn off the extensions everything works fine. Sure, you could do this, but then you take away perhaps the major feature that makes people like FF so much.
So, what does all this tell you? What it should tell you is that the extension mechanism in FF is flawed. Since the FF extenstions can not be properly confined you will always run the risk of malfunctional or malicious extensions accessing and consuming browser resources that it shouldn't.
The good news is that since (to my knowledge) FF extensions are written in XML and ECMAScript rather than, e.g., C, it should in theory be possible to control to a better extent which and how many resources an extenstion has access to. I have too little knowledge about the extension mechanism in FF to say whether such a solution is really feasible, though. All I can say is that if FF is going to take security, stability, and robustness seriously, more effort must be put into properly designing the extension architecture.
And as for Opera not having the same possibilities for extensions as FF, this is IMHO a wise move. Yes, I know that Opera has the User JS stuff, but for some reason this has never caused me any troubles whatsoever. Not that I have much experience with the User JS design or have played around with many User JS extensions, mind you.
3. Add ASSERT() like comments and ASSERT() or equivalent to your code
I can't stress enough how important this is. Not only do asserts tell the programmer looking at the code what the assumptions and invariants are. Asserts also make sure that you are notified immediately when any of these assumptions are not met. This is particularly useful if the result would be incorrect but still usable (and hence not resulting in a crash), or if breaking the assumptions lead to a non-debuggable crash (i.e., within low level systems code).
Just a short note on avoiding the problems of drivers relying on API breakage or some given kernel semantics. An alternative approach to supporting such drivers (in source or binary form) is to embed these drivers in a virtual machine. Such an approach incurs a little bit of overhead, sure, but you also get the added benefit that the direver need not necessarily be trusted by the rest of the system.
And to make matters worse, you get 1 mail a minute from some remote daemon telling you that there is a virus in a message which is apparently from you. Mail administrators who set up such auto-replies shoot be taken out and shot.
It's sort of fun to see people getting all agitated about this. You did fail to mention the French, though, and even if many people in Alsace speak pretty good German (at least people involved in the tourist industry) I'm afraid this isn't really the case for the rest of France.
Anyhow, I happen to live in Germany myself and I've come to learn that English is by far the best language to use for communication within a group consisting of various nationalities -- in particular when applied to computer people (and I still haven't taken Brits and Scandinavians into consideration). From personal experiences I've also learned that many Dutch and Belgians are far better versed in English than in German.
Dont you think its normal that they keep conferences in Germany on a German event in German?
Not necessarily. If they want to reach a broader community they might want to make, e.g., the speeches more accessible by having them in a language that more people can understand. Considering that Karlsruhe (the place where Linux Tag takes place) is only 15-20 minutes away from France, and a few hours drive away from Switzerland, Luxembourg, Belgium and the Netherlands, this might not be a bad idea.
[Sorry for my last post. I happened to press the submit button involuntarily.]
The nature of non-modular things means that they can regress in serious ways (because everything's bunched together). However, the Linux kernel has some pretty significant advantages over the main micro-kernel competitor (BSD's Kernel). It supports more hardware (try getting an HP OfficeJet to work on *BSD). Furthermore, more programs will work with it.
Am I reading you wrong here, or are you considering BSD's kernel (as in FreeBSD, OpenBSD, etc.) to be a microkernel. If so, you are clearly stating your incompetence in this discussion.
I can only assume that you are here referring to Mach and their microkernel based operating systems (BSD Lites, OSF, OS X). The problem with Mach, however, has been widely documented in research from the early and mid 90's. The same research not only identified the problems with Mach, it also showed how the microkernel could be designed to overcome these problems.
The point is, that since macro-kernel's are much easier to get into initially and maintain, they will be superior in practice, despite their inferiority in theory.
Of course, your whole argument rests on the claim that a monolithic (macro kernel based) system is easier to maintain. I've never seen any "proof" of this claim---only anecdotal "evidence" by comparing various systems---and must as such dismiss your conclusions.
Your numbers seem way off. Are you running the benchmark with a cold cache? Since a well designed, e.g., web server would be constructed so that most of its data and code working set would be resident in the cache, the experiment is better performed with warm caches. Here are some other numbers for getpid() performance (all performend on a 1.4GHz Pentium4):
[The small spaces and large spaces indicate the numbers when address space switching is performed via segment register reloading (as explained earlier in this thread).]
As can be seen, your measurement of 18000 cycles is way more than 1540 cycles. You can also see that the 2200 cycles for L4Linux only adds about 30% overhead---despite having to execute two complete IPC operations (i.e., system calls) for communication between the application and the L4Linux server.
One of the reasons why system calls on Linux are so expensive is because they use software interrupts to enter the kernel. If using sysenter/sysexit instructions (syscall/sysenter for AMD processors), the overhead for entering and exiting the kernel can be decreased by an order of magnitude (~160 vs. ~1500 cycles for the 1.4GHz Pentium4).
Sloppy programmer accesses through bad pointer in C. OS traps task.
...with a probability of 0.001%. 99.999% of the times the bad pointer access goes through unnoticed. If only there was a way for the developer to increase the detection rate from 0.001% to 100%.
Sloppy programmer accesses beyond array bounds in MySafeLanguage. Runtime system traps tasks.
...with a probability of 100%. 0% of the times the bad pointer access goes thriough unnoticed. If only there was a way for the developers to increase the detection rate from 100% to 100%.
There are two paradigms at work here. One is the "single user on a single machine running locally." The other is "multiple users on multiple machines running anywhere they want." X11 supports both paradigms. Windows supports only the first. Please don't dumb down X11 to the Windows level.
Nobody's saying that one should rule out on or the other paradigm. One should still be able to support both. The point that David Wexelblat (and others) are arguing is that running the graphical interface on your local machine is by far the most common usage scenario.
Now, higly regarded design philosophies claim that one should optimize the design for the common case while still allowing for all other conceivable usage scenarios. These other usage scenarios might not be supported optimally in the design, though. That is, instead of directly making use of all the internal features of the system, one might need to access them through some translation/abstraction/emulation layer. The fact that one go through all these layers are, however, completely transparent to the application/user. The overhead associated with the extra layering is probably also acceptable to the user. (You don't care if there is some millisecond overhead when running your remote email client or administration utility. You do care if you're experiencing such overhead when utilizing the 3D engine on your graphics hardware, though.)
Slashdot Mirror
- Blu-ray prices shooting up --- You can hardly blame Sony for retailers taking advantage of the situation and increasing their profit margins. I suspect the same would have been true if HD-DVD had emerged as the winning format.
- Incompatible early BD players --- You're talking complete and utter rubbish. Older players can still play newer movies. They will just not be able to take advantage of Profile 2.0 features such as viewing online contents related to the movie.
- PS3 crippled by Blu-ray --- While people might argue that quality of PS3 games is outshined by its rivals, putting the blame on the Blu-ray drive is wide off target. Do you seriously believe the quality of games would magically get better if they were distributed on DVDs?
Oh, and by the way, it's called "Blu-ray", not "Blue-ray". If you mean to go on a rant about something you should at least have the decency to call it by its proper name....and beer prices world wide would skyrocket due to the sudden high demand from third world countries. True, we can't have any of that!
Right. So (most) bloggers have a strong dislike for Sony and everything they do. How is this news? This is akin to having an analysis of Slashdot postings concluding that most Slashdotters dislike Microsoft. As it turns out, neither bloggers nor Slashdotters give an accurate picture of the demographics of regular consumers. And given that people with a grudge against some idea or company -- in this case Sony -- are always the ones who cry out the loudest, I'm actually surprised that the "analysis" didn't come out even more slanted in HD-DVDs favour.
And what's the deal about 21 percent of the online consumers disliking Blu-ray because Sony included it in the PlayStation 3? I can see several reasons why poeple might resent Blu-ray, but this is definitely not one of them. The only conceivable explanation I can see behind such reasoning is peoples aversion against anything that is Sony.
Not to sound pedantic, but many/most people seem to be refering to Blu-ray discs as "BR" or "BR discs". According to the official naming convention the correct abbriviation should be "BD". Again, this is not meant to sound pedantic. It's just annoying to see people (and especially tech savvy people like on Slashdot who really ought to know better) use the wrong abbreviation. Reminds me of the whole "CD disc" thing of the ninetees before people started using CD as a proper noun.
How exactly can a post just containing the subject line "comments I liked" and a quote from the linked article be modded up as "insightful"? I mean, it's not like the poster actually added any actual insight beyond him stating that he liked that particular comment. Just curious.
Because -- depending on how you construct your system -- you don't want to do IPI based messaging to the CPU where the single kernel thread runs whenever you, e.g., get an exception or perform a system call on another CPU. Neither do you want to transfer your cache working set to that CPU.
Trying to turn a monolithic kernel into a microkernel has been attempted before. The result was the abomination which is Mach.
Which is basically the definition of a monolithic kernel. Whether the kernel is multi-threaded, etc., does not matter.
Web browsing on the PSP currently leaves a lot to be desired. Are there any plans to port Opera to the PSP? Yes, I know, you've previously said that such a port could easily been done if there was enough demand for it. This was a long time ago, however, and I'm wondering if there have been any recent developments in providing such a port?
You touch upon your problems with high memory usage in FF. Other people around here have complained about this as well, including stories about memory leakage and crashes. The general consensus seems to be that the cause of these problems are the extensions, and not FF itself. It's been said that if you just turn off the extensions everything works fine. Sure, you could do this, but then you take away perhaps the major feature that makes people like FF so much.
So, what does all this tell you? What it should tell you is that the extension mechanism in FF is flawed. Since the FF extenstions can not be properly confined you will always run the risk of malfunctional or malicious extensions accessing and consuming browser resources that it shouldn't.
The good news is that since (to my knowledge) FF extensions are written in XML and ECMAScript rather than, e.g., C, it should in theory be possible to control to a better extent which and how many resources an extenstion has access to. I have too little knowledge about the extension mechanism in FF to say whether such a solution is really feasible, though. All I can say is that if FF is going to take security, stability, and robustness seriously, more effort must be put into properly designing the extension architecture.
And as for Opera not having the same possibilities for extensions as FF, this is IMHO a wise move. Yes, I know that Opera has the User JS stuff, but for some reason this has never caused me any troubles whatsoever. Not that I have much experience with the User JS design or have played around with many User JS extensions, mind you.
I can't stress enough how important this is. Not only do asserts tell the programmer looking at the code what the assumptions and invariants are. Asserts also make sure that you are notified immediately when any of these assumptions are not met. This is particularly useful if the result would be incorrect but still usable (and hence not resulting in a crash), or if breaking the assumptions lead to a non-debuggable crash (i.e., within low level systems code).
Just a short note on avoiding the problems of drivers relying on API breakage or some given kernel semantics. An alternative approach to supporting such drivers (in source or binary form) is to embed these drivers in a virtual machine. Such an approach incurs a little bit of overhead, sure, but you also get the added benefit that the direver need not necessarily be trusted by the rest of the system.
And to make matters worse, you get 1 mail a minute from some remote daemon telling you that there is a virus in a message which is apparently from you. Mail administrators who set up such auto-replies shoot be taken out and shot.
Actually, France was the first one on my list. I also find it amusing that you assume I am German (and yes, I am still having fun).
Anyhow, I happen to live in Germany myself and I've come to learn that English is by far the best language to use for communication within a group consisting of various nationalities -- in particular when applied to computer people (and I still haven't taken Brits and Scandinavians into consideration). From personal experiences I've also learned that many Dutch and Belgians are far better versed in English than in German.
Not necessarily. If they want to reach a broader community they might want to make, e.g., the speeches more accessible by having them in a language that more people can understand. Considering that Karlsruhe (the place where Linux Tag takes place) is only 15-20 minutes away from France, and a few hours drive away from Switzerland, Luxembourg, Belgium and the Netherlands, this might not be a bad idea.
[Sorry for my last post. I happened to press the submit button involuntarily.]
Not necessarily. If they want to reach a broader community they might want to
Am I reading you wrong here, or are you considering BSD's kernel (as in FreeBSD, OpenBSD, etc.) to be a microkernel. If so, you are clearly stating your incompetence in this discussion.
I can only assume that you are here referring to Mach and their microkernel based operating systems (BSD Lites, OSF, OS X). The problem with Mach, however, has been widely documented in research from the early and mid 90's. The same research not only identified the problems with Mach, it also showed how the microkernel could be designed to overcome these problems.
Of course, your whole argument rests on the claim that a monolithic (macro kernel based) system is easier to maintain. I've never seen any "proof" of this claim---only anecdotal "evidence" by comparing various systems---and must as such dismiss your conclusions.
As can be seen, your measurement of 18000 cycles is way more than 1540 cycles. You can also see that the 2200 cycles for L4Linux only adds about 30% overhead---despite having to execute two complete IPC operations (i.e., system calls) for communication between the application and the L4Linux server.
One of the reasons why system calls on Linux are so expensive is because they use software interrupts to enter the kernel. If using sysenter/sysexit instructions (syscall/sysenter for AMD processors), the overhead for entering and exiting the kernel can be decreased by an order of magnitude (~160 vs. ~1500 cycles for the 1.4GHz Pentium4).
...with a probability of 100%. 0% of the times the bad pointer access goes thriough unnoticed. If only there was a way for the developers to increase the detection rate from 100% to 100%.
Now, higly regarded design philosophies claim that one should optimize the design for the common case while still allowing for all other conceivable usage scenarios. These other usage scenarios might not be supported optimally in the design, though. That is, instead of directly making use of all the internal features of the system, one might need to access them through some translation/abstraction/emulation layer. The fact that one go through all these layers are, however, completely transparent to the application/user. The overhead associated with the extra layering is probably also acceptable to the user. (You don't care if there is some millisecond overhead when running your remote email client or administration utility. You do care if you're experiencing such overhead when utilizing the 3D engine on your graphics hardware, though.)