I can't fault the professor for charging for his genuine time and expense needed to put these lectures online. However, I can and do fault the university for not providing the video equitment and hosting to make this process painless and requiring professors to put their lectures up in this fashion.
Many students learn in different ways. Some students, such as myself, are almost incapable of learning from sitting in class and taking notes. At the moment students like myself are totally screwed over in classes that don't offer a book or other written material to learn from. While I would prefer written matieral when this doesn't exist (and often the prof couldn't create it in a reasonable time) a video that one can watch at home and skip around to the parts you need to hear would at least give me some reasonable way to learn.
A university would never allow a professor to screw over the students who learn best from lecture by only providing written (or even video) material and only holding office hours or question sections. Fair treatment demands that the professor not screw over students who don't learn from lecture by not providing any at home learning method.
Unfortunatly there is a nasty prejudice that many people have that if you don't learn well from lecture your just lazy. It's not true but even if it was it wouldn't matter. Making sure that people don't 'get away' with learning on their own is no justification to deny saving time and effort by providing take home materials. The current practice of everyone going into lecture and blindly copying down what the professor says is just stupid.
Sure if we have good reason to believe the company was at fault in this situation then they are certainly morally culpable. However, it is quite reasonable, likely even, that someone stole/walked out with some of this rice and started making use of it.
Holding this company responsible when someone else may have just taken their product farmed it and sold it is completely ridiculous. It is kinda like holding a drug company responsible because someone diverted some of their product and it was used in a food tampering case.
The reaction of the europeans to GM food is just totally irrational. While there are some good reasons to be critical of growing GM food there is no justification to think eating minor quantities is dangerous. Sure the opponents are going to say it's untested and we shouldn't risk it but any time you breed a new type of agricultural product naturally the same reasoning should apply. Moreover, it seems like they treat a small amount of GM contamination of imported food more seriously than they would treat some minor chemical contamination.
The problem is that people don't like feeling they are 'using up' their help or that the company is making sure they don't ask too many questions.
For instance I'm a techie and go to great lengths to avoid calling tech support. However, I would be reluctant to buy a product if I knew I would have to pay just to talk to someone for tech support or if my use of tech support was limited to 3 calls or something. I mean it is possible that I will get a defective product or that their product just won't work right.
As I see it tech support is exactly like insurance. You pay for the peace of mind that if something were to go wrong you would have help. Like insurance it is therefore important that people who are a much higher risk pay a much higher price.
It would be bad if insurance companies treated everyone equally and capped the damages you could recieve because they couldn't charge young kids who owned fast racing cars more because of their dangerous behavior. It is unlikely but you want to know you are covered in case you get unlucky and get in two car accidents in a row. However, just because you want the coverage in case this unlikely event happens doesn't mean you should pay the same rate as someone who is statistically very likely to total their car repeatedly.
On the one hand it is clearly horrible for competent older individuals to be denied products.
On the other hand what do you do when you do know old people are far more likely to not understand or be able to use the product? It does seem like they are disproportionatly likely to use tecchnical serrvice or buy computer products wthout understanding their use. This is no real slight against old people but when you are young it is far easier to adjust to different situations and the very old are in a world that is incredibly different from the one they adjusted to at a young age. My grandpa was a phycicist and still a very smart man but he is way more likely to call tech support for computer help than most younger people I know.
Now you might think this is a situation like age discrimination in hiring. However, when hiring the employer has the opportunity to make an individualized deciscion. The employer can look at the resume and determine if this individual has the right skills regardless of whether they belong to a class which is statistically less likely to have those skills. When selling a product one doesn't necessarily have the resources to make an individualized deciscion. For instance we are comfortable letting insurance companies charge old people more for car insurance because they are more likely to get in accidents.
Don't get me wrong I think denying old people the chance to buy the software/service is wrong and this company acted irresponsibly. However, I don't know if I would feel the same way if they just charged old people extra money in return for their statistically increased usage of service calls and greater guidance in selecting a product. Is this more like increased insurance premiums or more like job descrimination?
Though I'm not a computer scientist I am a mathematician, another field inhabited by nerds with a large ratio of men to women. While there are definatly tensions created by this ratio I have never seen the men try to exclude girls or form a clique and not let them in. However, often shyness or lack of social skills will be interpreted by a more socially competent girl as a form of exclusion.
So if you are a girl I sugest just going up to them and being friendly. Likely what seems like exclusion is really just fear of talking to a girl or fear of looking like they are trying to pick you up. Often the prettier the girl the more she will intimidate the guys and the less likely they are to initiate conversation. Also remember that many nerds dispense with conversational niceities and tend to just launch directly into subjects they are comfortable with in conversation.
Going the other direction the big thing to avoid doing is glooming the girl, that is making yourself overly friendly and following her around in the hope that she will like you and start dating you. It won't work and it will make her uncomfortable around her. If you want to pick up a girl in this sort of situation be friendly but do so in reasonable doses and don't push yourself on her. Leave when the conversation naturally dies and if she seems to be recipricating your interest you can ask her out but don't follow her around just because she is nice to you.
In other words treat the girl as just another one of the guys. Don't worship her and don't ignore her.
Unfortunatly the biggest reason for gender tension I have seen is the catch-22 many tech girls find themselves in of wanting to be polite to nice but clueless nerds and fending off advances. Often this can make girls feel like they are under seige and make spending time with their male colleagues feel like walking through a mine field. Most nerd girls just want to be one of the guys (figuratively) and not have to worry about akward advances.
If links were the only way to find new web content then the number (and popularity of linking sites) would totally determine a websites popularity (modulo a bit of advertising).
Now if you believe that at least occasionally people find sites through search engines that weren't linked to from any of the sites they normally visit the search engine reduces the impact of popularity. All you need is one example of someone searching for "f22 raptor cost overruns" who doesn't browse milatary/political websites and the search engines have reduced the impact of popularity.
I always thought the criticism of google was that their choice in search algorithm did less to reduce the influence of popularity than it could. I don't find this a compelling criticism, wisdom of the masses and everything, but it is at least a cogent point.
The US, and I'm sure almost every other country, has exceptions in their copyright law for national security. The milatary can just take your code and use it anyway if they want. Now perhaps their might be some administrative hassle but this is more of a political statement than a real restriction on use. Of course the milatary doesn't just take software from big companies, it buys it so they have an incentive to keep writing it and because they have influence with congress/DoD.
Besides, everyone on slashdot complains about the ridiculous provisions companies put in their EULAs. This is just more of the same. Just as a EULA for a word processing product which demanded you not use the product to produce material that is critical of the company (or more extremely favors the political party the company founder dislikes) would be thrown out by the courts likely this restriction would be found invalid as well.
It's an interesting quesiton whether they have a severability clause so when this clause is found invalid the entire liscensce isn't deemed invalid (hmm...would that mean no one had a liscencse or for a open source piece of code that it was now just public domain).
Alright sure I'm willing to buy that representing information in sound can sometimes be more evocative or make for a better presentation but it hardly counts as an important scientific advancement.
I mean this is like having a press release for the pie chart talking about how it is going to revolutionize research in economics.
Now I'm a big fan of a policy of eventual public disclosure of exploits. The behavior of many big companies have shown that without the pressure of public knowledge of an exploit they will drag their heels about fixing the exploit. However, it is undoubtable that publicly making availible details of an exploit without giving vendors a chance to create a patch increases the number of attackers who are able to execute attacks against that vendor's customers.
Now there are reasonable people who believe this increased danger is pretty much always offset by the benefits of public knowledge of the risk, i.e., a vulnerability you know about is sufficently less risky to justify disclosure. However it is disgustingly biased and misleading to not even acknowledge that some people and companies might reasonably believe total public disclosure harms the end customers. This is especially true when we are talking about the difference between revealing the existance of the exploit and revealing info that might enable someone to copy the exploit.
Moreover, I didn't see the slightest evidence that it was outside pressure that caused this pair not to reveal the details. The tone of this cnet article seems to imply they made the choice themselves to be responsible which seems totally reasonable.
Also I don't understand who would put this pressure on them unless it is the network card manufacturer. Macs, linux and windows machines are supposedly all affected so no one company would take a PR hit relative to others. Unlike the case with the cisco vulnerability.
Yes it's true that vendors tend to be biased toward maintaining their good name. Just like real people they tend to be biased toward the answers that help them out but this is hardly dastardly. True I think they sometimes go to far and chill free speech and harm security research but this seems fairly rare and I see no reason to believe it is happening here.
Uhh I don't think your claim about malloc/free and GC speed makes sense.
By definition O(n) means that the time required grows linearly in the limit. Saying that GC grows like O(1) when it hasn't run out of availible memory and O(n) when it has is equivalent to saying that GC time grows like O(n).
I presume you are trying to say that while both GC and malloc grow like O(n) GC has better performance for 'low' amounts of memory. This may be true but I can't figure out any way to interpret your actual statement to make it true but perhaps I am missing something.
This is kinda a incoherent justification for GC. Supposedly the reason we need GC in the first place is so programmers without enough ability/experience/care don't screw up and forget to deallocate something. If using GC requires special knowledge training and optimization of GC then the argument for GC in the first place now doesn't go through.
Most programers at least know HOW to go about freeing memory and finding memory leaks even if they aren't good at it. If using GC required this special knowledge it would be even worse.
Still I agree that GC is the right way to go (so long as it can be turned off both globally and locally) because a good GC implementation will just work right for the vast vast majority of apps even if you have no clue what you are doing.
However, it's wrong to critisize someone for not being a GC expert as the very point of GC is to make programming work with less expertise/hassle. If the GC doesn't JUST WORK for the vast majority of apps it is the fault of the people who did the GC not the poor guy who has to select a different GC strategy or optimize his code around the GC.
Uhh it *might* be true that the software implementation is unpatentable but likely in this case the DRM would be at least patentable. RSA, for instance, was under patent.
Yes but it is easy to just define the common music exchange format to be MP3 or some custom format without any DRM technology. A law like this doesn't merely specify that the bits of the file must satisfy some formal feature but the actual content is encoded in the format specified. That means you couldn't just pack encrypted information in a standard mp3 file and say it was in mp3 format.
Or more sneakily they could mandage a certain format for DRM that has already been broken and refuse to outlaw the use of software to break that DRM for valid uses.
It's interesting the way so many people on slashdot are willing to disregard or even diss intel's Itanium strategy. Admittedly intel mistimed the itanium introduction, trying to move the processor world in a whole new direction just as AMD started producing some good chips was a mistake. Though to be fair to intel it isn't clear they could have foreseen this when they made the decisions. However, just because Itanium isn't going to run the next version of WoW or Quake doesn't mean that it is dead or a bad idea.
Itanium's big advantage is that it is simply a better ISA. Anyone who has done x86 assembly knows it is clunky and old while the IA64 architecture (except for the x86 emulation part) is well designed. Trying to improve x86 single threaded performance is ultimately a losing battle. Exacting a little bit more parallelism out of x86 instructions requires more and more transistors for smaller and smaller gains.
In the long run if you need more single thread performance IA64 or similar strategies are the way you have to go. Sure it is taking a long time to work out the bugs in the compiler technology but that just means intel has that much of a leg up when x86 single thread performance hits a brick wall. Also the work intel does on the itanium produces technology and insight that can be transfered to their other processor lines.
Remember intel needs to keep the big picture in mind and can't just look to the next 2 years. Rather than an indication of error I think the long time it is taking to iron out the IA64 technology is proof of foresight rather than an indication of a bungle.
The fact that C code is not as close to assembely code as it once was isn't the relevant issue. The question is whether C code is still closer to the assembely than high level languages are. This is undoubtedly true. If you don't believe this try adding constructs to ruby or lisp to let you do low level OS programming and see how difficult it would be.
I'm a big fan of high level languages and I believe eventually it will be the very distance from assembely that high level languages provide that will make them faster by allowing compilers/interpreters to do more optimization. However, it is just silly to pretend that C is not still far closer to the way a modern processor works than high level languages are.
If nothing else just look at how C uses pointers and arrays and compare this to the more flexible way references and arrays work in higher level languages.
It could be a lot worse. Apple could be one of those companies which for PR reasons decides to employ people in the US instead of in china. In this case all these chinese workers, who apparently prefer this job to their other options, wouldn't be employed at all (or more accurately would be employed in the same conditions but be making less money).
If the concern is the welfare of workers in China then every company which chooses not to make goods in China, often supposedly out of concern for the worker, ought to be held accountable. These companies are depressing the price of labour in china and making things worse for the Chinese workers.
It just doesn't make sense how companies who offer not so great employment to chinese workers are somehow treated as if they are doing something worse to the chinese than companies that don't offer them any employment at all. Yes, there have been problems with prison labor in china but all these workers are choosing to work in the city as opposed to staying home on the farm (many are doing so in violation of laws which say otherwise) so unless you think they are too stupid to know what is good for them we can assume they prefer the factory job to the farm job. Thus the idea that a company should refuse to provide them any job because they can't provide them an american quality job is just absurd.
Yes, if we were in a situation where individual customers could vote with their feet on net neutrality this anslysis would have a point. There would be less government regulation and the market could sort out whether people value net neutrality.
However, there is little to no effective competition in the internet access market. Sure there is a bit of competition between the cable and phone companies and electric companies always claim to be just about to deploy broadband over powerlines but these providers control the lines and can make life very difficult for any other DSL providers. Besides even if your broadband provider believes in net neutrality it isn't clear you don't still suffer from privleges granted by an upstream carrier. In short their is no easy way for competition to exercisce its judgement that net neutrality is worth paying for (and with enough money surely people could expand their pipes).
I mean just imagine if the local phone company announced it was going to charge you double if you called any buisness that didn't join its prefered buisness program (i.e. paid it money). This would be extortion and phone regulations rightly prohibit it because otherwise phone companies could use their monopoly position to exact almost arbitrarily high profits.
Sure it is possible that the automated system will cock up and we should still have pilots ready to take control in case the planes get *really* close, i.e., the autopilot should be given the chance to steer away when the planes first get too close and if they continue to approach each other the pilot should be able to quickly override. If the situation evolves so fast that the pilot just wouldn't have time to take over if the autopilot is acting incorrectly then I'm even more convinced the autopilot should be in control. Humans acting quickly make lots of mistakes and take long times to figure out coordination issues (I presume there is some international standard on which way to turn to avoid a collision but stil).
Of course this system should be tested as thourghly as possible but the truth is that people make TONS of mistakes. Sure there have been incidents of air accidents caused by bad software but there is no shortage of accidents caused by pilot error. For some weird reason people seem more comfortable trusting their safety to an individual that might screw up than a computer that might screw up. Personally I want to minimize my chance of dying so if a computer has a slightly smaller chance of killing me I will take that.
Hopefully one day the computers will run the entire plane flight and 9/11 type uses of airlines as weapons will just be impossible.
Yes, obviously a uKernel benefits from address space protection. I see no reason to believe this is what happened in the case presented.
Yes, uKernels are going to be somewhat less likely to crash. All I'm saying is that my hybrid type kernel is so stable now that I wouldn't be willing to give up 3-5% performance for this additional safety.
1) If I go out and look at the OS systems availible is it likely that the uKernels would have prevented this sort of thing but not the monolithic kernels.
Yes. Because the sort of people who design uKernels are usually very concerned about this sort of thing. This is ultimately a cultural difference because if you are writing a uKernel you have already shown a preference for things like theory and isolation over performance (e.g. saving memory by loading a driver once)
2) Whether in principle building a uKernel gives a development advantage.
2 is the question we are talking about. 1 is just silly OS advocacy. If you were going to write a new OS and you really wanted this feature you would just build it in uKernel or no uKernel and the fact that no other monolithic kernels do it would be irrelevant.
Your point is like arguing all the really respectful people you know speak chinese (just random hypothetical not true). Therefor if one wants to be respectful one had better speak chinese. It is absurd in that case and it is absurd in this case. Just because the culture might be inclined to certain sorts of behavior doesn't mean you have to buy into everything else that culture does to engage in that behavior yourself.
I disagree. If the filesystem server in a uKernel got corrupted it can write bad blocks just like a corrupted driver in a monolithic kernel.
Also everything that happened after the initial corruption was just bad programming. Something that could happen just as well in a uKernel as a monolithic. You can program a monolithic kernel so that reading stuff off the disk isn't going to write values to the bios and you can write a uKernel that reads registry files and passes these messages to other parts of the kernel that overright bios stuff.
Yes, you might say the sort of development practices that uKernels use are less likely to copy random stuff from the disk and let it modify the bios but this isn't an argument for a true uKernel. It is an argument for, as I advocated in my post, using uKernel type modular development but still letting everything run in one address space.
The only thing that a true uKernel gives you that a hybrid type design doesn't is address space protection. Nothing in your example suggested any of your problems happened because one part of the kernel corrupted the memory of other parts of the kernel. So your example just advocates my point. Namely the modular nature of uKernels should be borrowed for monolithic kernels (and this could even allow reloading FS drivers) but true address space protection just isn't worth it.
The fact that generally monolithic kernels don't write modularly and uKernels do doesn't say anything about which is in principle better.
I've seen bits on mega texture for awhile but I have yet to be able to divine how the hell it is suppose to work.
My best guess is that one starts with a tiled texture like you would in any other game but that some engine allows artists to add modifications to the texture in different areas. Thus you take up less memory than actually having a full texture of that size but each area has it's own unique touchups.
Is this really what it does? I'm getting really frustrated at these stupid little gaming articles that never really explain the tech.
If you were given the choice between rebooting your machine every 3 months or so for updates/driver install or never rebooting your machine and but taking a 3-5% performance hit (I think this is what the most efficient uKernels waste on address space switches) which would you choose.
I know my answer. For embedded systems/media center type stuff I don't care about the 3-5% performance hit. I don't ever want to screw with them.
For my computer I don't care about rebooting every 3 months or so. I want that extra little bit of speed.
There is undoubtedly much that traditional monolithic kernel design can learn from microkernel development practices (and probably already has learned much). Much of the modular nature of microkernel development and the *logical* separation of different components can help manage the complexity of building a kernel.
However, the real issue comes down to whether it makes sense to actually compile this down to a microkernel or leave it as a monolithic kernel. In other words should we enforce the separation between components of the OS by running them in different addresses spaces/user mode.
Tannenbaum is a smart guy and thankfully he doesn't try and argue the stupid point that most uKernel people try and argue about more modular development. You can have just as modular development even if you end up running all the servers in kernel address space. Ultimately this means that a monolithic kernel can take advantage of all the development practices that make uKernel development nice (or disregard them when they cause a performance hit) and run faster because it won't need to switch between address spaces as much. Nicely recent chip features (SYSENTER SYSEXIT) and a focus on this problem has reduced the performance hit considerably in recent years.
The only real benefit that a true microkernel provides (as opposed to things like OS X that are designed like a uKernel then run monolithically) is reincarnation of kernel processes. Tannenbaum is right that if one's goal is to build a computer that just works like a TV and never fully crashes the uKernel has some strong advantages. So for things like media centers, embedded systems or any other incarnation of computer as consumer device (as opposed to general purpose computer) I think the uKernel has strong advantages.
The question is whether these advantages are as important in a standard computer. Yes, they would be a benefit if implemented right (so the filesystem isn't, for instance, restarted in a way that would cause data corruption) but not that much of a benefit. I mean OS X (which isn't a true uKernel) pretty much never crashes for me and just needs to be restarted for updates once every couple of months. Sure a uKernel might never need to be restarted (though if we really cared we could make a monolithic kernel that needs to be restarted less frequently) but this just isn't worth even a small performance hit for me.
Ultimately I suspect we will see uKernels win in the embedded space. In the computer space I suspect we will see hybrid type designs like OS X which co-opt the design practices of uKernels but stick lots of things in the kernel address space just because not ever rebooting just isn't that important to most people.
Slashdot Mirror
I can't fault the professor for charging for his genuine time and expense needed to put these lectures online. However, I can and do fault the university for not providing the video equitment and hosting to make this process painless and requiring professors to put their lectures up in this fashion.
Many students learn in different ways. Some students, such as myself, are almost incapable of learning from sitting in class and taking notes. At the moment students like myself are totally screwed over in classes that don't offer a book or other written material to learn from. While I would prefer written matieral when this doesn't exist (and often the prof couldn't create it in a reasonable time) a video that one can watch at home and skip around to the parts you need to hear would at least give me some reasonable way to learn.
A university would never allow a professor to screw over the students who learn best from lecture by only providing written (or even video) material and only holding office hours or question sections. Fair treatment demands that the professor not screw over students who don't learn from lecture by not providing any at home learning method.
Unfortunatly there is a nasty prejudice that many people have that if you don't learn well from lecture your just lazy. It's not true but even if it was it wouldn't matter. Making sure that people don't 'get away' with learning on their own is no justification to deny saving time and effort by providing take home materials. The current practice of everyone going into lecture and blindly copying down what the professor says is just stupid.
Sure if we have good reason to believe the company was at fault in this situation then they are certainly morally culpable. However, it is quite reasonable, likely even, that someone stole/walked out with some of this rice and started making use of it.
Holding this company responsible when someone else may have just taken their product farmed it and sold it is completely ridiculous. It is kinda like holding a drug company responsible because someone diverted some of their product and it was used in a food tampering case.
The reaction of the europeans to GM food is just totally irrational. While there are some good reasons to be critical of growing GM food there is no justification to think eating minor quantities is dangerous. Sure the opponents are going to say it's untested and we shouldn't risk it but any time you breed a new type of agricultural product naturally the same reasoning should apply. Moreover, it seems like they treat a small amount of GM contamination of imported food more seriously than they would treat some minor chemical contamination.
If this sort of thing really could happen we would have already seen cosmic rays make a blac hole and swallow things up somewhere in our solar system.
Not really.
The problem is that people don't like feeling they are 'using up' their help or that the company is making sure they don't ask too many questions.
For instance I'm a techie and go to great lengths to avoid calling tech support. However, I would be reluctant to buy a product if I knew I would have to pay just to talk to someone for tech support or if my use of tech support was limited to 3 calls or something. I mean it is possible that I will get a defective product or that their product just won't work right.
As I see it tech support is exactly like insurance. You pay for the peace of mind that if something were to go wrong you would have help. Like insurance it is therefore important that people who are a much higher risk pay a much higher price.
It would be bad if insurance companies treated everyone equally and capped the damages you could recieve because they couldn't charge young kids who owned fast racing cars more because of their dangerous behavior. It is unlikely but you want to know you are covered in case you get unlucky and get in two car accidents in a row. However, just because you want the coverage in case this unlikely event happens doesn't mean you should pay the same rate as someone who is statistically very likely to total their car repeatedly.
On the one hand it is clearly horrible for competent older individuals to be denied products.
On the other hand what do you do when you do know old people are far more likely to not understand or be able to use the product? It does seem like they are disproportionatly likely to use tecchnical serrvice or buy computer products wthout understanding their use. This is no real slight against old people but when you are young it is far easier to adjust to different situations and the very old are in a world that is incredibly different from the one they adjusted to at a young age. My grandpa was a phycicist and still a very smart man but he is way more likely to call tech support for computer help than most younger people I know.
Now you might think this is a situation like age discrimination in hiring. However, when hiring the employer has the opportunity to make an individualized deciscion. The employer can look at the resume and determine if this individual has the right skills regardless of whether they belong to a class which is statistically less likely to have those skills. When selling a product one doesn't necessarily have the resources to make an individualized deciscion. For instance we are comfortable letting insurance companies charge old people more for car insurance because they are more likely to get in accidents.
Don't get me wrong I think denying old people the chance to buy the software/service is wrong and this company acted irresponsibly. However, I don't know if I would feel the same way if they just charged old people extra money in return for their statistically increased usage of service calls and greater guidance in selecting a product. Is this more like increased insurance premiums or more like job descrimination?
Though I'm not a computer scientist I am a mathematician, another field inhabited by nerds with a large ratio of men to women. While there are definatly tensions created by this ratio I have never seen the men try to exclude girls or form a clique and not let them in. However, often shyness or lack of social skills will be interpreted by a more socially competent girl as a form of exclusion.
So if you are a girl I sugest just going up to them and being friendly. Likely what seems like exclusion is really just fear of talking to a girl or fear of looking like they are trying to pick you up. Often the prettier the girl the more she will intimidate the guys and the less likely they are to initiate conversation. Also remember that many nerds dispense with conversational niceities and tend to just launch directly into subjects they are comfortable with in conversation.
Going the other direction the big thing to avoid doing is glooming the girl, that is making yourself overly friendly and following her around in the hope that she will like you and start dating you. It won't work and it will make her uncomfortable around her. If you want to pick up a girl in this sort of situation be friendly but do so in reasonable doses and don't push yourself on her. Leave when the conversation naturally dies and if she seems to be recipricating your interest you can ask her out but don't follow her around just because she is nice to you.
In other words treat the girl as just another one of the guys. Don't worship her and don't ignore her.
Unfortunatly the biggest reason for gender tension I have seen is the catch-22 many tech girls find themselves in of wanting to be polite to nice but clueless nerds and fending off advances. Often this can make girls feel like they are under seige and make spending time with their male colleagues feel like walking through a mine field. Most nerd girls just want to be one of the guys (figuratively) and not have to worry about akward advances.
This is pretty obvious.
If links were the only way to find new web content then the number (and popularity of linking sites) would totally determine a websites popularity (modulo a bit of advertising).
Now if you believe that at least occasionally people find sites through search engines that weren't linked to from any of the sites they normally visit the search engine reduces the impact of popularity. All you need is one example of someone searching for "f22 raptor cost overruns" who doesn't browse milatary/political websites and the search engines have reduced the impact of popularity.
I always thought the criticism of google was that their choice in search algorithm did less to reduce the influence of popularity than it could. I don't find this a compelling criticism, wisdom of the masses and everything, but it is at least a cogent point.
The US, and I'm sure almost every other country, has exceptions in their copyright law for national security. The milatary can just take your code and use it anyway if they want. Now perhaps their might be some administrative hassle but this is more of a political statement than a real restriction on use. Of course the milatary doesn't just take software from big companies, it buys it so they have an incentive to keep writing it and because they have influence with congress/DoD.
Besides, everyone on slashdot complains about the ridiculous provisions companies put in their EULAs. This is just more of the same. Just as a EULA for a word processing product which demanded you not use the product to produce material that is critical of the company (or more extremely favors the political party the company founder dislikes) would be thrown out by the courts likely this restriction would be found invalid as well.
It's an interesting quesiton whether they have a severability clause so when this clause is found invalid the entire liscensce isn't deemed invalid (hmm...would that mean no one had a liscencse or for a open source piece of code that it was now just public domain).
Alright sure I'm willing to buy that representing information in sound can sometimes be more evocative or make for a better presentation but it hardly counts as an important scientific advancement.
I mean this is like having a press release for the pie chart talking about how it is going to revolutionize research in economics.
Now I'm a big fan of a policy of eventual public disclosure of exploits. The behavior of many big companies have shown that without the pressure of public knowledge of an exploit they will drag their heels about fixing the exploit. However, it is undoubtable that publicly making availible details of an exploit without giving vendors a chance to create a patch increases the number of attackers who are able to execute attacks against that vendor's customers.
Now there are reasonable people who believe this increased danger is pretty much always offset by the benefits of public knowledge of the risk, i.e., a vulnerability you know about is sufficently less risky to justify disclosure. However it is disgustingly biased and misleading to not even acknowledge that some people and companies might reasonably believe total public disclosure harms the end customers. This is especially true when we are talking about the difference between revealing the existance of the exploit and revealing info that might enable someone to copy the exploit.
Moreover, I didn't see the slightest evidence that it was outside pressure that caused this pair not to reveal the details. The tone of this cnet article seems to imply they made the choice themselves to be responsible which seems totally reasonable.
Also I don't understand who would put this pressure on them unless it is the network card manufacturer. Macs, linux and windows machines are supposedly all affected so no one company would take a PR hit relative to others. Unlike the case with the cisco vulnerability.
Yes it's true that vendors tend to be biased toward maintaining their good name. Just like real people they tend to be biased toward the answers that help them out but this is hardly dastardly. True I think they sometimes go to far and chill free speech and harm security research but this seems fairly rare and I see no reason to believe it is happening here.
Uhh I don't think your claim about malloc/free and GC speed makes sense.
By definition O(n) means that the time required grows linearly in the limit. Saying that GC grows like O(1) when it hasn't run out of availible memory and O(n) when it has is equivalent to saying that GC time grows like O(n).
I presume you are trying to say that while both GC and malloc grow like O(n) GC has better performance for 'low' amounts of memory. This may be true but I can't figure out any way to interpret your actual statement to make it true but perhaps I am missing something.
This is kinda a incoherent justification for GC. Supposedly the reason we need GC in the first place is so programmers without enough ability/experience/care don't screw up and forget to deallocate something. If using GC requires special knowledge training and optimization of GC then the argument for GC in the first place now doesn't go through.
Most programers at least know HOW to go about freeing memory and finding memory leaks even if they aren't good at it. If using GC required this special knowledge it would be even worse.
Still I agree that GC is the right way to go (so long as it can be turned off both globally and locally) because a good GC implementation will just work right for the vast vast majority of apps even if you have no clue what you are doing.
However, it's wrong to critisize someone for not being a GC expert as the very point of GC is to make programming work with less expertise/hassle. If the GC doesn't JUST WORK for the vast majority of apps it is the fault of the people who did the GC not the poor guy who has to select a different GC strategy or optimize his code around the GC.
Uhh it *might* be true that the software implementation is unpatentable but likely in this case the DRM would be at least patentable. RSA, for instance, was under patent.
Either way one gets the same result.
Yes but it is easy to just define the common music exchange format to be MP3 or some custom format without any DRM technology. A law like this doesn't merely specify that the bits of the file must satisfy some formal feature but the actual content is encoded in the format specified. That means you couldn't just pack encrypted information in a standard mp3 file and say it was in mp3 format.
Or more sneakily they could mandage a certain format for DRM that has already been broken and refuse to outlaw the use of software to break that DRM for valid uses.
It's interesting the way so many people on slashdot are willing to disregard or even diss intel's Itanium strategy. Admittedly intel mistimed the itanium introduction, trying to move the processor world in a whole new direction just as AMD started producing some good chips was a mistake. Though to be fair to intel it isn't clear they could have foreseen this when they made the decisions. However, just because Itanium isn't going to run the next version of WoW or Quake doesn't mean that it is dead or a bad idea.
Itanium's big advantage is that it is simply a better ISA. Anyone who has done x86 assembly knows it is clunky and old while the IA64 architecture (except for the x86 emulation part) is well designed. Trying to improve x86 single threaded performance is ultimately a losing battle. Exacting a little bit more parallelism out of x86 instructions requires more and more transistors for smaller and smaller gains.
In the long run if you need more single thread performance IA64 or similar strategies are the way you have to go. Sure it is taking a long time to work out the bugs in the compiler technology but that just means intel has that much of a leg up when x86 single thread performance hits a brick wall. Also the work intel does on the itanium produces technology and insight that can be transfered to their other processor lines.
Remember intel needs to keep the big picture in mind and can't just look to the next 2 years. Rather than an indication of error I think the long time it is taking to iron out the IA64 technology is proof of foresight rather than an indication of a bungle.
The fact that C code is not as close to assembely code as it once was isn't the relevant issue. The question is whether C code is still closer to the assembely than high level languages are. This is undoubtedly true. If you don't believe this try adding constructs to ruby or lisp to let you do low level OS programming and see how difficult it would be.
I'm a big fan of high level languages and I believe eventually it will be the very distance from assembely that high level languages provide that will make them faster by allowing compilers/interpreters to do more optimization. However, it is just silly to pretend that C is not still far closer to the way a modern processor works than high level languages are.
If nothing else just look at how C uses pointers and arrays and compare this to the more flexible way references and arrays work in higher level languages.
It could be a lot worse. Apple could be one of those companies which for PR reasons decides to employ people in the US instead of in china. In this case all these chinese workers, who apparently prefer this job to their other options, wouldn't be employed at all (or more accurately would be employed in the same conditions but be making less money).
If the concern is the welfare of workers in China then every company which chooses not to make goods in China, often supposedly out of concern for the worker, ought to be held accountable. These companies are depressing the price of labour in china and making things worse for the Chinese workers.
It just doesn't make sense how companies who offer not so great employment to chinese workers are somehow treated as if they are doing something worse to the chinese than companies that don't offer them any employment at all. Yes, there have been problems with prison labor in china but all these workers are choosing to work in the city as opposed to staying home on the farm (many are doing so in violation of laws which say otherwise) so unless you think they are too stupid to know what is good for them we can assume they prefer the factory job to the farm job. Thus the idea that a company should refuse to provide them any job because they can't provide them an american quality job is just absurd.
Yes, if we were in a situation where individual customers could vote with their feet on net neutrality this anslysis would have a point. There would be less government regulation and the market could sort out whether people value net neutrality.
However, there is little to no effective competition in the internet access market. Sure there is a bit of competition between the cable and phone companies and electric companies always claim to be just about to deploy broadband over powerlines but these providers control the lines and can make life very difficult for any other DSL providers. Besides even if your broadband provider believes in net neutrality it isn't clear you don't still suffer from privleges granted by an upstream carrier. In short their is no easy way for competition to exercisce its judgement that net neutrality is worth paying for (and with enough money surely people could expand their pipes).
I mean just imagine if the local phone company announced it was going to charge you double if you called any buisness that didn't join its prefered buisness program (i.e. paid it money). This would be extortion and phone regulations rightly prohibit it because otherwise phone companies could use their monopoly position to exact almost arbitrarily high profits.
Sure it is possible that the automated system will cock up and we should still have pilots ready to take control in case the planes get *really* close, i.e., the autopilot should be given the chance to steer away when the planes first get too close and if they continue to approach each other the pilot should be able to quickly override. If the situation evolves so fast that the pilot just wouldn't have time to take over if the autopilot is acting incorrectly then I'm even more convinced the autopilot should be in control. Humans acting quickly make lots of mistakes and take long times to figure out coordination issues (I presume there is some international standard on which way to turn to avoid a collision but stil).
Of course this system should be tested as thourghly as possible but the truth is that people make TONS of mistakes. Sure there have been incidents of air accidents caused by bad software but there is no shortage of accidents caused by pilot error. For some weird reason people seem more comfortable trusting their safety to an individual that might screw up than a computer that might screw up. Personally I want to minimize my chance of dying so if a computer has a slightly smaller chance of killing me I will take that.
Hopefully one day the computers will run the entire plane flight and 9/11 type uses of airlines as weapons will just be impossible.
Yes, obviously a uKernel benefits from address space protection. I see no reason to believe this is what happened in the case presented.
Yes, uKernels are going to be somewhat less likely to crash. All I'm saying is that my hybrid type kernel is so stable now that I wouldn't be willing to give up 3-5% performance for this additional safety.
You are confusing two different questions.
1) If I go out and look at the OS systems availible is it likely that the uKernels would have prevented this sort of thing but not the monolithic kernels.
Yes. Because the sort of people who design uKernels are usually very concerned about this sort of thing. This is ultimately a cultural difference because if you are writing a uKernel you have already shown a preference for things like theory and isolation over performance (e.g. saving memory by loading a driver once)
2) Whether in principle building a uKernel gives a development advantage.
2 is the question we are talking about. 1 is just silly OS advocacy. If you were going to write a new OS and you really wanted this feature you would just build it in uKernel or no uKernel and the fact that no other monolithic kernels do it would be irrelevant.
Your point is like arguing all the really respectful people you know speak chinese (just random hypothetical not true). Therefor if one wants to be respectful one had better speak chinese. It is absurd in that case and it is absurd in this case. Just because the culture might be inclined to certain sorts of behavior doesn't mean you have to buy into everything else that culture does to engage in that behavior yourself.
I disagree. If the filesystem server in a uKernel got corrupted it can write bad blocks just like a corrupted driver in a monolithic kernel.
Also everything that happened after the initial corruption was just bad programming. Something that could happen just as well in a uKernel as a monolithic. You can program a monolithic kernel so that reading stuff off the disk isn't going to write values to the bios and you can write a uKernel that reads registry files and passes these messages to other parts of the kernel that overright bios stuff.
Yes, you might say the sort of development practices that uKernels use are less likely to copy random stuff from the disk and let it modify the bios but this isn't an argument for a true uKernel. It is an argument for, as I advocated in my post, using uKernel type modular development but still letting everything run in one address space.
The only thing that a true uKernel gives you that a hybrid type design doesn't is address space protection. Nothing in your example suggested any of your problems happened because one part of the kernel corrupted the memory of other parts of the kernel. So your example just advocates my point. Namely the modular nature of uKernels should be borrowed for monolithic kernels (and this could even allow reloading FS drivers) but true address space protection just isn't worth it.
The fact that generally monolithic kernels don't write modularly and uKernels do doesn't say anything about which is in principle better.
I've seen bits on mega texture for awhile but I have yet to be able to divine how the hell it is suppose to work.
My best guess is that one starts with a tiled texture like you would in any other game but that some engine allows artists to add modifications to the texture in different areas. Thus you take up less memory than actually having a full texture of that size but each area has it's own unique touchups.
Is this really what it does? I'm getting really frustrated at these stupid little gaming articles that never really explain the tech.
A simple way to put the question is this:
If you were given the choice between rebooting your machine every 3 months or so for updates/driver install or never rebooting your machine and but taking a 3-5% performance hit (I think this is what the most efficient uKernels waste on address space switches) which would you choose.
I know my answer. For embedded systems/media center type stuff I don't care about the 3-5% performance hit. I don't ever want to screw with them.
For my computer I don't care about rebooting every 3 months or so. I want that extra little bit of speed.
There is undoubtedly much that traditional monolithic kernel design can learn from microkernel development practices (and probably already has learned much). Much of the modular nature of microkernel development and the *logical* separation of different components can help manage the complexity of building a kernel.
However, the real issue comes down to whether it makes sense to actually compile this down to a microkernel or leave it as a monolithic kernel. In other words should we enforce the separation between components of the OS by running them in different addresses spaces/user mode.
Tannenbaum is a smart guy and thankfully he doesn't try and argue the stupid point that most uKernel people try and argue about more modular development. You can have just as modular development even if you end up running all the servers in kernel address space. Ultimately this means that a monolithic kernel can take advantage of all the development practices that make uKernel development nice (or disregard them when they cause a performance hit) and run faster because it won't need to switch between address spaces as much. Nicely recent chip features (SYSENTER SYSEXIT) and a focus on this problem has reduced the performance hit considerably in recent years.
The only real benefit that a true microkernel provides (as opposed to things like OS X that are designed like a uKernel then run monolithically) is reincarnation of kernel processes. Tannenbaum is right that if one's goal is to build a computer that just works like a TV and never fully crashes the uKernel has some strong advantages. So for things like media centers, embedded systems or any other incarnation of computer as consumer device (as opposed to general purpose computer) I think the uKernel has strong advantages.
The question is whether these advantages are as important in a standard computer. Yes, they would be a benefit if implemented right (so the filesystem isn't, for instance, restarted in a way that would cause data corruption) but not that much of a benefit. I mean OS X (which isn't a true uKernel) pretty much never crashes for me and just needs to be restarted for updates once every couple of months. Sure a uKernel might never need to be restarted (though if we really cared we could make a monolithic kernel that needs to be restarted less frequently) but this just isn't worth even a small performance hit for me.
Ultimately I suspect we will see uKernels win in the embedded space. In the computer space I suspect we will see hybrid type designs like OS X which co-opt the design practices of uKernels but stick lots of things in the kernel address space just because not ever rebooting just isn't that important to most people.