has some neat bookmarklets, one of which removes redirects. I don't use it all the time, because some sites depend on the ad revenue. But if the site abuses redirects, I have it as an option.
> The mistake of equating all open source technology with Linux was "really very early on," > Paoli says. "That was really a long time ago," he says. "We understand our mistake."
So... Microsoft's new tune is "We Love Open Source...Except GPL Licensed Open Source"
> Microsoft hasn't... rescinded its declaration that Linux violates its patents... > [Microsoft's] earlier battle stance was a mistake. Microsoft wants the world to > understand, whatever its issues with Linux, it no longer has any gripe toward open source.
Except GPL Licensed Open Source
> Microsoft has released some technology under its own open source license (the > "Microsoft Public License"), such as IronRuby, which integrates.Net code with > the Ruby programming language.
"Signs are pointing to Microsoft backing away from IronRuby..."
ZDNet, "What's next for Microsoft's IronRuby?" by Mary Jo Foley
From the article: 'According to a now former IronRuby developer, Jimmy Schementi, Microsoft has just one developer left on that project (who is committed to it half-time). Schementi recently quit Microsoft when his manager asked him "what else would you want to work on other than Ruby," he blogged.'
Summary: Microsoft says "We Love Open Source..."
- except Linux...well, any GPL Licensing, really
- and we still maintain they violate MS patents...a bunch of em.
Really, you can take our word for it
- and we'll still extort license fees under threat of enforcing these
patents we refuse to enumerate
- and we love open standards and open technologies, and want to
work with them...as long as we can make a proprietary DotNet version...
And Microsoft will stand by its commitment to open source, unless its absolutely convenient.
Contact vendor and a reputable third party, such as CERT, simultaneously.
Give vendor a -very- small window (at -most- a week or so) to respond, with (1) contact information; (2) an assigned issue identifier (at least one while triaging), and (3) a specific time frame till a follow-up response, not to exceed N days (your choice; 14, 30, 60, 90, etc.). This response does not need to be a full triage and verification, just a real response of "we assigned this to John Doe to research as issue number 54321-unverified", rather than an automated "Thank you for your email..." BS response.
If the vendor blows off responding to this, contact one time requesting the information within a short time frame, informing the vendor of your intent to go public if they do not respond. If they fail to respond, release the information on the exploit, along with any known workarounds.
If the vendor responds with contact, information, etc., give them a time frame of N days (your choice) for analysis and wait for follow up until the time frame of N days specified earlier. If they fail to respond, see above. Again, this does not need to be the fix, just "we confirmed the issue and have determined this is a priority X issue. We are assigning it to Richard Roe to be addressed in a patch/scheduled update/major service pack/next version of product"
After the vendor has performed this initial assessment, give them a fixed, fairly aggressive period to respond with a fix, patch, or workaround, and hold them to the date as above. It's up to you to decide how long to give the vendor before you release the information. If their estimate is too long or inadequate (next version of the product, 18 months from now; will require all new hardware and tens of thousands of dollars), then give them a shorter time frame for a patch or workaround, and inform them that you will hold them to it.
Then hold them to it.
My biases: I believe vendors almost always take much too long. The goal is not to give them a comfortable time frame to respond or fix the issue, but -enough- time. If it's comfortable, it's too long.
Security flaws are unacceptable. If the vendor can't fix it, they must provide a workaround. If they can't provide a workaround, people need to be informed so they can stop using the vulnerable product or feature.
A lot of times you can just disable the feature rather than the entire product.
But people can't do that if they don't know it's broken.
> If a patent is overturned in court, you pay a statutory $10,000 fine, plus the > legal fees of the person who sues you.
I'd adjust that to reduce litigation. If the patent is overturned in court, I'd add an additional penalty for the time between the initial suit and the time it's resolved. The additional penalties can be waived if the patent is retracted unconditionally, and the matter is settled out of court. No out of court settlement would allow waiver of the burden of legal fees, no out of court settlements allowed without retracting the patent unconditionally.
> If you are found to have filed the patent in bad faith (i.e. knowing > that there was prior art) then this becomes willful abuse of the patent > system and the fine goes up to $100,000.
And an additional payment to the person who filed the suit.
> If a patent is found to be invalid, you must refund all license fees > collected on it, plus 50%. This is a statutory penalty and may not be > disclaimed by contract.
Agreed if found to be a bad faith patent. Limit to the license fees themselves for invalid patents filed in good faith.
> Anyone has standing to sue for an invalid patent, but the loser > pays the legal fees of both parties.
Needs work. Big companies would benefit from this, in that they would be encouraged to abuse the system with counter-suits, delaying tactics, etc. Effectively, people suing the big guys would need to have all of the following:
- absolute certainty they are right
- massive amounts of time to devote to this case (decades)
- and massive funds in reserve.
For both the above, a recent twit tv floss program discussed the real story of how ugly and expensive some of these fights can be. And it would be _much_ worse if you were involved in a suit with a big company with very deep pockets.
That's why people settle. The legal system is too expensive for the common man.
> Companies have a one-year amnesty after these rules are introduced > to retract patents that they discover to be invalid as a result of > internal auditing. No fines are incurred for patents that are > disowned during this period.
Why limit it to one year? Unlimited amnesty, but after one year, an upward sliding scale of the percentage of licensing fees that need to be returned. Encourage them to audit soon to avoid repaying years of licensing fees.
I worked on a couple of different teams for one company, in different office situations.
In one, 8 of us were in one common room, and we worked well together. Originally, we were all facing the walls, but we all agreed and moved the desks so we were facing one another. It was great; close group, close spacing, got along, worked well together.
Later, in the same company, in a different group, just three of us in a larger room. One of the guys snagged a conference room for a week just to get some work done. One member of our group was a "social butterfly." Loud conversations, all day long. Impossible to concentrate. Very limited knowledge of technology, always undoing the good work done by others.
I work now with some folks who are productive later in the day; in the morning they socialize, loudly. I work best early. It's unbelievably difficult to concentrate sometimes. Sometimes people need closeness, other times they need space. Particularly if work and personal styles don't mesh.
It's not the "most productive arrangement" that matters. It's the most productive team. What's best for the individuals that make up your group? Talk to -them-.
>...the idea of federal standards for driving certification kind of appeals to me.
I assume you mean "good" standard for driving certification.
Unfortunately, good standards are no more likely on the Federal level than they are on the state level. A number of the biggest problem cases are political hot potatoes, such as driver age (both too young and too old), and the fact that outside of a relatively few large cities with good public transportation systems, getting around without a car is nearly impossible.
I know a number of people who, for physical reasons can't drive or walk long distances, and who find it enormously difficult to get to medical appointments and take care of grocery shopping. There is -no- public transportation alternative for them.
That problem was made the loss of small retailers and corner markets, replaced by big box stores and supermarkets, and the replacement of the small office general practitioner with the "medical group".
Politicians who want to get reelected are not going to put more people in this kind of a position.
Application from hell. Client was almost ready to accept delivery of an application from another firm. Application was to distribute procedure documents created by central office.
Client forgot to develop and application to generate the procedure documents.
We had to slap together a tool to do this in less than 1/100 the time used to design the original application.
Did I mention it needed to support rich text, linked documents incremental translation and editing for the overseas offices?
Duct taped together several programs (Word, Access, Excel, others), users had to follow instructions and prompts. But, users don't -read- instructions or prompts.
One guy on my team wrote a custom messagebox. Anywhere any code called Windows MessageBox, it logged to a flat file:
- the calling function and context
- the exact title of the message
- the exact text of the message body
- the exact selection the user made
Tech support could view the flat file, read backwards, and see exactly what the user did, then walk them through doing it correctly.
What's tight at these locations is compliance auditing more than security.
In many environments, these compliance requirements have the force of law, and it can be a long up-hill battles to change a poor, "hack" compliance regulation, such as "Use Internet Explorer 6 with these settings and patches", to an effective one (use a browser that supports the following security...).
Since the ostensible purpose of compliance is security, many people mix the two concepts.
All excellent examples. Some of the things that help these events work:
- variety. I can't drink or have donuts or pastries for health reasons, but I love to cook chili, or chicken wings, or something hearty for lunch. other people have different health, cultural, or religious restrictions.
- self-sponsored. volunteer organizers, keep it simple and light. too many companies that do "events" over-control them; timed to the minute, checklisted, get in the queue, march in time.
- contests. some folks had a clever idea where I'm working; everyone picked an innocuous secret about themselves, and everyone had to guess who, in another department, had which secret. it gave people the chance to talk socially, rather than about work.
- time and consideration. too many companies that do "events" fail to leave time to socialize. especially with support staff, arrange to cover for them while they join in. push back meetings to another day, lighten up on "get this done by the end of the day" B.S. tasks. give people a chance to enjoy the event without worrying about the pile of stuff on their desks.
> The God question is sort of like dividing by zero in math. The result isn't 0, it is undefined, > or sometimes referred to as "not a number", and sometimes referred to as infinity. > It definitely exists, and can even be useful in certain applications, depending on how you > treat it, but what it means is impossible to determine.
> Only the Agnostics take a logical stance when it comes to god, and simply state "I dunno" > and go on with their lives.
Nitpick: logical, if you _believe_ that the failure to choose is a safe, neutral option.
"Would you like carrots or broccoli with your meal?"
"I dunno."
Is a neutral option choice.
"Here comes a truck heading straight for me! Should I dodge left or dodge right?"
"I dunno."
SPLAT!
Is a case where failing to choose is a choice, with consequences.
Imagine you're in Germany in the 1930s. Someone asks what your opinion is of these brown-shirted guys and their leader, Adolph somebody, with the Charlie Chaplin mustache.
"I dunno" is fine; but history shows that trying to learn what these guys are all about would be much safer than just moving on with your life in blissful ignorance.
Is it enough to say "I dunno" and move on, or do you need to proceed to "I'll take time to study, so I can make a decision."
> I'm also careful not to commit the fallicist's fallacy - that is, just because an argument > is fallacious does not mean the conclusion itself is false
Or phrased differently, lack or scientific proof for or against an assertion/theory/belief doesn't make it untrue, just unproven/unprovable.
>> Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.
> I have to disagree, here. I've banked with several different credit unions, a couple of small > banks, and three or four large banks over the past several decades. I've never had an EFT go > missing. Besides, if the problem was as widespread as you believe our entire e-commerce > marketplace would have never taken off. Amazon seems to be doing quite well.:)
Fair comment, but I must point out a few things:
- I didn't say the EFTs went missing; they weren't completed or cancelled. The bank knew where they went; they just couldn't resolve it in any reasonable time frame.
- I didn't say debit cards there. That specific comment was EFTs. Online banking payments in place of checks. Debit cards work very well, and I use them online at several places. But the legal protections aren't there. The banks have largely implemented good policies for handling debit card issues. But in case of an error, there is no legal protection. And banks often don't offer any of the same protection policies for online direct bank payments.
- I didn't say it was widespread, just commonplace. It happens to a lot of people; percentagewise not often. But with the number of people using them, even a tiny percentage adds up quickly. They are probably significantly -less- frequent than check errors. But check errors are governed by law. Consumer EFTs not so much.
Check the Risks Digest and Consumerist.com, as well as a number of mainstream news sites. If happens, and when it happens, it's often very bad.
> I will concede, though, that person to person EFT capabilities have been FAR too slow to emerge.
Not just consumer to consumer; they are often -very- unfriendly to small businesses. I've worked for many firms that don't offer direct deposit, not because they don't want to, but because of the horribly obstructionist bank policies.
>> not all customers have access to electronic funds transfer.
> That's your problem, right there. Fix it.
It's a problem, but not the only problem in the US.
> The capability for electronic funds transfer should be automatically granted with any bank > account - both via debit card and via internet. In the Nordic countries, cheques are > essentially extinct.
Most other nations have different financial protections on EFTs than here in the US.
One root cause of this is that the banking system in the US grew from state-chartered banks, not federally-chartered banks. 50 states, all with different rules and regulations.
Much of the current legal and technological infrastructure to begin to _consider_ phasing out checks in the US was only put into place post-911. At that time, the federal government was confronted with the fact that they had been nursemaiding a check clearing system leftover from the early 20th century, and even a brief interruption of airline service significantly impeded the ability to move huge boxes of paper checks across long distances quickly.
The legal overview still isn't as good as it needs to be. People in the US are still advised by security and financial planners to use _credit_ not _debit_ cards, because the protections against errors and fraud are "bank policy" which can change in an instant, not "the law".
Correcting an issue with bank errors in clearing a check required banks to put the funds back in place and follow a real procedure for resolving the issue quickly.
With EFTs/Debit cards, banks are typically _very_ slow to restore the funds, and often glacially slow (and incompetent) at resolving the issues.
Personal experience: I've set up EFTs for recurring bills at various times in the past. In each case, the bank was unable to complete some transfers, unable to cancel the transfer, unable to resolve the issue quickly, and I was charged for late payments. Some of these took several _months_ to resolve.
> The only cheques deposited are invariably from countries with backward retail banking (UK, US, Canada, etc.)
As noted by another poster, it isn't all retail. In fact, it likely isn't even _mostly_ retail that deals with checks. Small service industries: appliance repair, contracting/home remodeling, charities and non-profits, small-business suppliers and wholesalers, shippers and transport firms, any companies dealing with Asian, South American, or former Soviet-block nations need to deal in checks all day, every day. Or lose the bulk of the business they do.
> electronic transfer to or from other accounts (worldwide) is fast and cheap, > and provides immediate confirmation of receipt of the payment.
Not in the US, and the banks are shielded from the need to confirm _by law_. I'm also curious about the claim that it's fast and cheap (reliable implied) worldwide. I mentioned several regions above where checks are still common. I have no doubt that fast, cheap and reliable EFTs are available in all those regions. But are they reliable to all businesses in those areas? Sure, if you are dealing with a big Asian electronics, metals or chemicals supplier, I'm sure it's no problem. What about the small-lot specialty suppliers; do they have the same fast EFT access, with reliable transfers protected by law? I'm not so sure.
> There is no risk of "delayed/lost in the mail" as happens to cheques with remarkable frequency.
Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.
> On-the-spot payments (small stores and large, petrol stations, vending machines, > parking meters, etc.) are made using the debit card for the account.
Mostly true in the US; some things (parking meters) are not usually equipped for debit cards. In part, this is due to the fact that there are more parking meters in some major US cities than there are _people_ in some of the Nordic countries you mentioned. Since ownership and management of t
> AFAIK French legal system doesn't use this "precedence" the same way you USAers do.
You're probably correct. France's legal system is quite different from that in (most of) the USA. Louisiana still uses a lot of the French legal systems it had in place when it was a French territory.
But IIRC, the typical US legal precedent usage isn't specific to the US, but is based in the British Common Law, which is the legal system in many nations which were formerly British territories.
> Visual Studio, specifically VC++6, rocked in the days of writing Windows apps. >...the editor itself was just awesome. It was solid, never crashed...and was > fast fast fast. >...Later versions, though, got seriously sluggish, and yes, ultimately it's > just a glorified text editor, so why are all these windows sliding in and out > at odd times, they rearranged all the project settings...Plus everything up to > VS2008 has just been slow for me...from constant annoyingly-slow to > wait-did-it-freeze-up-on-me-oh-no-it-just-came-back slow. Plus I've been > able to crash pretty easily all of them...It's just that painful.
Hear, hear. Same pain on my end.
Especially with SSIS; redrawing the pretty little boxes seems to suck up all the processing power, and bring any other MS tools, like instances of SQL Workbench, to a halt.
Add to it the fact that, while the tools allow you to build project using msbuild and useful tools, the defaults are still exactly wrong. I work with a couple of teams at work who regularly have deployments to our production servers bomb, and they can't back out, because setting up the msbuild scripts and properly versioning the right files isn't the default.
It requires you to override the tools and do it manually. The pointers and clickers don't know how to do that and don't want to learn. So where I have Rakefiles (I was using ms-build, hoping to get others to use a decent tool by choosing one from MS. After fighting for months, I said screw it and just started using rake), they have 40 page manual checklists and tons of committee meetings to prevent errors -- and they still fail as often as not, and they never know what changed.
My Rakefiles track changes and version numbers, and I can back stuff out when needed (which isn't often).
Good to hear that 2010 seems to be better; but around here, that means we'll probably start using it in about 2025...
Quick disclaimer: I don't use TFS, and don't care for integrated solutions - not just MS, but any of them.
>...using TFS was the first time I realized how much an integrated source control, team collaboration > site, project management integrated solution makes sense.
In some scenarios. I know any number of companies where the MS integrated solution you use would fail utterly to be useful, because the people would not use the tools properly. Not just developers, but project managers, users, etc.
The *nix/open source advocates generally don't favor all-in-one packaged systems. The vast majority of the time, the system has specific, glaring deficiencies, While it often works well for a specific group, it fails to support others adequately.
This condemnation has been levied against Eclipse regularly, and from personal experience, I can tell you that the Visual Studio IDE alone, while it is absolutely adored by many, is in many ways a useless tinkertoy for others. MS (and other all-in-one solution providers) don't provide the perfect experience. They target a specific group, and often their "solutions" actively undercut the work of others. Some specifics:
> * Integrated work items with specialized and extensible work item types for tasks, bugs, issues etc.
Working with a system now at one assignment that is remarkably poor. It works beautifully...for on-call help desk support. It actively -impedes- tracking of bugs and tasks for development. I actually use a full external tool and update the approved system at the end. This is awfully inefficient: only 10 times more productive than trying to use the approved tool.
> * Work items, tasks, issues etc. editable through a web interface, but also right from inside the IDE.
That's handy - if everyone uses it. Where I'm on assignment, no one can be bothered to update information. I track things in my a web-enabled system, as I said. Several times a week, someone asks me to print out information in that system. It's become the system of record for a lot of this information, and anyone can use it; but I'm the only one who does. Everyone else's data is in little silos.
> * Work items, tasks, issues etc. editable through Excel or some other spreadsheet (regrettably project > managers favorite tool is *still* Excel - but having it integrated so the rest of us don't have to > mock around inside columns and rows to update status is a big relief).
Again, handy -- if anyone uses it. Not so handy when people actively break it by mucking around with the Excel sheets.
Just kill Excel use.
> * Source control without quirks when e.g. renaming files or removing files and adding files back with the > same names (I've had bad experience with subversion)
Others have complained about similar issues, but they aren't universal. Chances are you're not managing the files properly in subversion. But subversion isn't the be-all and the end-all of open source revision control. It was never intended to be, just a better CVS.
Git is very nice, and there are -many- others to look at. Check Wikipedia.
> * Shelving - storage of not-completed changes on the server without checking in. We use it to share > suggestions and if we cannot make the daily deadline on consistent check-ins.
Never used it. Frankly sounds like a hack; why not use a branch?
> * Configurable policy which can be set to reject commits/check-ins if a build has not been completed > locally and/or if too many tests fails and/or if test coverage is too low and/or if there are too > many/certain warnings (e.g. security related).
> * Dashboard with project manager-friendly roll-ups and graphs with speed, test coverage, test > completions, tasks, status etc.
Tons of options and tools. Again, not an "integrated" one I can recommend, as I don't care for integrated.
> * Branching based on metadata - not on actual directory copying and separat
> If this is a GPL violation, I'm sure it wasn't deliberate by Microsoft. > People around here no doubt think differently.
Yes and no.
> I'd be interested to know what processes they have in place...in theory, > something like this would be a...break-down in the process.
Microsoft doesn't have a great history with "process", of whatever sort, being followed by all business units. This is true with security, and using "other people's code", not specifically open source.
They don't seem to be that organized. I suspect if this is a true GPL violation, this isn't part of a grand evil genius conspiracy. But it's quite possible, in my opinion, that someone lifted this and that there really isn't much in the way of controls on this. Rules, sure; but no real process to ensure it happens.
I'm not saying, "Linux Rules, Microsoft Drools!" Just that MS, among commercial software companies, focuses on marketing aggressively, not process control.
>...cable modem contracts [assume] that your bandwidth is shared... You can burst up to the > advertised rate, but you are never guaranteed to get it 100% of the time.
The offensive part of this is not that there is no guarantee of availability, but that there is a guarantee that it will -not- be available for more than 15 minute increments.
> You get throttled *only* if the network is congested...
That's not what I saw in the summary. The summary states that you will be throttled if the network becomes congested -or- if you use more than 70% for 15 minutes. I would agree that throttling if the network becomes congested is reasonable, and scaling back the peak users at those times is the obvious measure.
But the "70% for 15 minutes" cap, when there is no congestion seems to be unsupportable. I can imagine thousands of legitimate scenarios where home users would use 70% plus for longer than 15 minute increments; not 24/7, but for longer periods than 15 minutes. If no other users are competing for the bandwidth, what is the justification for throttling?
> "The outage was caused by a system failure that created data loss in the core database and the back up," > [Microsoft Corporate Vice President Roz Ho] wrote in an open letter to customers.
It sounds like their "backup" was a replica on another connected server.
No actual offline backups at all.
When JournalSpace was destroyed, one SlashDot thread was "Why Mirroring Is Not a Backup Solution".
My favorite comment was by JoelKatz:
>> The whole point of a backup is that it is *stable*. Neither copy is stable, so there is no >> "backup on the hardware level". There are two active systems. >> >> If you cannot restore an accidentally-deleted file from it, it's not a backup. >>... if the active copy of the data is corrupted, there is no backup.
> Dude, a.reg file *is* a script. There's no difference between double-clicking on FIXSOUND.REG > and double-clicking on sndfix.sh.
Except sndfix.sh (oir any shell script) can have conditional and branching logic, and verify the current configuration settings.
A reg file can't do that; it is always "erase and replace, no questions asked."
That's why more Windows admins are using PowerShell every day.
> My big complaint with the registry is that it's too convoluted. Config files are typically > either in the user's home directory, the program's working directory or its installation > directory. Registry entries could be buried under something like HKEY_LOCAL_MACHINE/SYSTEM/ > CurrentControlSet/Control/Class/{4DE36972-E325-CE11-CBFC-86753094BABE} -- how the hell > am I supposed to remember that? (Assuming I could even find that in the first place!)
>>The only thing that seems strange is the cost disparity.
>>.NET apps are usually much cheaper to develop...
I'm not sure of that reasoning. Based on my personal experiences, I would agree that.NET applications are quick to get to the "80% done" phase. "Are you finished?" "80% done, boss!"
The problem is that often that represents 20% of the total cost, and the remaining
effort to get to completion is almost all cost overrun.
It starts off as a largely wizard built app, using stock controls... ...which fail to perform as advertised or scale properly... ...so you buy third-party controls, which don't solve the problem... ...so you supplement the cheap wizzywig coders with real programmers, who co$t much more money... ...and you lose the source code because VSS crashes and corrupts its repository... ...and the CIO won't use SVN or Git or Mercurial, but insist on $pending much more on Micro$oft Team Foundation $erver... ...and deploying builds takes much longer because "it worked on my machine", and who needs CruiseControl.NET when the IDE is so neat!... ...and managing the servers securely requires new hardware and better trained administrators... ...which is why the project often seems to cost 200 times what was budgeted.
None of this is unique to.NET; but the perception that "it's just so EASY!" often makes it worse.
I'm also not saying this is how this particular project went; just using these points to discuss the perception that.NET apps are cheaper to develop.
> The emails you do get from various online institutions don't look all that > more legit than the ones from the scammers.
Sadly true. My bank's email's don't look all that legit either; fortunately, they have a "messages" button on my account page. If I go to the site and click that, any email they sent is also on the web site.
I've gotten into the habit of deleting the emails unread and then logging in to my account to see what the message is.
Slashdot Mirror
This page:
https://www.squarefree.com/bookmarklets/pagelinks.html
has some neat bookmarklets, one of which removes redirects.
I don't use it all the time, because some sites depend on the ad revenue.
But if the site abuses redirects, I have it as an option.
Several other nice bookmarklets there.
> The mistake of equating all open source technology with Linux was "really very early on,"
> Paoli says. "That was really a long time ago," he says. "We understand our mistake."
So... Microsoft's new tune is "We Love Open Source...Except GPL Licensed Open Source"
> Microsoft hasn't ... rescinded its declaration that Linux violates its patents...
> [Microsoft's] earlier battle stance was a mistake. Microsoft wants the world to
> understand, whatever its issues with Linux, it no longer has any gripe toward open source.
Except GPL Licensed Open Source
> Microsoft has released some technology under its own open source license (the .Net code with
> "Microsoft Public License"), such as IronRuby, which integrates
> the Ruby programming language.
"Signs are pointing to Microsoft backing away from IronRuby..."
ZDNet, "What's next for Microsoft's IronRuby?" by Mary Jo Foley
http://www.zdnet.com/blog/microsoft/whats-next-for-microsofts-ironruby/7034
From the article:
'According to a now former IronRuby developer, Jimmy Schementi, Microsoft
has just one developer left on that project (who is committed to it half-time).
Schementi recently quit Microsoft when his manager asked him "what else would
you want to work on other than Ruby," he blogged.'
Summary: Microsoft says "We Love Open Source..."
- except Linux...well, any GPL Licensing, really
- and we still maintain they violate MS patents...a bunch of em.
Really, you can take our word for it
- and we'll still extort license fees under threat of enforcing these
patents we refuse to enumerate
- and we love open standards and open technologies, and want to
work with them...as long as we can make a proprietary DotNet version...
And Microsoft will stand by its commitment to open source, unless its
absolutely convenient.
Hurray for Microsoft! Hip, Hip, Phhhffffttt!
Contact vendor and a reputable third party, such as CERT, simultaneously.
Give vendor a -very- small window (at -most- a week or so) to respond, with (1) contact information; (2) an assigned issue identifier (at least one while triaging), and (3) a specific time frame till a follow-up response, not to exceed N days (your choice; 14, 30, 60, 90, etc.). This response does not need to be a full triage and verification, just a real response of "we assigned this to John Doe to research as issue number 54321-unverified", rather than an automated "Thank you for your email..." BS response.
If the vendor blows off responding to this, contact one time requesting the information within a short time frame, informing the vendor of your intent to go public if they do not respond. If they fail to respond, release the information on the exploit, along with any known workarounds.
If the vendor responds with contact, information, etc., give them a time frame of N days (your choice) for analysis and wait for follow up until the time frame of N days specified earlier. If they fail to respond, see above. Again, this does not need to be the fix, just "we confirmed the issue and have determined this is a priority X issue. We are assigning it to Richard Roe to be addressed in a patch/scheduled update/major service pack/next version of product"
After the vendor has performed this initial assessment, give them a fixed, fairly aggressive period to respond with a fix, patch, or workaround, and hold them to the date as above. It's up to you to decide how long to give the vendor before you release the information. If their estimate is too long or inadequate (next version of the product, 18 months from now; will require all new hardware and tens of thousands of dollars), then give them a shorter time frame for a patch or workaround, and inform them that you will hold them to it.
Then hold them to it.
My biases: I believe vendors almost always take much too long. The goal is not to give them a comfortable time frame to respond or fix the issue, but -enough- time. If it's comfortable, it's too long.
Security flaws are unacceptable. If the vendor can't fix it, they must provide a workaround. If they can't provide a workaround, people need to be informed so they can stop using the vulnerable product or feature.
A lot of times you can just disable the feature rather than the entire product.
But people can't do that if they don't know it's broken.
> If a patent is overturned in court, you pay a statutory $10,000 fine, plus the
> legal fees of the person who sues you.
I'd adjust that to reduce litigation. If the patent is overturned in court, I'd add an additional penalty for the time between the initial suit and the time it's resolved. The additional penalties can be waived if the patent is retracted unconditionally, and the matter is settled out of court. No out of court settlement would allow waiver of the burden of legal fees, no out of court settlements allowed without retracting the patent unconditionally.
> If you are found to have filed the patent in bad faith (i.e. knowing
> that there was prior art) then this becomes willful abuse of the patent
> system and the fine goes up to $100,000.
And an additional payment to the person who filed the suit.
> If a patent is found to be invalid, you must refund all license fees
> collected on it, plus 50%. This is a statutory penalty and may not be
> disclaimed by contract.
Agreed if found to be a bad faith patent. Limit to the license fees themselves for invalid patents filed in good faith.
> Anyone has standing to sue for an invalid patent, but the loser
> pays the legal fees of both parties.
Needs work. Big companies would benefit from this, in that they would be encouraged to abuse the system with counter-suits, delaying tactics, etc. Effectively, people suing the big guys would need to have all of the following:
- absolute certainty they are right
- massive amounts of time to devote to this case (decades)
- and massive funds in reserve.
For both the above, a recent twit tv floss program discussed the real story of how ugly and expensive some of these fights can be. And it would be _much_ worse if you were involved in a suit with a big company with very deep pockets.
That's why people settle. The legal system is too expensive for the common man.
> Companies have a one-year amnesty after these rules are introduced
> to retract patents that they discover to be invalid as a result of
> internal auditing. No fines are incurred for patents that are
> disowned during this period.
Why limit it to one year? Unlimited amnesty, but after one year, an upward sliding scale of the percentage of licensing fees that need to be returned. Encourage them to audit soon to avoid repaying years of licensing fees.
I worked on a couple of different teams for one company, in different office situations.
In one, 8 of us were in one common room, and we worked well together. Originally, we were all facing the walls, but we all agreed and moved the desks so we were facing one another. It was great; close group, close spacing, got along, worked well together.
Later, in the same company, in a different group, just three of us in a larger room. One of the guys snagged a conference room for a week just to get some work done. One member of our group was a "social butterfly." Loud conversations, all day long. Impossible to concentrate. Very limited knowledge of technology, always undoing the good work done by others.
I work now with some folks who are productive later in the day; in the morning they socialize, loudly. I work best early. It's unbelievably difficult to concentrate sometimes. Sometimes people need closeness, other times they need space. Particularly if work and personal styles don't mesh.
It's not the "most productive arrangement" that matters. It's the most productive team. What's best for the individuals that make up your group? Talk to -them-.
> ...the idea of federal standards for driving certification kind of appeals to me.
I assume you mean "good" standard for driving certification.
Unfortunately, good standards are no more likely on the Federal level than they are on the state level. A number of the biggest problem cases are political hot potatoes, such as driver age (both too young and too old), and the fact that outside of a relatively few large cities with good public transportation systems, getting around without a car is nearly impossible.
I know a number of people who, for physical reasons can't drive or walk long distances, and who find it enormously difficult to get to medical appointments and take care of grocery shopping. There is -no- public transportation alternative for them.
That problem was made the loss of small retailers and corner markets, replaced by big box stores and supermarkets, and the replacement of the small office general practitioner with the "medical group".
Politicians who want to get reelected are not going to put more people in this kind of a position.
Application from hell. Client was almost ready to accept delivery of an application from another firm. Application was to distribute procedure documents created by central office.
Client forgot to develop and application to generate the procedure documents.
We had to slap together a tool to do this in less than 1/100 the time used to design the original application.
Did I mention it needed to support rich text, linked documents incremental translation and editing for the overseas offices?
Duct taped together several programs (Word, Access, Excel, others), users had to follow instructions and prompts. But, users don't -read- instructions or prompts.
One guy on my team wrote a custom messagebox. Anywhere any code called Windows MessageBox, it logged to a flat file:
- the calling function and context
- the exact title of the message
- the exact text of the message body
- the exact selection the user made
Tech support could view the flat file, read backwards, and see exactly what the user did, then walk them through doing it correctly.
Still a pain, but a manageable one.
What's tight at these locations is compliance auditing more than security.
In many environments, these compliance requirements have the force of law, and it can be a long up-hill battles to change a poor, "hack" compliance regulation, such as "Use Internet Explorer 6 with these settings and patches", to an effective one (use a browser that supports the following security...).
Since the ostensible purpose of compliance is security, many people mix the two concepts.
All excellent examples. Some of the things that help these events work:
- variety. I can't drink or have donuts or pastries for health reasons, but I love to cook chili, or chicken wings, or something hearty for lunch. other people have different health, cultural, or religious restrictions.
- self-sponsored. volunteer organizers, keep it simple and light. too many companies that do "events" over-control them; timed to the minute, checklisted, get in the queue, march in time.
- contests. some folks had a clever idea where I'm working; everyone picked an innocuous secret about themselves, and everyone had to guess who, in another department, had which secret. it gave people the chance to talk socially, rather than about work.
- time and consideration. too many companies that do "events" fail to leave time to socialize. especially with support staff, arrange to cover for them while they join in. push back meetings to another day, lighten up on "get this done by the end of the day" B.S. tasks. give people a chance to enjoy the event without worrying about the pile of stuff on their desks.
> The God question is sort of like dividing by zero in math. The result isn't 0, it is undefined,
> or sometimes referred to as "not a number", and sometimes referred to as infinity.
> It definitely exists, and can even be useful in certain applications, depending on how you
> treat it, but what it means is impossible to determine.
I like that comparison. Thanks!
> Only the Agnostics take a logical stance when it comes to god, and simply state "I dunno"
> and go on with their lives.
Nitpick: logical, if you _believe_ that the failure to choose is a safe, neutral option.
"Would you like carrots or broccoli with your meal?"
"I dunno."
Is a neutral option choice.
"Here comes a truck heading straight for me! Should I dodge left or dodge right?"
"I dunno."
SPLAT!
Is a case where failing to choose is a choice, with consequences.
Imagine you're in Germany in the 1930s. Someone asks what your opinion is of these brown-shirted guys and their leader, Adolph somebody, with the Charlie Chaplin mustache.
"I dunno" is fine; but history shows that trying to learn what these guys are all about would be much safer than just moving on with your life in blissful ignorance.
Is it enough to say "I dunno" and move on, or do you need to proceed to "I'll take time to study, so I can make a decision."
> I'm also careful not to commit the fallicist's fallacy - that is, just because an argument
> is fallacious does not mean the conclusion itself is false
Or phrased differently, lack or scientific proof for or against an assertion/theory/belief doesn't make it untrue, just unproven/unprovable.
Good comment.
I expect you're right. I (and a number of people I know), purchased Amazon Gift cards at the 11th hour.
Convenience and rapid availability would apply very well to any dowloadable media.
>> Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.
> I have to disagree, here. I've banked with several different credit unions, a couple of small :)
> banks, and three or four large banks over the past several decades. I've never had an EFT go
> missing. Besides, if the problem was as widespread as you believe our entire e-commerce
> marketplace would have never taken off. Amazon seems to be doing quite well.
Fair comment, but I must point out a few things:
- I didn't say the EFTs went missing; they weren't completed or cancelled. The bank knew where they went; they just couldn't resolve it in any reasonable time frame.
- I didn't say debit cards there. That specific comment was EFTs. Online banking payments in place of checks. Debit cards work very well, and I use them online at several places. But the legal protections aren't there. The banks have largely implemented good policies for handling debit card issues. But in case of an error, there is no legal protection. And banks often don't offer any of the same protection policies for online direct bank payments.
- I didn't say it was widespread, just commonplace. It happens to a lot of people; percentagewise not often. But with the number of people using them, even a tiny percentage adds up quickly. They are probably significantly -less- frequent than check errors. But check errors are governed by law. Consumer EFTs not so much.
Check the Risks Digest and Consumerist.com, as well as a number of mainstream news sites. If happens, and when it happens, it's often very bad.
> I will concede, though, that person to person EFT capabilities have been FAR too slow to emerge.
Not just consumer to consumer; they are often -very- unfriendly to small businesses. I've worked for many firms that don't offer direct deposit, not because they don't want to, but because of the horribly obstructionist bank policies.
Thanks for your comments.
>> not all customers have access to electronic funds transfer.
> That's your problem, right there. Fix it.
It's a problem, but not the only problem in the US.
> The capability for electronic funds transfer should be automatically granted with any bank
> account - both via debit card and via internet. In the Nordic countries, cheques are
> essentially extinct.
Most other nations have different financial protections on EFTs than here in the US.
One root cause of this is that the banking system in the US grew from state-chartered banks, not federally-chartered banks. 50 states, all with different rules and regulations.
Much of the current legal and technological infrastructure to begin to _consider_ phasing out checks in the US was only put into place post-911. At that time, the federal government was confronted with the fact that they had been nursemaiding a check clearing system leftover from the early 20th century, and even a brief interruption of airline service significantly impeded the ability to move huge boxes of paper checks across long distances quickly.
The legal overview still isn't as good as it needs to be. People in the US are still advised by security and financial planners to use _credit_ not _debit_ cards, because the protections against errors and fraud are "bank policy" which can change in an instant, not "the law".
Correcting an issue with bank errors in clearing a check required banks to put the funds back in place and follow a real procedure for resolving the issue quickly.
With EFTs/Debit cards, banks are typically _very_ slow to restore the funds, and often glacially slow (and incompetent) at resolving the issues.
Personal experience: I've set up EFTs for recurring bills at various times in the past. In each case, the bank was unable to complete some transfers, unable to cancel the transfer, unable to resolve the issue quickly, and I was charged for late payments. Some of these took several _months_ to resolve.
> The only cheques deposited are invariably from countries with backward retail banking (UK, US, Canada, etc.)
As noted by another poster, it isn't all retail. In fact, it likely isn't even _mostly_ retail that deals with checks. Small service industries: appliance repair, contracting/home remodeling, charities and non-profits, small-business suppliers and wholesalers, shippers and transport firms, any companies dealing with Asian, South American, or former Soviet-block nations need to deal in checks all day, every day. Or lose the bulk of the business they do.
> electronic transfer to or from other accounts (worldwide) is fast and cheap,
> and provides immediate confirmation of receipt of the payment.
Not in the US, and the banks are shielded from the need to confirm _by law_. I'm also curious about the claim that it's fast and cheap (reliable implied) worldwide. I mentioned several regions above where checks are still common. I have no doubt that fast, cheap and reliable EFTs are available in all those regions. But are they reliable to all businesses in those areas? Sure, if you are dealing with a big Asian electronics, metals or chemicals supplier, I'm sure it's no problem. What about the small-lot specialty suppliers; do they have the same fast EFT access, with reliable transfers protected by law? I'm not so sure.
> There is no risk of "delayed/lost in the mail" as happens to cheques with remarkable
frequency.
Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.
> On-the-spot payments (small stores and large, petrol stations, vending machines,
> parking meters, etc.) are made using the debit card for the account.
Mostly true in the US; some things (parking meters) are not usually equipped for debit cards. In part, this is due to the fact that there are more parking meters in some major US cities than there are _people_ in some of the Nordic countries you mentioned. Since ownership and management of t
> AFAIK French legal system doesn't use this "precedence" the same way you USAers do.
You're probably correct. France's legal system is quite different from that in (most of) the USA. Louisiana still uses a lot of the French legal systems it had in place when it was a French territory.
But IIRC, the typical US legal precedent usage isn't specific to the US, but is based in the British Common Law, which is the legal system in many nations which were formerly British territories.
IANAL; I just play one on the Internet ;>
> Visual Studio, specifically VC++6, rocked in the days of writing Windows apps. ...the editor itself was just awesome. It was solid, never crashed ...and was ...Later versions, though, got seriously sluggish, and yes, ultimately it's
>
> fast fast fast.
>
> just a glorified text editor, so why are all these windows sliding in and out
> at odd times, they rearranged all the project settings...Plus everything up to
> VS2008 has just been slow for me...from constant annoyingly-slow to
> wait-did-it-freeze-up-on-me-oh-no-it-just-came-back slow. Plus I've been
> able to crash pretty easily all of them...It's just that painful.
Hear, hear. Same pain on my end.
Especially with SSIS; redrawing the pretty little boxes seems to suck up all the processing power, and bring any other MS tools, like instances of SQL Workbench, to a halt.
Add to it the fact that, while the tools allow you to build project using msbuild and useful tools, the defaults are still exactly wrong. I work with a couple of teams at work who regularly have deployments to our production servers bomb, and they can't back out, because setting up the msbuild scripts and properly versioning the right files isn't the default.
It requires you to override the tools and do it manually. The pointers and clickers don't know how to do that and don't want to learn. So where I have Rakefiles (I was using ms-build, hoping to get others to use a decent tool by choosing one from MS. After fighting for months, I said screw it and just started using rake), they have 40 page manual checklists and tons of committee meetings to prevent errors -- and they still fail as often as not, and they never know what changed.
My Rakefiles track changes and version numbers, and I can back stuff out when needed (which isn't often).
Good to hear that 2010 seems to be better; but around here, that means we'll probably start using it in about 2025...
That's one reason I specified I was going off the summary.
I don't use ComCast and din't plan to search out the sources, but it's good to know a little about it.
Thanks for the info.
Thanks! I'll check it out.
Quick disclaimer: I don't use TFS, and don't care for integrated solutions - not just MS, but any of them.
> ...using TFS was the first time I realized how much an integrated source control, team collaboration
> site, project management integrated solution makes sense.
In some scenarios. I know any number of companies where the MS integrated solution you use would fail utterly to be useful, because the people would not use the tools properly. Not just developers, but project managers, users, etc.
The *nix/open source advocates generally don't favor all-in-one packaged systems. The vast majority of the time, the system has specific, glaring deficiencies, While it often works well for a specific group, it fails to support others adequately.
This condemnation has been levied against Eclipse regularly, and from personal experience, I can tell you that the Visual Studio IDE alone, while it is absolutely adored by many, is in many ways a useless tinkertoy for others. MS (and other all-in-one solution providers) don't provide the perfect experience. They target a specific group, and often their "solutions" actively undercut the work of others. Some specifics:
> * Integrated work items with specialized and extensible work item types for tasks, bugs, issues etc.
Working with a system now at one assignment that is remarkably poor. It works beautifully...for on-call help desk support. It actively -impedes- tracking of bugs and tasks for development. I actually use a full external tool and update the approved system at the end. This is awfully inefficient: only 10 times more productive than trying to use the approved tool.
> * Work items, tasks, issues etc. editable through a web interface, but also right from inside the IDE.
That's handy - if everyone uses it. Where I'm on assignment, no one can be bothered to update information. I track things in my a web-enabled system, as I said. Several times a week, someone asks me to print out information in that system. It's become the system of record for a lot of this information, and anyone can use it; but I'm the only one who does. Everyone else's data is in little silos.
> * Work items, tasks, issues etc. editable through Excel or some other spreadsheet (regrettably project
> managers favorite tool is *still* Excel - but having it integrated so the rest of us don't have to
> mock around inside columns and rows to update status is a big relief).
Again, handy -- if anyone uses it. Not so handy when people actively break it by mucking around with the Excel sheets.
Just kill Excel use.
> * Source control without quirks when e.g. renaming files or removing files and adding files back with the
> same names (I've had bad experience with subversion)
Others have complained about similar issues, but they aren't universal. Chances are you're not managing the files properly in subversion. But subversion isn't the be-all and the end-all of open source revision control. It was never intended to be, just a better CVS.
Git is very nice, and there are -many- others to look at. Check Wikipedia.
> * Shelving - storage of not-completed changes on the server without checking in. We use it to share
> suggestions and if we cannot make the daily deadline on consistent check-ins.
Never used it. Frankly sounds like a hack; why not use a branch?
> * Configurable policy which can be set to reject commits/check-ins if a build has not been completed
> locally and/or if too many tests fails and/or if test coverage is too low and/or if there are too
> many/certain warnings (e.g. security related).
> * Dashboard with project manager-friendly roll-ups and graphs with speed, test coverage, test
> completions, tasks, status etc.
Tons of options and tools. Again, not an "integrated" one I can recommend, as I don't care for integrated.
> * Branching based on metadata - not on actual directory copying and separat
> If this is a GPL violation, I'm sure it wasn't deliberate by Microsoft.
> People around here no doubt think differently.
Yes and no.
> I'd be interested to know what processes they have in place...in theory,
> something like this would be a...break-down in the process.
Microsoft doesn't have a great history with "process", of whatever sort, being followed by all business units. This is true with security, and using "other people's code", not specifically open source.
They don't seem to be that organized. I suspect if this is a true GPL violation, this isn't part of a grand evil genius conspiracy. But it's quite possible, in my opinion, that someone lifted this and that there really isn't much in the way of controls on this. Rules, sure; but no real process to ensure it happens.
I'm not saying, "Linux Rules, Microsoft Drools!" Just that MS, among commercial software companies, focuses on marketing aggressively, not process control.
> ...cable modem contracts [assume] that your bandwidth is shared... You can burst up to the
> advertised rate, but you are never guaranteed to get it 100% of the time.
The offensive part of this is not that there is no guarantee of availability, but that there is a guarantee that it will -not- be available for more than 15 minute increments.
> You get throttled *only* if the network is congested...
That's not what I saw in the summary. The summary states that you will be throttled if the network becomes congested -or- if you use more than 70% for 15 minutes. I would agree that throttling if the network becomes congested is reasonable, and scaling back the peak users at those times is the obvious measure.
But the "70% for 15 minutes" cap, when there is no congestion seems to be unsupportable. I can imagine thousands of legitimate scenarios where home users would use 70% plus for longer than 15 minute increments; not 24/7, but for longer periods than 15 minutes. If no other users are competing for the bandwidth, what is the justification for throttling?
> "The outage was caused by a system failure that created data loss in the core database and the back up,"
> [Microsoft Corporate Vice President Roz Ho] wrote in an open letter to customers.
It sounds like their "backup" was a replica on another connected server.
No actual offline backups at all.
When JournalSpace was destroyed, one SlashDot thread was "Why Mirroring Is Not a Backup Solution".
My favorite comment was by JoelKatz:
>> The whole point of a backup is that it is *stable*. Neither copy is stable, so there is no ... if the active copy of the data is corrupted, there is no backup.
>> "backup on the hardware level". There are two active systems.
>>
>> If you cannot restore an accidentally-deleted file from it, it's not a backup.
>>
> Dude, a .reg file *is* a script. There's no difference between double-clicking on FIXSOUND.REG
> and double-clicking on sndfix.sh.
Except sndfix.sh (oir any shell script) can have conditional and branching logic, and verify the current configuration settings.
A reg file can't do that; it is always "erase and replace, no questions asked."
That's why more Windows admins are using PowerShell every day.
> My big complaint with the registry is that it's too convoluted. Config files are typically
> either in the user's home directory, the program's working directory or its installation
> directory. Registry entries could be buried under something like HKEY_LOCAL_MACHINE/SYSTEM/
> CurrentControlSet/Control/Class/{4DE36972-E325-CE11-CBFC-86753094BABE} -- how the hell
> am I supposed to remember that? (Assuming I could even find that in the first place!)
Very true, and I feel your pain.
>>The only thing that seems strange is the cost disparity.
.NET applications are quick to get to the "80% done" phase. "Are you finished?" "80% done, boss!"
...which fail to perform as advertised or scale properly...
...so you buy third-party controls, which don't solve the problem...
...so you supplement the cheap wizzywig coders with real programmers, who co$t much more money...
...and you lose the source code because VSS crashes and corrupts its repository...
...and the CIO won't use SVN or Git or Mercurial, but insist on $pending much more on Micro$oft Team Foundation $erver...
...and deploying builds takes much longer because "it worked on my machine", and who needs CruiseControl.NET when the IDE is so neat!...
...and managing the servers securely requires new hardware and better trained administrators...
...which is why the project often seems to cost 200 times what was budgeted.
.NET; but the perception that "it's just so EASY!" often makes it worse.
.NET apps are cheaper to develop.
>>.NET apps are usually much cheaper to develop...
I'm not sure of that reasoning. Based on my personal experiences, I would agree that
The problem is that often that represents 20% of the total cost, and the remaining effort to get to completion is almost all cost overrun.
It starts off as a largely wizard built app, using stock controls...
None of this is unique to
I'm also not saying this is how this particular project went; just using these points to discuss the perception that
> The emails you do get from various online institutions don't look all that
> more legit than the ones from the scammers.
Sadly true. My bank's email's don't look all that legit either; fortunately, they have a "messages" button on my account page. If I go to the site and click that, any email they sent is also on the web site.
I've gotten into the habit of deleting the emails unread and then logging in to my account to see what the message is.