I agree Vista does include numerous small improvements and features; but I'd also argue it includes anti-features as well, designed to benefit MS or their partners at the expense of the end user (more draconian DRM for example). The DRM thats present is opt-in, and is a net bennie to the end-user. If they dont purchase media with DRM, they never get affected by any DRM in windows. So thats the same as any other OS. But if they do choose to buy DRM media, then they CAN play it, because of the things put into the OS.
I know the argument is that they should have just 'stood up' against the media interests, but thats garbage. That would have also hurt the end-user as they couldnt play their blu-ray media, and it probably wouldnt have worked anyway.
The forum to eliminate the DRM problem is in the government, not in the OS technology.
I'd also argue that it is MS's monopoly on desktop OS's that is the reason why there is so little advancement in the field. Traditionally, one of the main problems with monopolies is that they retard innovation in that market because the monopolist has little incentive to put time and money into improvements because customers are going to buy whatever they make anyway. Wow and you base this on what? I see 2 other competitors in the desktop OS world. Mac, a consumer-focused boutique brand that is hideously successful (money-wise) and has growing marketshare. Linux that is completely free and available to anyone, and though a pain in the ass for many to get working, CAN be made to get working for most situations.
So there definitely isnt any natural monopoly, or government supported monopoloy being abused. Mac is fairly innovative, and some of the (technological) features in the Linux world are quite innovative.
Your idea that innovation is stifled by Microsoft's supposed unbreachable monopoly just isnt borne out by facts. Hell, the barrier to entry into the OS world is so low that VOLUNTEERS have created a saleable product in that market.
Face it, there is plenty of room for improvement of OS's. Hell, Vista still doesn't even have a spell checker that works in all my applications and uses the same dictionary, let alone other universal services. It's been what, ten years since the first OS with that feature was shipped (then killed). Thats your measure for innovation? A spell checker? Thats just absurd to me. Not to mention that IF Microsoft were to do that, then half of the anti-windows crowd would scream foul that they were including things in the OS and leveraging a monopoly to lock out innovation.
Not to mention that a universal spell checking service, while nice in theory is so very very far down the priority list for most people that it doesnt exists. I mean I actually laughed when I read that. Dont get me wrong, it would be useful, but so would butt air-conditioning in my office chair. Neither is going to happen. Not to mention that if someone wanted to make that product, they certainly could. I doubt if anyone would buy it though.
Top of the line, hideously overpowered, engineering laptop from their corporate line.
Vista x86 works great. Vista x64 works spectacularly. WinXP works perfectly.
But getting Ubuntu running on it was hideous, and several key hardware elements never could be made to work (ie, wifi). This despite the fact that the wifi card is the Intel abgn card that has a freaking open source driver for it. And you wouldnt believe the hoops I had to jump through just to get the installer not to fail (use alternate installer disk, modify the grub loader config to use a software framebuffer until I could get the nvidia drivers downloaded and installed).
In fact, based on my testing of the time, Ubuntu actually works BETTER on cut rate consumer garbage systems. That seems to be what it was designed for, and all the certified systems (of the time) were all consumer crap.
As a comparison, I had MUCH better luck with SuSE SLED, but still never could get the wifi working.
Compare that to the box now running Vista Business x64. I can sit on my couch and have it connected to my samsung DLP through HDMI and running 1920x1280. I can do that for work stuff, or random DivX videos, music, etc. Never have run into a single DRM issues, but then again, I dont buy anything with DRM, so its a non-start issue for me.
It was always a metadata layer built on top of NTFS.
I'm not going to do the research on this to provide links, but I'm 99.9% sure of this.
The bennies were an ubiquitous API and unified approach to this stuff, that any 3rd party software could use, and even end users directly could manipulate it.
The problem is it may not be relevant anymore. With horsepower and disk space so high nowadays compared to then, the simple brute force of the currently used desktop search systembs by MS and google work well and dont require a revolutionary product.
#1 will happen as a matter of course, since its the same driver model as Vista and Server 2008 use. So every month that goes by, the driver 'ecosystem' gets better.
#2 is just being silly. Thats just flat not a market requirement. Only the tiny percentage of techies want this, the 95% of the users out there dont care and have no expectation of this. They only want it to perform reasonably on the hardware it comes with.
People that say they're expecting this just dont get the market forces at work. There is NO DEMAND for an OS that performs better than the old one. It's not even going to be on the feature list at MS. No one cares (except for a subset of the people here on/.).
Hell, just a cursory examination of some of the improvements they made to the internals of Vista would rule that out. They moved a LOT of drivers out into userspace. It's inevitable that this will have a performance impact, but with the bennie of improved stability once the IHVs learn how to write drivers properly for the product.
MinWin exists now, you get it when you purchase Server 2008. It's called server core.
They dont seem to be interested in making that a part of the client OS distribution as they dont see a market for a desktop OS with only a command line interface.
Vista WAS the radical change, or didnt you notice all the driver incompatibilities?
The kernel and core of Vista was an excellent, technically impressive 10-year needed change to the windows platform, particularly if you're looking at the changes in the x64 versions.
Much of what you're seeing as problems with Vista are ecosystem issues, combined with the typical set of MS v1 bugs.
What you'll find nowadays is that if you have a clean build of Vista SP1, with quality drivers, and no crapware from the manufacturer, then Vista is an excellent platform. Fast, MUCH more stable and long running than XP, particularly on laptops.
Still has its growing pains, but not bad.
You can really see this in the pretty much universal accolades that Server 2008 is getting. And after all, Vista SP1 and Server 2008 are largely the same product, just some differences in tuning and what stuff is included in the OS by default.
Microsoft DID badly screw up the Vista deployment, but it wasnt in the technology. It was in the marketing, OEM relationships, and ecosystem development. I know most of the/. crowd doesnt get it, but thats because the typical slashdotter has a very shallow viewpoint, and not much experience in actually developing large complex software products.
It's the same major generation of kernel, but of course they're also making evolutionary improvements to it while keeping binary compatibility, minimal api changes, driver scenarios the same, etc.
It's better to say that Vista SP1 is very close to the same kernel as Server 2008, and Windows 7 will be further evolution along the same major kernel generation.
You dont just run the tool over and over again and never adapt it to your code.
If it produces a bunch of false positives, then you go in and modify the rules to not generate those false positives.
Thats half the point of something like this, you need to tune it to your project.
The flip side is that if you see some devs over and over making the same kind of mistake, well you can write a new rule in it to flag that kind of thing.
If you have an endless number of false positives, that doesnt ever go down, then you are either:
1. Not using the tool correctly. or 2. Not working on a project that is amenable to this tool.
IME, the vast majority of time its #1. Now you may find that for certain small or narrowly scoped projects, or those worked on by 2 super-gurus, that the overhead for learning and tuning the tool for that project isnt worth it. But thats something you'd have to find out yourself, and it differs from project to project.
Wow, nice story. Quite amazing, as you'd think the devs could just do things the right way for not much more work than gaming the tools.
This kind of thing though, is ultimately a failure of management, whoever leads/runs the dev team. They should be able to see this kind of thing happening and either apply some proper motivation, change the procedures, or let some bad devs go.
Mind you, bad developers as well. But if I were the owner, the dev mgr would get the brunt first on something like this.
Due to the bandwidth (minimum 800k per node) and processing requirements (heavy), this sort of thing doesnt really work with typical asymmetric bandwidth available to most sites.
The way you do this is with a bridge/reflector. Everyone dials into that, and it does the multiplexing, and re-broadcasts.
This gives you a star topology rather than a mesh, which is much more practical.
With decentralized, figure 7 nodes at 800k each, means that each node would need at least 6mbps upstream bandwidth available to them. Very few businesses have this, smaller than large orgs or universities.
MSN Messenger, iChat, etc dont qualify here either, as they're decentralized, so have this same problem.
Have you considered just saving yourself all this pain and acquiring a commercial bridge from codian or polycom?
I cant speak to your specific time/cost tradeoffs, but at some point, given the relative crappiness and/or non-availability of FOSS solutions, it may be cheaper to just buy something that works and move on to your real job.
You are saying that either quality doesn't matter for the user, or he wants to be tricked. I am not saying that.
I am saying that the features/functions the user considers important, or where greater levels of 'quality' are important to them, have little bearing to this article's definition of code quality.
The biggest thing TFA measures is readability, maintainability, etc. This has an indirect effect on the business' ability to change, update, etc.
But these are very indirect sorts of relationships, often through several layers of indirection, and with a delay time between code creation and benefit the user sees in several years or more, if ever.
If the code quality improves quality of the product, it's a good thing. Yep, and thats the whole rub of it.
There is little evidence that code quality improves the quality of the product, from the end user point of view.
You can produce the same features, at the same level of quality, with no connection to code quality (though poorer code quality will likely make the product development more expensive over time).
Code Quality and Product/Feature Quality can be orthogonal. You can have great features, that do exactly what the user wants, and how he/she wants it, but the underlying code is terrible. And vice-versa, you can have the perfect code, beautiful to the eye, and easier to maintain, but doesnt provide the features the customer/market wants.
Businesses fail all the time because of the latter (great technology, poorly thought out product/business-plan), but rarely because of the former.
In the former case, it makes new versions and product enhancements more expensive, so it eats into your margins, and slows you down.
For the users of operating systems, the code quality is irrelevant.
Things like features, marketing, packaging, etc are what drives markets, not an academic analysis on source code quality.
This kind of information is only useful or interesting to those of us in the field.
As an analogy to automobiles, consider metrics on the complexity of supply chain dependencies in car manufacturing.
Only interesting to people in the business, not interesting at all to the people who actually buy and drive cars. They only care how cool it looks, mileage, and what colors you can get it in.
This article only speaks to things interesting to those of us who build these things for a living. It says nothing about the market/commercial success.
As a final trivial analogy, the most beautiful code in the world, used to create the perfect OS, doesnt mean squat if it doesnt provide features that its target audience wants.
I think you're misunderstanding what WRK is. It's not a research kernel, its a snapshot of the 2003-x64/XP-x64 kernel, minus a bunch of hardware layer stuff (HAL, etc) and minus everything from userspace.
The information to inform you is here, which was also linked on the summary to TFA.
I think you're vastly overestimating the overall knowledge, experience, and education in this context of the/. readership.
Only a small portion of the/. readers are programmers/developers (or in an academic speciality in this field).
Even amongst that population, only a small percentage are qualified in large operating systems development.
Similarly, a small percentage of the programmer subpopulation of/. will be familiar with the various theory, metrics and approaches to measuring and analyzing code quality.
The target population of the paper are people who fit into all three of these groups. Thats not very many people.
I've been doing software development for a living for almost 2 decades, but arent familiar with many of the metrics and approaches used to analyze the source code (of course some, like cyclomatic complexity, line lengths, operands per line, etc etc I am familiar with).
This is incredibly narrowly focused stuff, even for/.
How do you change "GPL" to "LGPL"? You add an "L". And the result is a LESS restrictive license. Heh. RMS might disagree with you there, I think he would probably call it less free, not less restrictive.
Are you seriously claiming that this is not purposly done by Microsoft to confuse things? I'm sorry, I don't believe you. So your entire argument is based on the fact that MS uses an 'L' modifier on some of their licenses, which sorta kinda maybe looks a little bit similar to the GPL/LGPL variants?
Thats quite a stretch. Given your viewpoint, I'm surprised you werent here ranting when MPL was released, that it looks too much like GPL. Or CDDL. Or CPL. Or EPL. Or ECL. Or APL. Or OSL. Or QPL. Or LPL. All of these are OSI categorized licenses that look alot like the GPL, and by your definitions, must be trying to confuse the market with their marks.
Oh wait, maybe its just an industry norm to abbreviate licenses this way. Sure is a lot of prior art in the area.
As to what some employees at MS may or may not intend with these license names are impossible to know, but ultimately irrelevant.
No reasonable human being would confuse MS-PL, MS-LPL, or MS-RL with GPL or LGPL. It just isnt going to happen.
No reasonable human being would confuse one of the restricted licenses like MS-RSL with an open source (as used by OSI) license/software.
And you still didn't address the fact that you are ignoring the MS-LPL, MS-LRL, and MS-RSL, as well as several other licenses that they call "shared source". I'm not sure in what way I'm 'ignoring' them, given that we're sitting here talking about them. It's trivial to go look at the license text on microsoft.com and see what they are.
The 'Limited' versions of MS-PL and MS-RL restrict the use to just windows. It's not that complicated.
The MS-RSL is a 'view-only' license, and they're quite clear about that here.
The Microsoft Reference Source License (Ms-RSL) is the most restrictive of the Microsoft source code licenses. The license prohibits all use of source code other than the viewing of the code for reference purposes. The intent of this license is to enable licensors to release, for review purposes only, more sensitive intellectual property assets. So given how easy it is to understand what those licenses you mention are, I'm not sure what your complaint is.
Are you complaining that there are restrictive licenses used by Microsoft at all? Or that they all use acronyms and therefore may be confusing (to who?). Or are you suggesting that MS-RSL, MS-LPL, or MS-LRL are too similar to LGPL and GPL to be understandable by a reasonable person?
If the latter, who are these people you're dealing with that cant differentiate between words with different letters?
I personally agree with the sentiment expressed by the grandparent, the term 'open source' (Open Source?) is basically reserved for describing software licensed under a license that complies with the Open Source Definition by the OSI. But you cant 'reserve' it. Language doesnt work that way, its not something you can declare by fiat.
Language is defined by what is understandable. In items like this, 'common understanding' is usually the threshold used.
But the problem is, even within the software development industry, there's no common agreement or understanding among the practitioners that 'Open Source' means what you (or OSI) says it means.
Concerning your statement that "the term 'open source' has been around for much, much longer than the OSI has even existed" the following discussion and statement by Bruce Perens right here on Slashdot might be of interest: Yeah, I saw Bruce's posts, and he responded to two of my posts with the same idea. And with all due respect to him, he also doesnt get to decide how the language is used, nor does he get to re-write history.
Prior to OSI, (and still so for a large number of developers in the industry) open source was generally understood to mean source viewable or available. It did not make any judgement or statement about what licenses or restrictions applied to your use of this source, it just was concerned with whether the source was available at all.
As I responded to Bruce Perens, although it wasnt used in the 'quoted and capitalized' form, the non-quoted and non-capitalized form would have been generally understandable for the last 20 years. But that general understanding wouldnt have been so specific to include all the distinctions of Bruce's or OSI's definitions.
In fact, one could even argue that folks like Bruce Perens and OSI are engaged in the same sort of guerrila campaign to modify the language that the slashdotters are accusing Microsoft of.
I say this because at this point in time, 'Open Source' as OSI defines it is not the same thing as 'open source'. They're trying to make it a proper noun that has special meaning, but is visually indistinguishable from the non-proper noun term.
I dont have any problem with this, any human is welcome to throw their hat in the ring and try to change society. Doing so by changing the language is an effective approach to this.
But I dont like people re-writing history or trying to say that their definition of something is the official definition when its not even in common usage, even within the specific industry jargon.
I'm not sure what you mean by:
licenses that everybody is arguing about The discussion is about whether MS is trying to (or doing so) create market confusion by making their various source-viewable licenses sound similar to open source licenses.
Whether you pick MS-LPL or MS-PL or MS-RSL is irrelevant.
No reasonable human being would confuse these with GPL or LGPL. I mean heck, they all have a giant MS- stuck in front of them.
And if anyone is so unfamiliar with English language that they cannot distinguish 'shared source' from 'open source' then they are not a reasonable person to be in a decision making role for software acquisition.
Even when reading the license text directly, the MS licenses are simple and clear. They're fairly similar to many other licenses out there, but with the patent poison-pill business, which is very reasonable for a commercial company to use at this point in legal history in the US.
Okay, I realize I'm late coming back to this, and no one but you (Bruce) will probably read this, but...
I agree that the quoted, capitalized term 'Open Source' as such was not in common use, but a much looser phrasing has been common for 20+ years, as in 'open source' (ie, no caps, no hoopla surrounding it) or 'source available'.
It's only when (at least in my perspective) FSF and that group brought religion/politics into it that it became a capitalized phrase with 'extra meaning'. But thats always been controversial.
Even today, the vast majority of developers (both corporate and ISV) (at least that I've encountered) do not share a consensus about what that means.
Many have a vague notion that it means free (as in public domain or bsd-style licenses), many understand that it means source viewable, but very very few have any understanding of the subtleties and commercial implications of 'copyleft' style licenses such as GPL and similar.
In other words, there's no common understanding now that it means what OSI defines it to mean. Only among a highly specialized niche of the software development industry is the OSI definition widely agreed with (versus the more loosely defined concept).
I would disagree with you though that it wasnt in common usage. That exact, quoted and capitalized phrase was not used as-such, but the term used without the quotes and capitalization would have been generally understood to mean at least source-viewable for the last 20 years.
Even now its not as clear as OSI would like it to be. OSI certifies both BSD/Apache style licenses (ie, commercial friendly) and GPL (community friendly) as 'open source', but software licensed under these two types are hugely different in how you can use them. They may have similar development methodologies, but for licensing//use concerns, they are completely unrelated and distinctive. About the only similarity between the two is that they're not proprietary.
Based on this, which does 'Open Source' mean? If it means both, then its a fairly diluted 'official' definition, which pretty much defeats the purpose of having an 'official' definition.
The shared source license is somewhat different in that the specific use case it is designed to solve is a marketing one, rather than a functional one. It is simply a way to provide a license that benefits the one and only developer at the expense of the user, by providing a very small subset of the benefits of other OSS licenses, while intentionally castrating the most important (but less understood) benefits. That is grossly inaccurate.
The MS-RSL (reference source license) that they're using for.NET code now is infinitely better than it was before. I'm sure it helps MS in marketing and sales aspects, but the primary beneficiaries are developers. You can now see how they built the.net stuff, debug into.net source code to identify problems, etc.
This is a huge thing, and a big win for.NET developers. To suggest that this only helps MS is absurd.
And take all the MS-PL code on CodePlex.com. This doesnt help MS directly (though indirectly it does by enhancing the ecosystem), but its a huge win for any windows developer because there is SO MUCH code there that can be used. It's not as useful as Apache is for Java devs, but its heading strongly in that direction.
Here's another case where the MS-PL is hugely (and directly) beneficial to the customers, and only beneficial to MS through indirections. Thats the great thing about these, they are win/win for both parties.
And look at the MS-PL and MS-RL. The biggest difference between these and other typical FOSS licenses are the patent mutually-assured-destruction business. Basically its saying that if you sue the developer over patents, then you lose the right to use their software and any related patents. Thats eminently reasonable for a commercial entity.
Shared Source only benefits the author -- i.e., it exists to keep people locked in to the Windows OS and the Office office suite. Depends on which licenses you consider 'shared source' from MS.
The MS-PL and MS-RL do not lock you into a platform. The 'L' versions of these do, by locking the licensed software onto windows.
Thats my whole point. There is NOT any official definition of the term 'open source'.
It is two highly common words with many different meanings based on context and personal opinion.
Just because the OSI org has recently sprung up and tried to rewrite common usage of the term, doesnt mean anyone pays any attention to them.
This is also why, even here on/., a bastion of FSF/FOSS zealotry, people are constantly having to correct each other with the 'free as-in-beer vs. free as-in-speech' comments, or the whole FOSS term. The concept of open and free as applies to software and software methodologies isnt even consistent on/., much less the general software developer population.
MS has chosen to because the subpopulation of developers they're trying to play nice with chooses to agree with the OSI definition. Thats just enlightened self-interest.
Slashdot Mirror
I know the argument is that they should have just 'stood up' against the media interests, but thats garbage. That would have also hurt the end-user as they couldnt play their blu-ray media, and it probably wouldnt have worked anyway.
The forum to eliminate the DRM problem is in the government, not in the OS technology. I'd also argue that it is MS's monopoly on desktop OS's that is the reason why there is so little advancement in the field. Traditionally, one of the main problems with monopolies is that they retard innovation in that market because the monopolist has little incentive to put time and money into improvements because customers are going to buy whatever they make anyway. Wow and you base this on what? I see 2 other competitors in the desktop OS world. Mac, a consumer-focused boutique brand that is hideously successful (money-wise) and has growing marketshare. Linux that is completely free and available to anyone, and though a pain in the ass for many to get working, CAN be made to get working for most situations.
So there definitely isnt any natural monopoly, or government supported monopoloy being abused. Mac is fairly innovative, and some of the (technological) features in the Linux world are quite innovative.
Your idea that innovation is stifled by Microsoft's supposed unbreachable monopoly just isnt borne out by facts. Hell, the barrier to entry into the OS world is so low that VOLUNTEERS have created a saleable product in that market. Face it, there is plenty of room for improvement of OS's. Hell, Vista still doesn't even have a spell checker that works in all my applications and uses the same dictionary, let alone other universal services. It's been what, ten years since the first OS with that feature was shipped (then killed). Thats your measure for innovation? A spell checker? Thats just absurd to me. Not to mention that IF Microsoft were to do that, then half of the anti-windows crowd would scream foul that they were including things in the OS and leveraging a monopoly to lock out innovation.
Not to mention that a universal spell checking service, while nice in theory is so very very far down the priority list for most people that it doesnt exists. I mean I actually laughed when I read that. Dont get me wrong, it would be useful, but so would butt air-conditioning in my office chair. Neither is going to happen. Not to mention that if someone wanted to make that product, they certainly could. I doubt if anyone would buy it though.
Thats not true at all.
I bought a brand new HP Compaq 8710w recently.
Top of the line, hideously overpowered, engineering laptop from their corporate line.
Vista x86 works great. Vista x64 works spectacularly. WinXP works perfectly.
But getting Ubuntu running on it was hideous, and several key hardware elements never could be made to work (ie, wifi). This despite the fact that the wifi card is the Intel abgn card that has a freaking open source driver for it. And you wouldnt believe the hoops I had to jump through just to get the installer not to fail (use alternate installer disk, modify the grub loader config to use a software framebuffer until I could get the nvidia drivers downloaded and installed).
In fact, based on my testing of the time, Ubuntu actually works BETTER on cut rate consumer garbage systems. That seems to be what it was designed for, and all the certified systems (of the time) were all consumer crap.
As a comparison, I had MUCH better luck with SuSE SLED, but still never could get the wifi working.
Compare that to the box now running Vista Business x64. I can sit on my couch and have it connected to my samsung DLP through HDMI and running 1920x1280. I can do that for work stuff, or random DivX videos, music, etc. Never have run into a single DRM issues, but then again, I dont buy anything with DRM, so its a non-start issue for me.
It was never a filesystem.
It was always a metadata layer built on top of NTFS.
I'm not going to do the research on this to provide links, but I'm 99.9% sure of this.
The bennies were an ubiquitous API and unified approach to this stuff, that any 3rd party software could use, and even end users directly could manipulate it.
The problem is it may not be relevant anymore. With horsepower and disk space so high nowadays compared to then, the simple brute force of the currently used desktop search systembs by MS and google work well and dont require a revolutionary product.
#1 will happen as a matter of course, since its the same driver model as Vista and Server 2008 use. So every month that goes by, the driver 'ecosystem' gets better.
/.).
#2 is just being silly. Thats just flat not a market requirement. Only the tiny percentage of techies want this, the 95% of the users out there dont care and have no expectation of this. They only want it to perform reasonably on the hardware it comes with.
People that say they're expecting this just dont get the market forces at work. There is NO DEMAND for an OS that performs better than the old one. It's not even going to be on the feature list at MS. No one cares (except for a subset of the people here on
Hell, just a cursory examination of some of the improvements they made to the internals of Vista would rule that out. They moved a LOT of drivers out into userspace. It's inevitable that this will have a performance impact, but with the bennie of improved stability once the IHVs learn how to write drivers properly for the product.
I dont think you understand the situation.
/. crowd doesnt get it, but thats because the typical slashdotter has a very shallow viewpoint, and not much experience in actually developing large complex software products.
MinWin exists now, you get it when you purchase Server 2008. It's called server core.
They dont seem to be interested in making that a part of the client OS distribution as they dont see a market for a desktop OS with only a command line interface.
Vista WAS the radical change, or didnt you notice all the driver incompatibilities?
The kernel and core of Vista was an excellent, technically impressive 10-year needed change to the windows platform, particularly if you're looking at the changes in the x64 versions.
Much of what you're seeing as problems with Vista are ecosystem issues, combined with the typical set of MS v1 bugs.
What you'll find nowadays is that if you have a clean build of Vista SP1, with quality drivers, and no crapware from the manufacturer, then Vista is an excellent platform. Fast, MUCH more stable and long running than XP, particularly on laptops.
Still has its growing pains, but not bad.
You can really see this in the pretty much universal accolades that Server 2008 is getting. And after all, Vista SP1 and Server 2008 are largely the same product, just some differences in tuning and what stuff is included in the OS by default.
Microsoft DID badly screw up the Vista deployment, but it wasnt in the technology. It was in the marketing, OEM relationships, and ecosystem development. I know most of the
It's both.
It's the same major generation of kernel, but of course they're also making evolutionary improvements to it while keeping binary compatibility, minimal api changes, driver scenarios the same, etc.
It's better to say that Vista SP1 is very close to the same kernel as Server 2008, and Windows 7 will be further evolution along the same major kernel generation.
What is your complaint about Groovy?
Lets you write code very similar to Ruby if you want, but its just java on the back-end, running on the JVM.
The 'me' in this case is missing the point.
You dont just run the tool over and over again and never adapt it to your code.
If it produces a bunch of false positives, then you go in and modify the rules to not generate those false positives.
Thats half the point of something like this, you need to tune it to your project.
The flip side is that if you see some devs over and over making the same kind of mistake, well you can write a new rule in it to flag that kind of thing.
If you have an endless number of false positives, that doesnt ever go down, then you are either:
1. Not using the tool correctly.
or
2. Not working on a project that is amenable to this tool.
IME, the vast majority of time its #1. Now you may find that for certain small or narrowly scoped projects, or those worked on by 2 super-gurus, that the overhead for learning and tuning the tool for that project isnt worth it. But thats something you'd have to find out yourself, and it differs from project to project.
Wow, nice story. Quite amazing, as you'd think the devs could just do things the right way for not much more work than gaming the tools.
This kind of thing though, is ultimately a failure of management, whoever leads/runs the dev team. They should be able to see this kind of thing happening and either apply some proper motivation, change the procedures, or let some bad devs go.
Mind you, bad developers as well. But if I were the owner, the dev mgr would get the brunt first on something like this.
You're almost certainly using a bridge & gatekeeper.
I think stoodin was talking about doing it decentralized, which doesnt really work past 2 or 3 nodes.
Decentralized wont work here at all.
Due to the bandwidth (minimum 800k per node) and processing requirements (heavy), this sort of thing doesnt really work with typical asymmetric bandwidth available to most sites.
The way you do this is with a bridge/reflector. Everyone dials into that, and it does the multiplexing, and re-broadcasts.
This gives you a star topology rather than a mesh, which is much more practical.
With decentralized, figure 7 nodes at 800k each, means that each node would need at least 6mbps upstream bandwidth available to them. Very few businesses have this, smaller than large orgs or universities.
MSN Messenger, iChat, etc dont qualify here either, as they're decentralized, so have this same problem.
Have you considered just saving yourself all this pain and acquiring a commercial bridge from codian or polycom?
I cant speak to your specific time/cost tradeoffs, but at some point, given the relative crappiness and/or non-availability of FOSS solutions, it may be cheaper to just buy something that works and move on to your real job.
I am saying that the features/functions the user considers important, or where greater levels of 'quality' are important to them, have little bearing to this article's definition of code quality.
The biggest thing TFA measures is readability, maintainability, etc. This has an indirect effect on the business' ability to change, update, etc.
But these are very indirect sorts of relationships, often through several layers of indirection, and with a delay time between code creation and benefit the user sees in several years or more, if ever. If the code quality improves quality of the product, it's a good thing. Yep, and thats the whole rub of it.
There is little evidence that code quality improves the quality of the product, from the end user point of view.
You can produce the same features, at the same level of quality, with no connection to code quality (though poorer code quality will likely make the product development more expensive over time).
Code Quality and Product/Feature Quality can be orthogonal. You can have great features, that do exactly what the user wants, and how he/she wants it, but the underlying code is terrible. And vice-versa, you can have the perfect code, beautiful to the eye, and easier to maintain, but doesnt provide the features the customer/market wants.
Businesses fail all the time because of the latter (great technology, poorly thought out product/business-plan), but rarely because of the former.
In the former case, it makes new versions and product enhancements more expensive, so it eats into your margins, and slows you down.
You're missing a very important point.
For the users of operating systems, the code quality is irrelevant.
Things like features, marketing, packaging, etc are what drives markets, not an academic analysis on source code quality.
This kind of information is only useful or interesting to those of us in the field.
As an analogy to automobiles, consider metrics on the complexity of supply chain dependencies in car manufacturing.
Only interesting to people in the business, not interesting at all to the people who actually buy and drive cars. They only care how cool it looks, mileage, and what colors you can get it in.
This article only speaks to things interesting to those of us who build these things for a living. It says nothing about the market/commercial success.
As a final trivial analogy, the most beautiful code in the world, used to create the perfect OS, doesnt mean squat if it doesnt provide features that its target audience wants.
I think you're misunderstanding what WRK is. It's not a research kernel, its a snapshot of the 2003-x64/XP-x64 kernel, minus a bunch of hardware layer stuff (HAL, etc) and minus everything from userspace.
The information to inform you is here, which was also linked on the summary to TFA.
I think you're vastly overestimating the overall knowledge, experience, and education in this context of the /. readership.
/. readers are programmers/developers (or in an academic speciality in this field).
/. will be familiar with the various theory, metrics and approaches to measuring and analyzing code quality.
/.
Only a small portion of the
Even amongst that population, only a small percentage are qualified in large operating systems development.
Similarly, a small percentage of the programmer subpopulation of
The target population of the paper are people who fit into all three of these groups. Thats not very many people.
I've been doing software development for a living for almost 2 decades, but arent familiar with many of the metrics and approaches used to analyze the source code (of course some, like cyclomatic complexity, line lengths, operands per line, etc etc I am familiar with).
This is incredibly narrowly focused stuff, even for
Thats quite a stretch. Given your viewpoint, I'm surprised you werent here ranting when MPL was released, that it looks too much like GPL. Or CDDL. Or CPL. Or EPL. Or ECL. Or APL. Or OSL. Or QPL. Or LPL. All of these are OSI categorized licenses that look alot like the GPL, and by your definitions, must be trying to confuse the market with their marks.
Oh wait, maybe its just an industry norm to abbreviate licenses this way. Sure is a lot of prior art in the area.
As to what some employees at MS may or may not intend with these license names are impossible to know, but ultimately irrelevant.
No reasonable human being would confuse MS-PL, MS-LPL, or MS-RL with GPL or LGPL. It just isnt going to happen.
No reasonable human being would confuse one of the restricted licenses like MS-RSL with an open source (as used by OSI) license/software. And you still didn't address the fact that you are ignoring the MS-LPL, MS-LRL, and MS-RSL, as well as several other licenses that they call "shared source". I'm not sure in what way I'm 'ignoring' them, given that we're sitting here talking about them. It's trivial to go look at the license text on microsoft.com and see what they are.
The 'Limited' versions of MS-PL and MS-RL restrict the use to just windows. It's not that complicated.
The MS-RSL is a 'view-only' license, and they're quite clear about that here. The Microsoft Reference Source License (Ms-RSL) is the most restrictive of the Microsoft source code licenses. The license prohibits all use of source code other than the viewing of the code for reference purposes. The intent of this license is to enable licensors to release, for review purposes only, more sensitive intellectual property assets. So given how easy it is to understand what those licenses you mention are, I'm not sure what your complaint is.
Are you complaining that there are restrictive licenses used by Microsoft at all? Or that they all use acronyms and therefore may be confusing (to who?). Or are you suggesting that MS-RSL, MS-LPL, or MS-LRL are too similar to LGPL and GPL to be understandable by a reasonable person?
If the latter, who are these people you're dealing with that cant differentiate between words with different letters?
I'm not sure how your post got marked 5 insightful.
There is no confusion about why they dropped it in the first place.
Right there one of the paragraphs in TFA talks about it, and has a link to a prior blog posts that states exactly why they dropped it.
That may be so, but I bet your misunderstanding didnt last through the first actual inspection of OOXML.
/. groupthink, MS is not obligated to make all of their product names sound hugely different from any and all open source projects.
And think about it from the other point of view.
If you were in a leadership position within MS and had to choose a name for the format, what would you call it?
'Office Open XML' makes perfect sense, is accurate and descriptive, and translates into a nice acronym.
Despite the
Language is defined by what is understandable. In items like this, 'common understanding' is usually the threshold used.
But the problem is, even within the software development industry, there's no common agreement or understanding among the practitioners that 'Open Source' means what you (or OSI) says it means. Concerning your statement that "the term 'open source' has been around for much, much longer than the OSI has even existed" the following discussion and statement by Bruce Perens right here on Slashdot might be of interest: Yeah, I saw Bruce's posts, and he responded to two of my posts with the same idea. And with all due respect to him, he also doesnt get to decide how the language is used, nor does he get to re-write history.
Prior to OSI, (and still so for a large number of developers in the industry) open source was generally understood to mean source viewable or available. It did not make any judgement or statement about what licenses or restrictions applied to your use of this source, it just was concerned with whether the source was available at all.
As I responded to Bruce Perens, although it wasnt used in the 'quoted and capitalized' form, the non-quoted and non-capitalized form would have been generally understandable for the last 20 years. But that general understanding wouldnt have been so specific to include all the distinctions of Bruce's or OSI's definitions.
In fact, one could even argue that folks like Bruce Perens and OSI are engaged in the same sort of guerrila campaign to modify the language that the slashdotters are accusing Microsoft of.
I say this because at this point in time, 'Open Source' as OSI defines it is not the same thing as 'open source'. They're trying to make it a proper noun that has special meaning, but is visually indistinguishable from the non-proper noun term.
I dont have any problem with this, any human is welcome to throw their hat in the ring and try to change society. Doing so by changing the language is an effective approach to this.
But I dont like people re-writing history or trying to say that their definition of something is the official definition when its not even in common usage, even within the specific industry jargon.
Whether you pick MS-LPL or MS-PL or MS-RSL is irrelevant.
No reasonable human being would confuse these with GPL or LGPL. I mean heck, they all have a giant MS- stuck in front of them.
And if anyone is so unfamiliar with English language that they cannot distinguish 'shared source' from 'open source' then they are not a reasonable person to be in a decision making role for software acquisition.
Even when reading the license text directly, the MS licenses are simple and clear. They're fairly similar to many other licenses out there, but with the patent poison-pill business, which is very reasonable for a commercial company to use at this point in legal history in the US.
Okay, I realize I'm late coming back to this, and no one but you (Bruce) will probably read this, but ...
I agree that the quoted, capitalized term 'Open Source' as such was not in common use, but a much looser phrasing has been common for 20+ years, as in 'open source' (ie, no caps, no hoopla surrounding it) or 'source available'.
It's only when (at least in my perspective) FSF and that group brought religion/politics into it that it became a capitalized phrase with 'extra meaning'. But thats always been controversial.
Even today, the vast majority of developers (both corporate and ISV) (at least that I've encountered) do not share a consensus about what that means.
Many have a vague notion that it means free (as in public domain or bsd-style licenses), many understand that it means source viewable, but very very few have any understanding of the subtleties and commercial implications of 'copyleft' style licenses such as GPL and similar.
In other words, there's no common understanding now that it means what OSI defines it to mean. Only among a highly specialized niche of the software development industry is the OSI definition widely agreed with (versus the more loosely defined concept).
I would disagree with you though that it wasnt in common usage. That exact, quoted and capitalized phrase was not used as-such, but the term used without the quotes and capitalization would have been generally understood to mean at least source-viewable for the last 20 years.
Even now its not as clear as OSI would like it to be. OSI certifies both BSD/Apache style licenses (ie, commercial friendly) and GPL (community friendly) as 'open source', but software licensed under these two types are hugely different in how you can use them. They may have similar development methodologies, but for licensing//use concerns, they are completely unrelated and distinctive. About the only similarity between the two is that they're not proprietary.
Based on this, which does 'Open Source' mean? If it means both, then its a fairly diluted 'official' definition, which pretty much defeats the purpose of having an 'official' definition.
The MS-RSL (reference source license) that they're using for
This is a huge thing, and a big win for
And take all the MS-PL code on CodePlex.com. This doesnt help MS directly (though indirectly it does by enhancing the ecosystem), but its a huge win for any windows developer because there is SO MUCH code there that can be used. It's not as useful as Apache is for Java devs, but its heading strongly in that direction.
Here's another case where the MS-PL is hugely (and directly) beneficial to the customers, and only beneficial to MS through indirections. Thats the great thing about these, they are win/win for both parties.
And look at the MS-PL and MS-RL. The biggest difference between these and other typical FOSS licenses are the patent mutually-assured-destruction business. Basically its saying that if you sue the developer over patents, then you lose the right to use their software and any related patents. Thats eminently reasonable for a commercial entity.
The MS-PL and MS-RL do not lock you into a platform. The 'L' versions of these do, by locking the licensed software onto windows.
Thats my whole point. There is NOT any official definition of the term 'open source'.
/., a bastion of FSF/FOSS zealotry, people are constantly having to correct each other with the 'free as-in-beer vs. free as-in-speech' comments, or the whole FOSS term. The concept of open and free as applies to software and software methodologies isnt even consistent on /., much less the general software developer population.
It is two highly common words with many different meanings based on context and personal opinion.
Just because the OSI org has recently sprung up and tried to rewrite common usage of the term, doesnt mean anyone pays any attention to them.
This is also why, even here on
MS has chosen to because the subpopulation of developers they're trying to play nice with chooses to agree with the OSI definition. Thats just enlightened self-interest.