Yup, that's exactly what they want. Technically if you live in Maine and tele-order from Ca you are SUPPOSED to declare it and pay a Maine Use tax (many/most other states are same-same). That is, tax is paid where you live/product is shipped to. Now most people do not comply and tele-order USED to be a small percentage of all traffic in a given state so non compliance had little real tax impact. Along comes the Internet and amazon.com, ebay, and a host of other large tele-order business. Suddenly a few percent of all tele-business is a big number. Non compliance is now seen as a big number. State's new attitide, 'cough up'.
I think I said, I believe we all consider a week too short and a year too long. The issue (IMO) is where is the correct middle ground. I can see issues taking from days to a couple of months once the exploit is identified at the code level. Everything has some base cost below which it can not drop, whether a one line fix or a major release, you have a packaging process. If packaging takes a week at company X then the minimal amount of time to release a product is at least a week, if it takes a month then the minimum is a month. You can argue that it SHOULDN'T take that long but that does not reduce time to market for today's bug. The one day fix at any major software developer is a myth, IMO.
Given the complexity of the fix, there is some minimal testing cost, 1 day to potentially weeks. This cost rises as your product runs in more diverse environments. Testing a new internal house app that runs on one platform with a handful of users is simpler than testing a new release of Windows or Linux with a user base of millions. Consequently, testing a patch to the core of the house app is likely to have less scheduled regression test than a patch to the Windows or Linux kernel. Just a fact of life in products with a large diverse user base.
Buffer overflow is the usual example of a 'simple fix'. OK, let's look at a case. In a buffer overflow fix you can either truncate the input to fit the buffer or reject the input (return error), I can not think of another choice, can you?
If you truncate the buffer, you pass obviously bogus data downstream to further processing. Hmmmm, will that GPF the app later? What impact will it have? What impacts should I test for? How many test cases with data should I craft? Did I craft the 'correct'/'optimal' tests to ensure I tested down stream impact as best I can? How much analysis time will it take to ensure I craft the correct down stream test cases?
OK, let's return an error, it is easier. Oh wait, that routine never did return an error, fix up all callers and have them handle the returned error (recurse for parents that do not handle errors). Oh, it CAN return an error. Should I have a new error (see previous fix up parent comment) or pick an existing error to minimize up stream impact. If I pick an existing error, what does the end user see as an error message, is it confusing? Gee how many up stream locations call this function and how many reort error up stream and what actually ges displayed? What test cases do I need to craft?...
Hhhhhm simple buffer overflows are not necessarily so simple. Then again they MAY be, you may already have an 'invalid input' error return code. It all depends.:)
This is where most VENDORS fall down. If it is complex and they keep the bug reporter in the loop, I'd bet more time would be provided. Ancedotal evidence points to the fact that most vendors do not keep the bug reporter in the loop. They then get indigent when the 'complex' bug is made public. Bad planning on their part IMO.
Yeah, I can see a comment after some minimally reasonable time that says, 'an issue exists'. I think we all agree that there is a difference between:
1 - Issue exists 2 - Issue of type X exists in screen field Y 3 - Issue of type X exists in screen field Y and here is sample exploit code
Maybe all three are reasonable disclosure statements just arguably at different timeframes. A statement that says 'We may have found a remote/local exploit vunerability in program X and are working with the manufacturer to confirm the issue' is pretty low on the 'bad guys have more data' risk meter. However, if you do that you are under obligation to follow up with more data at reasonable intervals. Say another status report in a week or two and that report has a deadline for a follow up report. Do NOT leave the community hanging. You want to jump on the early bandwagon, you are on the hook for follow up until the issue is resolved or 'public'. As you point out, continued communication is critical. Finding potential exploit info without follow up leaves everyone guessing if it was real, fixed, exploited, or what happened.
It is in the best interests of the user community in several ways. First, it puts pressure on teh software company to patch quickly. Second, it allows users to compare patch histories (quantity and response time) in choosing a product/company. Lastly, the bad guys have a communications system just like the good guys, eventually it WILL be common knowledge on the 'dark side', it needs to be common knowledge on the 'light side' as well.
The issue is 'what is a reasonable timeframe'. Someone said 3 months, someone else said 1 week, and someone said it can take a year. As we all know, 'reasonable' is a subjective term.
I think 1 week is not sufficient. I work in a small software company and I deal with large companies. A large company can't issue a memo in 1 week, it can't get from the department where you reported it to the department that needs to fix it in a week (notify development, support, QA, and 'shipping/distribution' managers and get an impact statement).
As to the one year to fix it estimate, that seems very unreasonable, especially at Internet time speeds. The 'dark side' will be well versed in the bug well before that time has passed.
Is it 1 month, 3 months, 6 months, or 9 months? It probably depends on where the bug is located. We develop a small niche market piece of middleware. A 'full QA' run (specifically test new function, regression test all other functions) can take a couple weeks even using automated test suites (runs on 10+ platforms, several hundred tests per platform, some testing is single threaded due to 'expensive hardware' resource issues, some test have to be manual). Packaging issues across 10 platforms with doco can add a couple more weeks. All assuming we know the exact coding bug and do not have to analyse the reported problem.
So if a specific coding bug is reported in a core secton of the product, it can take a couple weeks of QA, plus Dev time, plus packaging, plus documentation, plus... So a core change that impacts packaging and doco can easily be a month or more. On the other hand, a 'typo' that does not impact packaging (impossible, we have to release it somehow so some 'packaging' is needed) or doco can be a few days.
Consequently, I'd guess 1 month is too short as well. I'd posit that a couple of months (3?) from the time the coding level fix it identified is probably a reasonable startng point. Given some reports I've received it can take from minutes to a lifetime to narrow the reported issue to a coding level fix.
OK, I'm not a CFO but I am a CTO and I'll tell you why the CxO group likes certs. The clients require it (indirectly). First let me say, I personally do not find certs useful. They do not actually tell me that 'the guy' can do the job. I prefer the interview process to weed out the deadwood. However...
When a contract goes out to bid and a company replies, in many cases CV's of the potential staff are required or at least requested. Bottom line, a staff with no certs and no degrees does not 'paper stack' against a company with lots of certs. Result, no contract, net result, no company over time.
So for the small company CxO, the client requirements drive the bus. Government contracts frequently require CVs unless you are 'known'. Large fortune 100 contracts frequently use CVs or corporate rep to weed out the list at first pass to the first 'short list'. So you want on the short list to get to talk to a human, have the certs.
Large companys have come to rely on the certs as the first pass weeding process. Now lot's of large consulting companies pay for certs so they have staff that passes the checklist test (feeding the cycle). Small companies do not always have the cash, they tend to hire certs (let the big boys or the employee pay) or not play in that space. The game is not likely to stop, too entrenched and the vendors are feeding the lions more certs everyday.
Just my opinion of the issue, YMMV as they say. Or put another way, "I'm a CxO, what to hell do I know about anything".
My point is that Grandma is 'sharing' pictures when she emails them. So are several other non techies that I talk to. The 'I sent Sue that picture of little Joey the other day and she loved it. If you have other pictures to share I'd be happy to send them on.' comments abound. Hell a good percentage of non techies don't know if they are using outlook or IE for email. So it REALLY depends on how the data was collected/collated.
Did someone look for filenames ending in.jpg,.mp3,.wmv,.gif, and.avi followed by lots of binary data (may be an ftp, an email, or go knows what) or did people determine lots of P2P activity existed and it MUST be media (could be bit torrents of the linux kernel).
As techies we ASSUME that sharing means P2P. Now in finest slashdot tradition, I have not read the article. It may well be that a definition was given, but I'm assuming that people assumed P2P:).
Guess I'll have to read the article when it is available, so little time so many articles...
Guys, Sharing media files may not mean P2P. I hate to say it but it is possible to email a couple of meg picture of the kid/grandkid nowdays. With email like gmail/hotmail/... allowing attachments in the multimeg range, the odd photo or sound bite times a few million people can add up.
It does if you're logging in:). If you log in, I can chain the cookies or update the current cookie you are using. Simply store the one TRUE cookie in the login context and use that cookie to 'bind' them all or to replace as necessary.
You are assuming it was an invitation for a job. Perhaps it was an invitation for an interview (a different animal). Way back in the mid 80's I was phoned and offered an interview at MS. I went, I survived a few hours of question marathon, and eventually offered a job (turned it down). The original offer was for an interview, not a job. That offer was due to the fact that someone at MS had worked with me previously and thought MS might want to hire me (i.e., an internal unsolicited reference from an existing high level staffer).
Confusion can occur. May be he thought it was a job offer, but it was an interview offer. I know that in my case, I was confused and I asked a direct question before I caught the plane. "Are you offering me a job, if so what position and what salary range?", the answer was "no, you were recommend by someone at MS and we are offering you an interview". It DID seem a bit bizzare to be cold called and offered a job, so I asked questions. Perhaps, he did not and assumed?
Nope. I've learned that with anything related to statistics, you need to know the definitions and sampling to understand it.
Bottomline, in the previous post you mentioned that they sample a population group until they become employed or 'leave the labor market'. Is that die? Do they follow people for say 35 years? I doubt it, so there is PROBABLY some other 'reasonable' definition of 'leave the labor market'. As you say it is a highly reviewed report so I'm sure there is a definition of 'reasonable' that is truely reasonable. I'm NOT sure it is the same definition as that in my head at this moment.
As example questions: If it is sampled, is it by industry and weighting applied? If so, is the weighting dynamic? Given the IT situation 5 years ago, unemployment in IT was low. Now not as low. Did the weight of a 'sampled' IT worker change? (how dynamic, quarterly or every five years) If it isn't weighted, aren't they assuming that unemployment time is industry independant (an interesting tidbit if true and something I would not have guessed).
If the weight is dynamic based on projected number of unemployed in that industry, is that number estimated based on claim data (maybe over N weeks/months/years)? Or maybe better put is, we expect that N% of the unemployed are from the auto manufact industry, Y% from IT, Z% from fast food,... consequently given our sample data set and their return to work rate, that projects to... So how did they get N% Y% and Z%, picked 50 guys at random and divided them up, survey data, unemployment data from the previous quarter,...
All interesting tidbits used to understand the report. I'm NOT claiming the report is wrong. I AM claiming that without the definitions and methods it can not be completely understood (need context).
The obvious example, a large city has a dispatcher a small city wants to make us of that dispatcher for a fee. Last year the large city paid $150,000 for dispatch, how much should the small city pay? The large city says $60,000 because that's what they calculated. The first question out of most people's mouth is, how did you calculate it?
Should the dispatch rate be calculated on number of calls (us vs. them last year), a 50/50 split of the salary of the dispatcher, a 50/50 split of the time and equipment costs, a split of the time, equipment, and building costs,... All may be REASONABLE methods, but one gets chosen. How often do we recalculate the 'costs'? Yearly? Quarterly?
Questions about the method ALWAYS occur during contract talks or money talks so people understand the deal. Questions like that SHOULD occur when people see statistics so people understand the 'deal'. If unemployment is up 22% this quarter but it is basically in the 'foo' market but I work in the 'bar' market, do I care? Probably not. But if the number is presented as unemployment is up 22% this quarter (without definition or clarification) I COULD get nervous. If I understand the number, I KNOW whether to get nervous. I.e., 22% without more information is interesting, but insufficient to truly understand the unemployment situation.
Hopefully this long winded post clarifys why I asked, I wanted context.
Quasi serious, I wasn't sure how they did it. I WAS sure they didn't track EVERYONE. Obviously it was either the quick, stupid, method (check claims) or some sort of statistical method.
I assumed someone on slashdot would fail to restrain themselves and I'd be come enlightened, cheaply. (Thanks!)
Now, you do not happen to know the gory details of the statistical sampling methods used, do you? Like Mr Clemmons said, "lies, damn lies, and statistics".
Now how are they REALLY counted. If you are on unemployment and you go to the office every week or file the paperwork every week to get your check, you are easy to count. If your benefits run out and you stop filing the paperwork, what happens? Does someone call you every week/month to see if you finally got a job (yeah, right)? Do they just assume you will never get a job and you are counted for life (yeah, right)?
So while that is the official definition, how does it REALLY work? Is the bureaucratic definition, "those that filed paperwork"?
As the guy in SE Asia recently found out, very easy. He had a car that would not start without his fingerprint. The carjackers whacked his wrist with a machette, car starts fine. It turns out that in SE Asia (at least that part), his car was worth more to the carjackers than the trouble of hacking off his hand.
Bottomline, biometrics are good if what you are protecting is worth more than the human (launch codes), not so good for something cheap. Faced with "give up that candy bar or we'll hack off your hand and take it", I'd rather they take the candy bar.
Just because you CAN protect something with biometrics, doesn't mean you should.
It's harder to loan/tell someone your fingerprint.
The bottomline line issue is: does the library intend to require id to use the computers. If yes, then the privacy veil has already been pierced whether a swipe card, barcode, or a fingerprint hash is used.
Since the fingerprint is not stored but hashed and the hash is stored, the fingerprint vs. the 'id card' is not (in my opinion) worse. Privacy is lost either way and no additional REAL data is given up.
Whether the library SHOULD require ID, is the question. Given federal/state funding requirements and laws like CIPA and the Patriot Act, it is more complex than it appears on the surface.
How about "plugs into a single 110 volt US outlet". This thing draws 1500 watts PEAK. That's about 14 amps for the math challenged or well under the recommended max for a 20-amp circuit from your household panel (think coffee maker on steroids). Let's try your barebones system approach and let's say you tweak it to use 50 watts per system (good luck). That's 50 watts per system multiplied by roughly 100 systems => 5Kwatts or 3+ times the power consumption. PLUS as an added bonus you get 96 cases, external cabling, at least 96 fans, a dozen power strips, and assorted other toys to trip over. Oh yeah and a few weeks of setup, integration, burn in, and testing.
It appears that you have a social issue (don't care) and not a technical/education issue (can't figure out how to get/install/update the antivirus). Most technical answers really do not work in that environment.
The best technical response to the social issue is usually REALLY an attempt at a social response. I'll talk to you (education), disconnect you (isolation, banishment,...), or use peer pressure. It appears from your comments you have tried education and have difficultly with banishment, so you have to try other social fixes. How about a PUBLIC weekly/monthly list of the top ten lusers causing a slow/bad network environment. You hog bandwidth (virus, spam, trojans, excessive bittorrent,...) or cause your neighbors pain (virus, hacking,...) you make the list. You want off the list, fix the issue and have it stay fixed for a week/month.
Note: this can create a different issue, those interested in 15 minutes of fame regardless of cost. Without a plan to handle that occurance (banishment is the usual), you risk trading the current issue for a different issue.
An additional technical mechnism is to install a bandwidth management mechanism. If you make the list you get your allowed bandwidth reduced by X% for each week/time you are on the list. Screw up lose 20% of the allowed bandwidth, don't fix it, lose another 20%. After about a month of being on the list, you are down to zero. You stay at zero until the issue is fixed, and then move to say 60% until it stays fixed for X period of time (or it gets reduced again). This is somewhat of a progressive banishment solution which may or may not work in your environment.
Bottomline, you need to pass on the pain to the people that deserve it. Technical solutions do not do that, social ones do. The only technical response to your problem is to find a technical mechnism to enforce a social solution.
Hey, I never claimed he was wrong. I'll try one more time. Let's start with RMS can start what ever movement he wants with what ever rules he wants. I'll even grant that his ethics won't change over time and that it will always be about ethics for him.
Let's continue with business is free to ignore him. So let's posit why is Free software popular with business, did the movement catch on in the business world? (A frequent argument I hear, even businesses like IBM/NOVELL/HP/SUN/... are 'seeing the light'.)
My answer, NO! Business doesn't care about the movement. Anyone that thinks that business use of Free software is a win for the ethics of free software, is reading the situation wrong (IMO). Business cares about TCO, you know the whole Capitalism == Profit thing. Confusing the growth of Linux in the Business world (and likely the rest of the world) with the ethics of the free software movement is blowing sunshine where it doesn't belong.
And for the record I'm fully aware of the difference between Free and Open source, I've contributed to both and I read software licenses about every week as part of my job. My point was and still is, that Business doesn't differentiate, even though Mr. Stallman would like it if they did.
Assuming the distinction is an integral part of the 'market success' of Linux or Free Software is a mistake waiting to happen. Hence the concern over what was changing in GPL 3, would it force people off Linux and on to BSD?
Stallman is not stupid. He appears to understand the issue, change is coming in small increments. Much like Microsoft he appears to know his market space. His movement can target the users of Free Software while the license maintains the monopoly on code use to keep Microsoft and others from competing cheaply. The business users of GNU/Linux as a platform do not care about the license, it works, has low TCO, and has good support. Free software 'product' has low development cost (close to free, due to volunteer labor) and high barrier to competition (Microsoft does not have 'free' labor). Its competitors are locked out from 'standing on its shoulders' much as Microsoft's competitors are locked out from standing on MS' shoulders. The code model (GPL license from a competition standpoint ONLY) is very proprietary, what is owned by MS can not be used by its competitors to compete against MS and what is 'owned' by the Free software movement can not be used by its proprietary oriented competitors to compete against it. As has been said many times, really quite brilliant.
The LGPL license is a bit more flexible, Companies and people can use LGPL code to compete against Free Software (in a different market space) in a for profit mode. If the 'for profit' guys can do a better job to be worth the price difference, they fairly win profit, if they can't then they lose their investment. Any changes a company makes to the LGPL portion of the code must be given back to the community so the community can compete fairly. A quasi even playing field where both parties get the same leg up, the common LGPL code. (OK, Free Software has the leg up over the long term, incredibly low development cost. The 'for profit' group has the leg up in the short term, toss money at it, reduce time to market, hope you make the money back.)
From an end user perspective, this is good. Common code gets enhanced by both and competition occurs on a quasi even field for the customer mindshare with Free Software potentially getting the long term cheap labor advantage. The more code (as a percent of product) that is LGPL the lower the burden to market entry and likely a lower price of proprietary software (giving an advantage to Free Software with its lower cost structure).
I understand that this is not essential to RMS, as he (to a large extent) doesn't really believe that proprietary software should exist. It may however, help in small markets where Free hasn't penetrated or even in large markets where a high quality profit oriented pro
Actually if you note my post I used F/OSS in response to the post about Free Software. My terminology is fine, my clarity is not.
My point is that, in general, business doesn't care if it is Free or Open software. To be REALLY clear, they really do not care about the ethics, they care about either the market or the TCO. If they are hyping Free software it is likely because they sell service in that market to make money. If they are not hyping it but are using it, it is likely an effort to reduce TCO. So Free software is hot in the business world right now more because of free as in beer (TCO) than free as in freedom (ethics). The freedom part is useful because it reduces TCO (pretrained staff, available patches, free GOOD web support, reasonable distribution portability,...).
When people start to move to the 'ethics is king' side of the road they occaisionally need a reminder that it is not the only motivating factor in the use of Free software. Sure, it is RMS' motivation.
However, to some extent GPL software is not truly free as in freedom. There is a second class citizen, business. From a true free software for EVERYONE, PD or LGPL is a better choice. The LGPL allows the author to get enhancements and maintain GPL like control over his pieces but allows everyone to use it how they see fit (even for profit which is a motivator for some to apply their talent).
Personally and professionally it doesn't matter which F/OSS infrastructure I use. I'll use the one that makes sense to run my network (Linux, BSD, even FreeDOS:-) and the company will produce software for the fastest moving train (currently Linux) to make profit. In talking to others in the industry, they seem to feel the same, they just don't say it in public.
------- Free Software is not Open Source. Ethics is the whole point behind Free Software. Rarely does a moderate stance drive change. -------
With respect, ethics may be YOUR whole point behind free software but it is not everyone's point. As a CTO for a small company there are several corporate reasons I use 'free software', honestly most boil down to cost and support.
Linux in a corporate environment is about both free as in beer and free as in choice to switch. BUT both are really a TCO issue. The free to switch or modify is about reducing risk or cost, not about having more toys or supporting an ethic.
My boss doesn't care about the freedom ethics of F/OSS. He cares about his bottomline (that IS his job) and the freedom ethics of F/OSS are a means to an end. The corporate advantage of freedom in F/OSS is about the availability of patches, the replacement of developers, and the long term availability of inexpensive product.
IBM/Novell/HP/? doesn't support Linux because it is cool, they don't support it because of free as in freedom. They support it because they can make money that way. It adds billions per year to their bottomline. If Linux dies off tomorrow and BSD is the new drug of choice, they will support that and my corporate infrastructure will run on that (in fact it did, before Linux). They go where the customer goes, that's where the money is.
What is driving change on the corporate level is the low TCO, good support, and the hype reaching senior management. BSD has low TCO, not as good a support structure (but still good) and significantly less hype. Small companies have used it for years before Linux and some still use it today. The hype reaching management and the availability of 'linux trained staff' in droves off the street (compared to BSD) is Linux's major leg up in the corporate network infrastructure game. Easy to get/use mail server stuff, www server stuff, DNS, anti-virus, anti-spam, file/print share, networking,... with easy to find staff (that increase the internal hype) can really reduce the network infrastructure TCO.
Now this is stated by someone that has given away free (as in beer and freedom) software since the early 1980s (waaay pre GPL, I did it public domain:). I like Linux, I've used Linux since about the 0.93(?) kernel. I like the concept of free (freedom) software, always have, that's why I've released tools PD years ago (sadly I push paper not bits now). But my job isn't about what I like, it is about doing my bit to improve profit and reduce costs. As it is in most corporations I've ever worked at. Linux does that, that's the reason to implement it in a corporation.
------------------ Nearly all popular linux distributions now come on more than one CD (even if you ignore the source code) and the default installations are WAY bigger than that of Windows XP. ------------------
Gee, don't do much do you. My windows install comes on a crate load of CDs, first one is Win 2000, then several for Visual Studio, then a couple more for Photoshop, then several more for MS Office and finally several more for MS SQL. I think I have about 10-15 CDs for my Windows install.
Oh yeah, my Linux desktop does all that (and more) from I think about 4 CDs (haven't counted recently).
Oh, and as far a space goes, I have a Linux server (old terminal server software) booting from a floppy. I think my total disk requirement is 1.3MB and it runs in 32MB of RAM (I had it so I used it, probably could use less). While I seem to remember Win 3.1 running is less than 32 MB of RAM, I don't think it could boot from floppy.
Methinks you missed the point, you can have it ALL or you can take almost NOTHING. How it is packaged is only marketing. Now admittedly Granny cares about marketing and ease of use more than I do (and Linux can learn from Windows there). But Linux CAN be both smaller and provide more functionality per dollar than Windows, depending on your needs and expertise.
Well, hopefully it is done in true clean room style then no one gets sued. Second, they can find Jon, they do not know about 'me'. And third, I haven't produced the software, I do not distribute the software, and sueing me doesn't stop distribution.
Remember, my 'crime' is accessing them with illegal software, which usually means I lose my account (NB: I have NOT read the actual Apple agreement, comment is based on knowledge of other agreements). Loss of account is not a big stick. Issues may or may not exist with 'circumventing DRM' but probably do not if I live in Norway. It's all about where you live and what you did not JUST what you did.
NB: If DRM is added by the client and I document the protocol to the server as a spec, I did not circumvent DRM as I didn't build anything or remove DRM from a protocol or file. I simply looked at a point where DRM did not exist (yeah, angels and heads of pins). I did not build anything that copied copyrighted material. I AM probably in violation of the agreement and that WOULD lead to cancelation of my account. I'm not sure if anything worse is apt to stick.
Ahh, NO. Someone may have to connect but it does not have to be him.
Let's say I connect to iTunes with Apple's software and I pay for stuff as a normal user. While I'm doing it, I capture network traffic logs, debugger output, etc. Then I write a spec and hand it to Jon. He writes the code and hands it back. I run his stuff and the 'real' stuff and issue change requests. He implements the change requests and we iterate. His hands are clean (mine may be dirty but his are clean). He never connected to iTunes.
Or, I could reverse engineer it, build the server (as you mention) and let Jon code against my server.
The whole clean room reverse engineering methodology is more complex but similar in intent to this (you'd REALLY like both sets of hands to be clean).
OK, slightly different things but not as different (IMO) as you think. MS claims forks are bad. You seem to claim they are not really bad in practice (disagree, sort of). Forks can be bad for several reasons retraining, rework, for lack of a better term fork cascades, market confusion, momentum stalls, and probably several I missed.
Retraining falls into a couple of buckets: user UI retraining, developer API retraining, and testing/packaging/distribution retraining.
Rework occurs when a fork occurs in a 'base product' like X, and the existing API changes over time (more likely as new owners make their mark as opposed to old owners maintain direction) and I need to recode my app to the new API.
Fork cascades occur when there is no clear winner in an area. This can occur whether the base product was forked (XFree, XOrg) or whether 2 different base products fill the same niche (Gnome, KDE). Other development projects that rely on that base product/niche as a requirement now have to fork to support multiple niche filling parties. Hence my example about forking an internal dev tree to support both Gnome and KDE.
Yes as a niche gets several competing players, different toolkits arrive on the scene to help bridge the pain gap, but they all introduce compromises (look and feel, performance,...).
So the strength of OSS, important dead/dying projects get revived, can become the weakness of OSS, no clear standard. All because any Yahoo can pick up a set of source and create 'his/her' version. Now not any idiot (OK, stop with the exceptional idiot jokes) can get their vision to be a real competing player in a niche so there is some self limiting involved. However, when true competing projects do arrive on the scene, they can make developer hell a reality. This saps effort, confuses the market, and stalls momentum in that area. How many, "I'm building an app, should I use Gnome or KDE" or "Should I code directly to KDE or use QT for portability " messages have you seen? If they'd just code the damn thing it would be at market already and the resource could free up to improve it or do another needed project. But they can't, coding for both is too big, using a toolkit is a research project in trade offs, and ultimately they are as confused as the rest of the market.
So you are correct, XOrg replacing XFree is a good thing. The old project effectively dies and life move on with little long term confusion or impact.
However, MS is correct, Gnome/KDE/QT/the next big thing is stalling desktop momentum and no one can say that what they pick today is the correct choice. No one has a road map to provide developers with a long term strategy for development. One could argue that the MS road map changes, (DDE, OLE, OLE2, COM, COM2,...) but in general the MS stuff maintains good backward compatibility. I just fired up an ancient app that used OLE and it still worked, not always true with OSS stuff (usual 'HELP!' response, why aren't you running the latest stuff, that's WAY too old).
Slashdot Mirror
Yup, that's exactly what they want. Technically if you live in Maine and tele-order from Ca you are SUPPOSED to declare it and pay a Maine Use tax (many/most other states are same-same). That is, tax is paid where you live/product is shipped to. Now most people do not comply and tele-order USED to be a small percentage of all traffic in a given state so non compliance had little real tax impact. Along comes the Internet and amazon.com, ebay, and a host of other large tele-order business. Suddenly a few percent of all tele-business is a big number. Non compliance is now seen as a big number. State's new attitide, 'cough up'.
I think I said, I believe we all consider a week too short and a year too long. The issue (IMO) is where is the correct middle ground. I can see issues taking from days to a couple of months once the exploit is identified at the code level. Everything has some base cost below which it can not drop, whether a one line fix or a major release, you have a packaging process. If packaging takes a week at company X then the minimal amount of time to release a product is at least a week, if it takes a month then the minimum is a month. You can argue that it SHOULDN'T take that long but that does not reduce time to market for today's bug. The one day fix at any major software developer is a myth, IMO.
...
:)
Given the complexity of the fix, there is some minimal testing cost, 1 day to potentially weeks. This cost rises as your product runs in more diverse environments. Testing a new internal house app that runs on one platform with a handful of users is simpler than testing a new release of Windows or Linux with a user base of millions. Consequently, testing a patch to the core of the house app is likely to have less scheduled regression test than a patch to the Windows or Linux kernel. Just a fact of life in products with a large diverse user base.
Buffer overflow is the usual example of a 'simple fix'. OK, let's look at a case. In a buffer overflow fix you can either truncate the input to fit the buffer or reject the input (return error), I can not think of another choice, can you?
If you truncate the buffer, you pass obviously bogus data downstream to further processing. Hmmmm, will that GPF the app later? What impact will it have? What impacts should I test for? How many test cases with data should I craft? Did I craft the 'correct'/'optimal' tests to ensure I tested down stream impact as best I can? How much analysis time will it take to ensure I craft the correct down stream test cases?
OK, let's return an error, it is easier. Oh wait, that routine never did return an error, fix up all callers and have them handle the returned error (recurse for parents that do not handle errors). Oh, it CAN return an error. Should I have a new error (see previous fix up parent comment) or pick an existing error to minimize up stream impact. If I pick an existing error, what does the end user see as an error message, is it confusing? Gee how many up stream locations call this function and how many reort error up stream and what actually ges displayed? What test cases do I need to craft?
Hhhhhm simple buffer overflows are not necessarily so simple. Then again they MAY be, you may already have an 'invalid input' error return code. It all depends.
This is where most VENDORS fall down. If it is complex and they keep the bug reporter in the loop, I'd bet more time would be provided. Ancedotal evidence points to the fact that most vendors do not keep the bug reporter in the loop. They then get indigent when the 'complex' bug is made public. Bad planning on their part IMO.
Yeah, I can see a comment after some minimally reasonable time that says, 'an issue exists'. I think we all agree that there is a difference between:
1 - Issue exists
2 - Issue of type X exists in screen field Y
3 - Issue of type X exists in screen field Y and here is sample exploit code
Maybe all three are reasonable disclosure statements just arguably at different timeframes. A statement that says 'We may have found a remote/local exploit vunerability in program X and are working with the manufacturer to confirm the issue' is pretty low on the 'bad guys have more data' risk meter. However, if you do that you are under obligation to follow up with more data at reasonable intervals. Say another status report in a week or two and that report has a deadline for a follow up report. Do NOT leave the community hanging. You want to jump on the early bandwagon, you are on the hook for follow up until the issue is resolved or 'public'. As you point out, continued communication is critical. Finding potential exploit info without follow up leaves everyone guessing if it was real, fixed, exploited, or what happened.
It is in the best interests of the user community in several ways. First, it puts pressure on teh software company to patch quickly. Second, it allows users to compare patch histories (quantity and response time) in choosing a product/company. Lastly, the bad guys have a communications system just like the good guys, eventually it WILL be common knowledge on the 'dark side', it needs to be common knowledge on the 'light side' as well.
... So a core change that impacts packaging and doco can easily be a month or more. On the other hand, a 'typo' that does not impact packaging (impossible, we have to release it somehow so some 'packaging' is needed) or doco can be a few days.
The issue is 'what is a reasonable timeframe'. Someone said 3 months, someone else said 1 week, and someone said it can take a year. As we all know, 'reasonable' is a subjective term.
I think 1 week is not sufficient. I work in a small software company and I deal with large companies. A large company can't issue a memo in 1 week, it can't get from the department where you reported it to the department that needs to fix it in a week (notify development, support, QA, and 'shipping/distribution' managers and get an impact statement).
As to the one year to fix it estimate, that seems very unreasonable, especially at Internet time speeds. The 'dark side' will be well versed in the bug well before that time has passed.
Is it 1 month, 3 months, 6 months, or 9 months? It probably depends on where the bug is located. We develop a small niche market piece of middleware. A 'full QA' run (specifically test new function, regression test all other functions) can take a couple weeks even using automated test suites (runs on 10+ platforms, several hundred tests per platform, some testing is single threaded due to 'expensive hardware' resource issues, some test have to be manual). Packaging issues across 10 platforms with doco can add a couple more weeks. All assuming we know the exact coding bug and do not have to analyse the reported problem.
So if a specific coding bug is reported in a core secton of the product, it can take a couple weeks of QA, plus Dev time, plus packaging, plus documentation, plus
Consequently, I'd guess 1 month is too short as well. I'd posit that a couple of months (3?) from the time the coding level fix it identified is probably a reasonable startng point. Given some reports I've received it can take from minutes to a lifetime to narrow the reported issue to a coding level fix.
OK, I'm not a CFO but I am a CTO and I'll tell you why the CxO group likes certs. The clients require it (indirectly). First let me say, I personally do not find certs useful. They do not actually tell me that 'the guy' can do the job. I prefer the interview process to weed out the deadwood. However ...
When a contract goes out to bid and a company replies, in many cases CV's of the potential staff are required or at least requested. Bottom line, a staff with no certs and no degrees does not 'paper stack' against a company with lots of certs. Result, no contract, net result, no company over time.
So for the small company CxO, the client requirements drive the bus. Government contracts frequently require CVs unless you are 'known'. Large fortune 100 contracts frequently use CVs or corporate rep to weed out the list at first pass to the first 'short list'. So you want on the short list to get to talk to a human, have the certs.
Large companys have come to rely on the certs as the first pass weeding process. Now lot's of large consulting companies pay for certs so they have staff that passes the checklist test (feeding the cycle). Small companies do not always have the cash, they tend to hire certs (let the big boys or the employee pay) or not play in that space. The game is not likely to stop, too entrenched and the vendors are feeding the lions more certs everyday.
Just my opinion of the issue, YMMV as they say. Or put another way, "I'm a CxO, what to hell do I know about anything".
My point is that Grandma is 'sharing' pictures when she emails them. So are several other non techies that I talk to. The 'I sent Sue that picture of little Joey the other day and she loved it. If you have other pictures to share I'd be happy to send them on.' comments abound. Hell a good percentage of non techies don't know if they are using outlook or IE for email. So it REALLY depends on how the data was collected/collated.
.jpg, .mp3, .wmv, .gif, and .avi followed by lots of binary data (may be an ftp, an email, or go knows what) or did people determine lots of P2P activity existed and it MUST be media (could be bit torrents of the linux kernel).
:).
...
Did someone look for filenames ending in
As techies we ASSUME that sharing means P2P. Now in finest slashdot tradition, I have not read the article. It may well be that a definition was given, but I'm assuming that people assumed P2P
Guess I'll have to read the article when it is available, so little time so many articles
Guys, Sharing media files may not mean P2P. I hate to say it but it is possible to email a couple of meg picture of the kid/grandkid nowdays. With email like gmail/hotmail/... allowing attachments in the multimeg range, the odd photo or sound bite times a few million people can add up.
...
Think camera phone
It does if you're logging in :). If you log in, I can chain the cookies or update the current cookie you are using. Simply store the one TRUE cookie in the login context and use that cookie to 'bind' them all or to replace as necessary.
OK, I hate to defend MS but ...
You are assuming it was an invitation for a job. Perhaps it was an invitation for an interview (a different animal). Way back in the mid 80's I was phoned and offered an interview at MS. I went, I survived a few hours of question marathon, and eventually offered a job (turned it down). The original offer was for an interview, not a job. That offer was due to the fact that someone at MS had worked with me previously and thought MS might want to hire me (i.e., an internal unsolicited reference from an existing high level staffer).
Confusion can occur. May be he thought it was a job offer, but it was an interview offer. I know that in my case, I was confused and I asked a direct question before I caught the plane. "Are you offering me a job, if so what position and what salary range?", the answer was "no, you were recommend by someone at MS and we are offering you an interview". It DID seem a bit bizzare to be cold called and offered a job, so I asked questions. Perhaps, he did not and assumed?
-- If you're going to attack the CPS methodology,
... consequently given our sample data set and their return to work rate, that projects to ... So how did they get N% Y% and Z%, picked 50 guys at random and divided them up, survey data, unemployment data from the previous quarter, ...
... All may be REASONABLE methods, but one gets chosen. How often do we recalculate the 'costs'? Yearly? Quarterly?
Nope. I've learned that with anything related to statistics, you need to know the definitions and sampling to understand it.
Bottomline, in the previous post you mentioned that they sample a population group until they become employed or 'leave the labor market'. Is that die? Do they follow people for say 35 years? I doubt it, so there is PROBABLY some other 'reasonable' definition of 'leave the labor market'. As you say it is a highly reviewed report so I'm sure there is a definition of 'reasonable' that is truely reasonable. I'm NOT sure it is the same definition as that in my head at this moment.
As example questions:
If it is sampled, is it by industry and weighting applied? If so, is the weighting dynamic? Given the IT situation 5 years ago, unemployment in IT was low. Now not as low. Did the weight of a 'sampled' IT worker change? (how dynamic, quarterly or every five years) If it isn't weighted, aren't they assuming that unemployment time is industry independant (an interesting tidbit if true and something I would not have guessed).
If the weight is dynamic based on projected number of unemployed in that industry, is that number estimated based on claim data (maybe over N weeks/months/years)? Or maybe better put is, we expect that N% of the unemployed are from the auto manufact industry, Y% from IT, Z% from fast food,
All interesting tidbits used to understand the report. I'm NOT claiming the report is wrong. I AM claiming that without the definitions and methods it can not be completely understood (need context).
The obvious example, a large city has a dispatcher a small city wants to make us of that dispatcher for a fee. Last year the large city paid $150,000 for dispatch, how much should the small city pay? The large city says $60,000 because that's what they calculated. The first question out of most people's mouth is, how did you calculate it?
Should the dispatch rate be calculated on number of calls (us vs. them last year), a 50/50 split of the salary of the dispatcher, a 50/50 split of the time and equipment costs, a split of the time, equipment, and building costs,
Questions about the method ALWAYS occur during contract talks or money talks so people understand the deal. Questions like that SHOULD occur when people see statistics so people understand the 'deal'. If unemployment is up 22% this quarter but it is basically in the 'foo' market but I work in the 'bar' market, do I care? Probably not. But if the number is presented as unemployment is up 22% this quarter (without definition or clarification) I COULD get nervous. If I understand the number, I KNOW whether to get nervous. I.e., 22% without more information is interesting, but insufficient to truly understand the unemployment situation.
Hopefully this long winded post clarifys why I asked, I wanted context.
-- You aren't serious, are you? You seem to be.
Quasi serious, I wasn't sure how they did it. I WAS sure they didn't track EVERYONE. Obviously it was either the quick, stupid, method (check claims) or some sort of statistical method.
I assumed someone on slashdot would fail to restrain themselves and I'd be come enlightened, cheaply. (Thanks!)
Now, you do not happen to know the gory details of the statistical sampling methods used, do you? Like Mr Clemmons said, "lies, damn lies, and statistics".
Nice dictionary definition.
Now how are they REALLY counted. If you are on unemployment and you go to the office every week or file the paperwork every week to get your check, you are easy to count. If your benefits run out and you stop filing the paperwork, what happens? Does someone call you every week/month to see if you finally got a job (yeah, right)? Do they just assume you will never get a job and you are counted for life (yeah, right)?
So while that is the official definition, how does it REALLY work? Is the bureaucratic definition, "those that filed paperwork"?
As the guy in SE Asia recently found out, very easy. He had a car that would not start without his fingerprint. The carjackers whacked his wrist with a machette, car starts fine. It turns out that in SE Asia (at least that part), his car was worth more to the carjackers than the trouble of hacking off his hand.
Bottomline, biometrics are good if what you are protecting is worth more than the human (launch codes), not so good for something cheap. Faced with "give up that candy bar or we'll hack off your hand and take it", I'd rather they take the candy bar.
Just because you CAN protect something with biometrics, doesn't mean you should.
It's harder to loan/tell someone your fingerprint.
The bottomline line issue is: does the library intend to require id to use the computers. If yes, then the privacy veil has already been pierced whether a swipe card, barcode, or a fingerprint hash is used.
Since the fingerprint is not stored but hashed and the hash is stored, the fingerprint vs. the 'id card' is not (in my opinion) worse. Privacy is lost either way and no additional REAL data is given up.
Whether the library SHOULD require ID, is the question. Given federal/state funding requirements and laws like CIPA and the Patriot Act, it is more complex than it appears on the surface.
Simple, they promise to read it twice this time :).
How about "plugs into a single 110 volt US outlet". This thing draws 1500 watts PEAK. That's about 14 amps for the math challenged or well under the recommended max for a 20-amp circuit from your household panel (think coffee maker on steroids). Let's try your barebones system approach and let's say you tweak it to use 50 watts per system (good luck). That's 50 watts per system multiplied by roughly 100 systems => 5Kwatts or 3+ times the power consumption. PLUS as an added bonus you get 96 cases, external cabling, at least 96 fans, a dozen power strips, and assorted other toys to trip over. Oh yeah and a few weeks of setup, integration, burn in, and testing.
It appears that you have a social issue (don't care) and not a technical/education issue (can't figure out how to get/install/update the antivirus). Most technical answers really do not work in that environment.
...), or use peer pressure. It appears from your comments you have tried education and have difficultly with banishment, so you have to try other social fixes. How about a PUBLIC weekly/monthly list of the top ten lusers causing a slow/bad network environment. You hog bandwidth (virus, spam, trojans, excessive bittorrent,...) or cause your neighbors pain (virus, hacking, ...) you make the list. You want off the list, fix the issue and have it stay fixed for a week/month.
The best technical response to the social issue is usually REALLY an attempt at a social response. I'll talk to you (education), disconnect you (isolation, banishment,
Note: this can create a different issue, those interested in 15 minutes of fame regardless of cost. Without a plan to handle that occurance (banishment is the usual), you risk trading the current issue for a different issue.
An additional technical mechnism is to install a bandwidth management mechanism. If you make the list you get your allowed bandwidth reduced by X% for each week/time you are on the list. Screw up lose 20% of the allowed bandwidth, don't fix it, lose another 20%. After about a month of being on the list, you are down to zero. You stay at zero until the issue is fixed, and then move to say 60% until it stays fixed for X period of time (or it gets reduced again). This is somewhat of a progressive banishment solution which may or may not work in your environment.
Bottomline, you need to pass on the pain to the people that deserve it. Technical solutions do not do that, social ones do. The only technical response to your problem is to find a technical mechnism to enforce a social solution.
Hey, I never claimed he was wrong. I'll try one more time. Let's start with RMS can start what ever movement he wants with what ever rules he wants. I'll even grant that his ethics won't change over time and that it will always be about ethics for him.
Let's continue with business is free to ignore him. So let's posit why is Free software popular with business, did the movement catch on in the business world? (A frequent argument I hear, even businesses like IBM/NOVELL/HP/SUN/... are 'seeing the light'.)
My answer, NO! Business doesn't care about the movement. Anyone that thinks that business use of Free software is a win for the ethics of free software, is reading the situation wrong (IMO). Business cares about TCO, you know the whole Capitalism == Profit thing. Confusing the growth of Linux in the Business world (and likely the rest of the world) with the ethics of the free software movement is blowing sunshine where it doesn't belong.
And for the record I'm fully aware of the difference between Free and Open source, I've contributed to both and I read software licenses about every week as part of my job. My point was and still is, that Business doesn't differentiate, even though Mr. Stallman would like it if they did.
Assuming the distinction is an integral part of the 'market success' of Linux or Free Software is a mistake waiting to happen. Hence the concern over what was changing in GPL 3, would it force people off Linux and on to BSD?
Stallman is not stupid. He appears to understand the issue, change is coming in small increments. Much like Microsoft he appears to know his market space. His movement can target the users of Free Software while the license maintains the monopoly on code use to keep Microsoft and others from competing cheaply. The business users of GNU/Linux as a platform do not care about the license, it works, has low TCO, and has good support. Free software 'product' has low development cost (close to free, due to volunteer labor) and high barrier to competition (Microsoft does not have 'free' labor). Its competitors are locked out from 'standing on its shoulders' much as Microsoft's competitors are locked out from standing on MS' shoulders. The code model (GPL license from a competition standpoint ONLY) is very proprietary, what is owned by MS can not be used by its competitors to compete against MS and what is 'owned' by the Free software movement can not be used by its proprietary oriented competitors to compete against it. As has been said many times, really quite brilliant.
The LGPL license is a bit more flexible, Companies and people can use LGPL code to compete against Free Software (in a different market space) in a for profit mode. If the 'for profit' guys can do a better job to be worth the price difference, they fairly win profit, if they can't then they lose their investment. Any changes a company makes to the LGPL portion of the code must be given back to the community so the community can compete fairly. A quasi even playing field where both parties get the same leg up, the common LGPL code. (OK, Free Software has the leg up over the long term, incredibly low development cost. The 'for profit' group has the leg up in the short term, toss money at it, reduce time to market, hope you make the money back.)
From an end user perspective, this is good. Common code gets enhanced by both and competition occurs on a quasi even field for the customer mindshare with Free Software potentially getting the long term cheap labor advantage. The more code (as a percent of product) that is LGPL the lower the burden to market entry and likely a lower price of proprietary software (giving an advantage to Free Software with its lower cost structure).
I understand that this is not essential to RMS, as he (to a large extent) doesn't really believe that proprietary software should exist. It may however, help in small markets where Free hasn't penetrated or even in large markets where a high quality profit oriented pro
Actually if you note my post I used F/OSS in response to the post about Free Software. My terminology is fine, my clarity is not.
...).
:-) and the company will produce software for the fastest moving train (currently Linux) to make profit. In talking to others in the industry, they seem to feel the same, they just don't say it in public.
My point is that, in general, business doesn't care if it is Free or Open software. To be REALLY clear, they really do not care about the ethics, they care about either the market or the TCO. If they are hyping Free software it is likely because they sell service in that market to make money. If they are not hyping it but are using it, it is likely an effort to reduce TCO. So Free software is hot in the business world right now more because of free as in beer (TCO) than free as in freedom (ethics). The freedom part is useful because it reduces TCO (pretrained staff, available patches, free GOOD web support, reasonable distribution portability,
When people start to move to the 'ethics is king' side of the road they occaisionally need a reminder that it is not the only motivating factor in the use of Free software. Sure, it is RMS' motivation.
However, to some extent GPL software is not truly free as in freedom. There is a second class citizen, business. From a true free software for EVERYONE, PD or LGPL is a better choice. The LGPL allows the author to get enhancements and maintain GPL like control over his pieces but allows everyone to use it how they see fit (even for profit which is a motivator for some to apply their talent).
Personally and professionally it doesn't matter which F/OSS infrastructure I use. I'll use the one that makes sense to run my network (Linux, BSD, even FreeDOS
-------
... with easy to find staff (that increase the internal hype) can really reduce the network infrastructure TCO.
...
Free Software is not Open Source. Ethics is the whole point behind Free Software. Rarely does a moderate stance drive change.
-------
With respect, ethics may be YOUR whole point behind free software but it is not everyone's point. As a CTO for a small company there are several corporate reasons I use 'free software', honestly most boil down to cost and support.
Linux in a corporate environment is about both free as in beer and free as in choice to switch. BUT both are really a TCO issue. The free to switch or modify is about reducing risk or cost, not about having more toys or supporting an ethic.
My boss doesn't care about the freedom ethics of F/OSS. He cares about his bottomline (that IS his job) and the freedom ethics of F/OSS are a means to an end. The corporate advantage of freedom in F/OSS is about the availability of patches, the replacement of developers, and the long term availability of inexpensive product.
IBM/Novell/HP/? doesn't support Linux because it is cool, they don't support it because of free as in freedom. They support it because they can make money that way. It adds billions per year to their bottomline. If Linux dies off tomorrow and BSD is the new drug of choice, they will support that and my corporate infrastructure will run on that (in fact it did, before Linux). They go where the customer goes, that's where the money is.
What is driving change on the corporate level is the low TCO, good support, and the hype reaching senior management. BSD has low TCO, not as good a support structure (but still good) and significantly less hype. Small companies have used it for years before Linux and some still use it today. The hype reaching management and the availability of 'linux trained staff' in droves off the street (compared to BSD) is Linux's major leg up in the corporate network infrastructure game. Easy to get/use mail server stuff, www server stuff, DNS, anti-virus, anti-spam, file/print share, networking,
Now this is stated by someone that has given away free (as in beer and freedom) software since the early 1980s (waaay pre GPL, I did it public domain:). I like Linux, I've used Linux since about the 0.93(?) kernel. I like the concept of free (freedom) software, always have, that's why I've released tools PD years ago (sadly I push paper not bits now). But my job isn't about what I like, it is about doing my bit to improve profit and reduce costs. As it is in most corporations I've ever worked at. Linux does that, that's the reason to implement it in a corporation.
Oh, well. Mark it off topic and let's move on
Mine, they're geeks. But hey they come by it honestly enough. :)
------------------
Nearly all popular linux distributions now come on more than one CD (even if you ignore the source code) and the default installations are WAY bigger than that of Windows XP.
------------------
Gee, don't do much do you. My windows install comes on a crate load of CDs, first one is Win 2000, then several for Visual Studio, then a couple more for Photoshop, then several more for MS Office and finally several more for MS SQL. I think I have about 10-15 CDs for my Windows install.
Oh yeah, my Linux desktop does all that (and more) from I think about 4 CDs (haven't counted recently).
Oh, and as far a space goes, I have a Linux server (old terminal server software) booting from a floppy. I think my total disk requirement is 1.3MB and it runs in 32MB of RAM (I had it so I used it, probably could use less). While I seem to remember Win 3.1 running is less than 32 MB of RAM, I don't think it could boot from floppy.
Methinks you missed the point, you can have it ALL or you can take almost NOTHING. How it is packaged is only marketing. Now admittedly Granny cares about marketing and ease of use more than I do (and Linux can learn from Windows there). But Linux CAN be both smaller and provide more functionality per dollar than Windows, depending on your needs and expertise.
Well, hopefully it is done in true clean room style then no one gets sued. Second, they can find Jon, they do not know about 'me'. And third, I haven't produced the software, I do not distribute the software, and sueing me doesn't stop distribution.
Remember, my 'crime' is accessing them with illegal software, which usually means I lose my account (NB: I have NOT read the actual Apple agreement, comment is based on knowledge of other agreements). Loss of account is not a big stick. Issues may or may not exist with 'circumventing DRM' but probably do not if I live in Norway. It's all about where you live and what you did not JUST what you did.
NB: If DRM is added by the client and I document the protocol to the server as a spec, I did not circumvent DRM as I didn't build anything or remove DRM from a protocol or file. I simply looked at a point where DRM did not exist (yeah, angels and heads of pins). I did not build anything that copied copyrighted material. I AM probably in violation of the agreement and that WOULD lead to cancelation of my account. I'm not sure if anything worse is apt to stick.
Ahh, NO. Someone may have to connect but it does not have to be him.
Let's say I connect to iTunes with Apple's software and I pay for stuff as a normal user. While I'm doing it, I capture network traffic logs, debugger output, etc. Then I write a spec and hand it to Jon. He writes the code and hands it back. I run his stuff and the 'real' stuff and issue change requests. He implements the change requests and we iterate. His hands are clean (mine may be dirty but his are clean). He never connected to iTunes.
Or, I could reverse engineer it, build the server (as you mention) and let Jon code against my server.
The whole clean room reverse engineering methodology is more complex but similar in intent to this (you'd REALLY like both sets of hands to be clean).
OK, slightly different things but not as different (IMO) as you think. MS claims forks are bad. You seem to claim they are not really bad in practice (disagree, sort of). Forks can be bad for several reasons retraining, rework, for lack of a better term fork cascades, market confusion, momentum stalls, and probably several I missed.
...).
...) but in general the MS stuff maintains good backward compatibility. I just fired up an ancient app that used OLE and it still worked, not always true with OSS stuff (usual 'HELP!' response, why aren't you running the latest stuff, that's WAY too old).
Retraining falls into a couple of buckets: user UI retraining, developer API retraining, and testing/packaging/distribution retraining.
Rework occurs when a fork occurs in a 'base product' like X, and the existing API changes over time (more likely as new owners make their mark as opposed to old owners maintain direction) and I need to recode my app to the new API.
Fork cascades occur when there is no clear winner in an area. This can occur whether the base product was forked (XFree, XOrg) or whether 2 different base products fill the same niche (Gnome, KDE). Other development projects that rely on that base product/niche as a requirement now have to fork to support multiple niche filling parties. Hence my example about forking an internal dev tree to support both Gnome and KDE.
Yes as a niche gets several competing players, different toolkits arrive on the scene to help bridge the pain gap, but they all introduce compromises (look and feel, performance,
So the strength of OSS, important dead/dying projects get revived, can become the weakness of OSS, no clear standard. All because any Yahoo can pick up a set of source and create 'his/her' version. Now not any idiot (OK, stop with the exceptional idiot jokes) can get their vision to be a real competing player in a niche so there is some self limiting involved. However, when true competing projects do arrive on the scene, they can make developer hell a reality. This saps effort, confuses the market, and stalls momentum in that area. How many, "I'm building an app, should I use Gnome or KDE" or "Should I code directly to KDE or use QT for portability " messages have you seen? If they'd just code the damn thing it would be at market already and the resource could free up to improve it or do another needed project. But they can't, coding for both is too big, using a toolkit is a research project in trade offs, and ultimately they are as confused as the rest of the market.
So you are correct, XOrg replacing XFree is a good thing. The old project effectively dies and life move on with little long term confusion or impact.
However, MS is correct, Gnome/KDE/QT/the next big thing is stalling desktop momentum and no one can say that what they pick today is the correct choice. No one has a road map to provide developers with a long term strategy for development. One could argue that the MS road map changes, (DDE, OLE, OLE2, COM, COM2,
Oh well, just my 2 cents.