And just where did you find this article? We slashdot nerds can handle active weblinks, you know. Or at least a reference to a tree-killing publication or something.
I was making an unstated assumption, but I indeed miscalculated.
The old Intel 16-bit x86 architecture had 32 bits for addressing in a segment:offset format. However, 12 of those bits were redundant; each upper-word segment referred to a 16-byte memory line, so that A000:0010 addressed the same byte as A001:0000 (at 20-bit address A0010). In order to compare long pointers as equivalent, you had to first convert them to a canonical format.
I was presuming that any new 16-bit architecture would not have to be real-mode compliant in this way, so that you would still use segment:offset but then get 32 bits out of the address space, meaing the same as existing 32-bit architectures. Somehow the twisted calculation in my head came out as 64MB. I must have lost a few binary orders of magnitude on the floor somewhere.
99.99% of computer users have absolutely no need of a 64bit environment.
Well, do you really even need 32 bits? The problem is that no one writes 16-bit software anymore, not that we need 32 bits. I'm sure Intel could make some super-zippy 16-bit computers now with 64MB of memory.
Eventually 64 bit machines will be common, that's all modern software will be written for, and then you won't be able to use a 32-bit machine if you want to because the desired software won't be available.
So, while it's not mandatory, I'd definitely say It's The Future.
--dv
Well, rather than "proof that George has lost his touch" why not say "reinforces my opinion that George has lost his touch"? It's more accurate, less snippy, and doesn't incite a flamewar over whose opinion has the best proof.
It's troll because it incites people like me to correct you. See the definition for troll.
They put up the copy of the story BECAUSE THE ORIGINAL LINK WAS SLASHDOTTED. So it's remarkably convenient rather than having to way two days until all the nerds stop viewing the story. The original server and ISP will probably thank you as well; no one is trying to "get one over on copyright" here.
Ah, I would beg to differ. "Please? Pretty pretty please????" <whimper whimper>
I lament the loss of distinction between geek and nerd. Other posts here have hinted at it, but I want to shout it from the monitor tops!
Nerds are the socially inept, technically super-competent intelligent tinkerers of the information- and technology-focused world. Geeks are the socially repulsive, generally stupid chicken-head-biters (traditionally) or booger-eating undesirables (modern) of everyday life.
I don't mind being called a nerd, but I AM NOT A GEEK <Elephant-Man-Music/>. Please maintain the distinction in your everyday lives and help educate those stupid Hollywood people who couldn't get a technical term straight if their multi-million dollar budgets depended on it.
Remember, you are the first defense against misuse of techspeak!!!
Dude, Winnipeg's subsurface triggers work, and the place has an 80 degree spread, winter to summer (celsius, without the whinefactor -- that is, without windchill "added in")
Well by "winter punishment" I mean freezing / melting / refreezing, not severely cold temperatures. While I will agree that Winnipeg is significantly colder than NYC, I would bet that here we cross the freezing threshhold during the winter much more often than you do. Winnipeg gets cold and stays cold, while NYC often melts during the day and freezes at night. This wreaks havoc on roadbed material, turning it into gravel.
It also seems a problem in all US Northern Seaboard cities (Boston, Philadelphia, etc.). Boston has some of the worst roads as well. And this doesn't include the multi-fold volume of traffic per street mile.
I will however give a respectful nod to Canadian infrastructure, that seems to be able to produce sturdy reliable long-lasting roads. I don't really know for sure though whether the same techniques here would just continue to rupture year after year (thus making the expense too great), or if they're just too expensive in the first place.
*Almost*all* the crosswalks in NYC sport buttons. Almost none of them work (I haven't actually tested most of them though), because you can tell that the time that it takes for a WALK to show doesn't change when you press the button or don't. (As I stated in a previous reply to this story,) almost all traffic lights in NYC are timed and don't vary based on traffic conditions, like other areas of the country. They may vary based on time of day and even day of week, but I do an awful lot of stopping for nobody at red lights when I drive at 2 AM.
The real reason is that almost all NYC traffic lights are on a timer anyway. Unlike most areas of the country that have on-demand lights that are sensitive to traffic and keep green for the major roadway, if you wait a minute the light will change anyway. So why interrupt the rare possible synchronized goodness on a Manhattan avenue for the impatient pedestrian?
The downside to this timer approach is that you often wait for nobody at red lights at 3am. Stooopid lazy NYC planners.
Either that or the trigger antennas that they would need to place under the roadway can't take the winter punishment.
BG: Until we had this concept of Web services, software on the Internet couldn't talk to other software on the Internet. The only thing that worked was you could move bits -- that's TCP/IP -- or you could put up screens -- that's HTML -- but software couldn't talk to software. And so it's pretty fundamental to think about Web services and how that's built in. That's what really takes the Internet to the next level where you're going out and getting price quotes or....
Is BG really saying that Microsoft has invented Internet communication between software apps? This sounds to me like a sly twisting of the State Of The Art. Hmmm... TCP / IP is just moving bits, but.NYET is software talking to software? Doesn't.NOT go through TCP / IP anyway?
Part of the problem may be that I don't understand.NEM fully, but the only difference I see is that.NIT is XML on top of TCP / IP, in an easy-to-access form (with the appropriate MS licenses, of course).
Please clarify my fuddled brain, or translate Bill-speak for me.
Well, technically lying (the deliberate telling of falsehood) is a subclass of deception. Deception is deliberate, like lying, but can include categories like camouflage, altered photographs, withholding information, redirection of attention, and duplicate part numbers for merchandise with differing specifications (as long as it's deliberate).
Please gentlemen and gentlewomen, let's keep our categories of vice appropriately defined.
1. Never trust anything Microsoft says. Trust only what Microsoft does.
>> corollary: "Trustworthy Computing" is sheer bunk until it appears in the digital flesh.
>> corollary: Microsoft is more interested in PR spin than actual truth. (or is that a lemma?)
2. Never trust anything anybody else says about Microsoft until it has been demonstrated that there is no financial or political relationship between the speaking party and Microsoft.
>> How many "grassroots campaigns" and "testimonials" and "benchmark reports" and "white papers" by supposedly disinterested third parties has Microsoft been exposed to have influenced unfairly? Did you run out of digits to count on? Borrow a few friends, I'll wait. My, your little office is getting crowded!
3. Follow the money. If it doesn't bring in more revenue, Microsoft doesn't care. Nits in the OS (GOD I hate the shutdown being the first item on the start menu, e.g.)? Big deal, they don't have to change it and you can't do anything about it BECAUSE YOU CLICKED YES ON THE EULA.
I'm not bitter, I'm just squashed helplessly into the ground by an indifferent greedy corporation.
Telemarketing has been a fact, but recent regulations have improved. You can now have your phone number added to a database which all US telemarketers must check before calling you. If they call you when if you are in that database, or if they call back after you have explicitly requested that they not call you back, they can be fined $500 for each violation (or some such fee). Perhaps not many people know of this database, but it does work and several telemarketers have been successfully sued for their violations. I still stand by my statements that regulations don't have to be incomprehensible, nor hinder normal use. I am unfamiliar with the "screening services" you mention, but I don't think anyone has to buy these to accomplish a reduction in telemarketing calls.
Telemarketing is less prevalent than spam though, because there has to actually be a live person on the other end (usually) to make it really work. But I see your point that e-mail is a different issue. It is international in scope and forgible in content.
The phone regulations work because the infrastructure is there to support it. E-mail does not have this infrastructure: phone calls are traceable, and centrally controllable while e-mail is potentially UNtraceable and not centralized.
Then perhaps what we need is a better infrastructure? A series of "trusted" servers perhaps, with required configurations? Some overseeing body to reject a server deemed irresponsible? That would also mean a centralized location for complaints... a big plan but perhaps necessary.
Another idea is to go after those who benefit. At some point there is a name or URL to visit or write. If they aren't the spammers, then they can provide who is or be shut down anyway. I know this approach has been taken by some mail administrators, but won't work unless it's applied consistently.
This all sounds like turning e-mail into the phone company, but I don't have another workable solution right now. Hmmmm.... more ideas, anyone?
Your solution does not solve the problem whereby Internet bandwidth is wasted. The mail still goes to the end-user's pickup point, where some user-defined rules reject it.
In addition, spam is a part of a technology/counter-technology process: you write a filter, then the spammer writes cleverer things to get around the filter. It is a Hard Problem to write a tool that correctly rejects the spam and correctly saves the non-spam. Obviously you don't have this tool to provide for us, so you handwave as though it already existed.
Yes, regulation will result in higher cost, but not necessarily in "incomprehensible rules," nor will it necessarily "hinder normal use." Fax rules are pretty clear, and work well. We have regulations for various services because we need them. Why else would our phone system be regulated? Because the Ma Bell is a dirty greedy company that wants desperately to cut corners and provide us with inadequate service in order to raise profits. So with e-mail; prevent its abuse so that we can have adequate service and an unnecessarily diminished infrastructure.
The real problem is that spam costs the spammer nothing; the real costs are borne by the receiver and his intermediaries. A similar thing happened with fax adverts, where people were getting pages and pages of junk, using up paper (expensive!) and preventing the real faxes from getting through because the whole roll was used up before the night was through (though the sender might have had to pay phone charges). Junk p-mail behaves better because the costs are borne by the sender; p-mail advertisers are remarkably efficient in targeting end-users, using bulk-mail rates, and so on.
Maybe ISPs should charge for number of recipients that a sender sends to, but even this seems a Hard Problem with remote distribution lists appearing as a single recipient. But it seems to me that until the sender starts bearing some costs for extra recipients, the spam problem will remain.
It does make very good sense to me to use comments in the place of source control where such is not readily available or is overkill. But the comment example you provide actually gives useful necessary information separate from the date/person comments. I'd want to know about the race condition in any case as a general comment. What I really mean, is the person and date information useful enough to be kept in the code? After a while they become obsolete; either the person leaves or years go by and the code remains. I've seen comments in code saying it was added four years prior, or some section was commented out by a person long forgotten. Having a point of contact for the section of code is useful, but it is better to have the text explain itself. Really though, I split hairs here as we are both much more in line than at odds with each other.
I will have to admit though that none of these can be thought of as hard rules; there has to be a balance to them all. We have to also take into account team dynamics and agreed-upon procedures. I don't think I've ever been involved with a project that didn't make some kind of non-perfect requirements on the participants; either there were some procedural hoops or we didn't have good source control or the existing code couldn't be rewritten or something along those lines. So these are all rules made to be broken as appropriate.
About marking changes, I would argue that the best place for that information would be source control. Source control will allow you to diff the two to see what version put the new code in or took it out, and also allows a change comment which describes the difference. Change comments require that you know the history of the code, which not all readers will have.
As for why code was inserted, that is always relevant information for comments:-).
I really like your idea about writing the comments first, however. I sometimes use this approach but honestly I don't do it often enough except where I'm having a difficult time getting my brain around a project. Probably because I don't use it, I didn't think to put it in-- my poor discipline is showing through.
Your idea about required standards in coding is also excellent. I prefer to use that approach but I often find it unpalatable to my coworkers because, well, herding programmers is like herding cats (or is that nailing jelly to the wall), and I don't have the dictatorial authority. Or the project already has lots of existing code. Rarely do I get to start anything.
Your other comments I think I mentioned already, but I agree with them.
Start with descriptive variable names and, where possible, code structure that models the problem domain. There is a necessary judgment call, as you can get carried away with variable names, such as m_lpszRepresentationOfDatabaseState. The hungarian notation thing can be helpful, but I sometimes find it tedious, especially for local variable names. You have to strike a balance between consistency and usability; if it's a pain to maintain, someone's gonna choke on it later and just not keep it up.
Let the code formatting accurately reflect its structure. I go out of my way to align items and maintain a consistent formatting style. It's easier to get a visual picture of how the code works. You might not think of this as commenting code, but it does help the reader understand it-- which is really the larger picture of what commenting is about.
Comment the non-obvious only. Don't comment a line like "x += 2;" with "Add 2 to x". Sheesh, we all knew that. As much as there is an argument for "all code should be completely self-commenting"--and I once worked in a shop that regularly removed comments from your checked-in code--you can't put everything in code. Some code just can't accurately reflect the decisions behind the logic, especially in code that's been highly optimized.
Comment arbitrary decisions. Why did you decide to limit the array to a static 25 items instead of a self-sizing dynamic array? Why are you doing a quick sort instead of a bubble sort? You don't have to do this for every little thing, and some are obvious (why are you using an int here instead of a char*?), but if it would help a new reader understand things, write it. Manifest constants can be a big help here; use that feature if your language supports it.
Comment code decisions based on external information. You don't have to reproduce the documentation for the other component or API, but at least mention it where it's not obvious. "There is a limit of 45 entries for the FoobieBletch address table. See the FoobieBletch documentation in Appendix C."
Comment unconventional areas. If you are iterating over an index from 1 to size instead of 0 to size-1, point it out so your readers don't think you're a C-newbie. I find it's also a good practice to comment that you're deliberately leaving out a break statement in a switch. Also, sometimes you have to write workarounds for other people's bugs or misfeatures (like MS' CString class), so it's a good way to point out that the bozo isn't you.
Keep comments brief. Verbose comments are boring to read, so your readers won't read them. They're harder to maintain, so maintainers won't maintain them. They're harder to write so you're more likely to make a mistake. They'll become out of date and mislead some foolish coder who forgets that comments are not code.
Don't use comments as source control.I hate seeing items like "This code changed by JZR on 3/18/1997. BEGIN CHANGE--" It doesn't help me understand the code. It can get cluttery, especially with common header files or high-traffic development areas. Let your source-control tools provide this information for those who need it.
Don't comment out code for long periods of time. A text search will still find the comments and make the searcher wade through more junk. Not to mention if you comment out all the calls to a function, the function itself still looks viable. A temporary commenting out is okay as a quick tool for development testing, but with the right source-control tools you won't need it.
Take the time and effort to review existing comments before you check in changed code. This is a hard thing to get people to do, but it helps to maintain consistency. If you don't do it yourself, you're just plain lazy and don't care about those who follow you. Coding is usually a team effort, even if the team is you now and you six months from now when you've forgotten this little stretch of structured wasteland.
Don't get too fancy with commenting. It can be tempting to block your comments with pretty/*********/ boxes but if it's a pain to maintain it just gets in the way.
I'm sure I have more of these somewhere but these are off the top of my head. Besides, I'm in danger of violating my own "Keep comments brief" rule. If I think of more I'll post them later.
I agree that they are separate issues; but with enough specification they are interchangeable. Who knows if Microsoft's own specifications are precise enough, or even well-designed enough, to allow interchangeability. I wouldn't be surprised if a design requirement was to obfuscate internal structures merely to prevent easy interchangeability.
Really I don't think anyone would have had a problem if WININET was built into Windows, but the IE interface was sold separately and allowed anyone else to build similar items that plugged in appropriately, like HTML controls. After all, MS has made great big noise about how COM allows modular interchangeable components. But the fact that they gave it away for free and said it was a necessary part of windows is pure bullcrap-and-vomit-mixed-together.
Shared source isn't open source: >> you can't touch it, you can only look at it >> you can't produce something modified and redistribute it >> not all necessary source is included >> MS benefits because you find bugs, they get the money, and all you get is a warm fuzzy feeling >> I don't think everyone can look at it, only those who sign an NDA
Some of these points I'm not completely sure of, but Shared Source benefits Microsoft more than the recipient. A typical Redmond setup.
1. Release all source for obsolete and no-longer-supported operating systems. Why can't we find DOS to run those machines that need it? Why should Windows 3.x still be proprietary? This type of open source would allow the curious to tinker and allow teaching without worrying about "can I copy this stuff for my students" stuff.
Though this could be a good public relations idea, I don't think Microsoft will ever do it, because too many skeletons are hidden in the codebase-- DR-DOS FUD, anyone? Anyone? It would also act counter their sacred-cow "all PCs must have a licensed OS or be declared as EVIL" stance.
2. Allow some of their prominent developers to work on and support useful open-source projects. The type of project would be the nooks and crannies that MS doesn't care about and that won't eat at their current market.
Again, I don't think they would ever do this, because MS developers don't have any real-life time anyway. They'd also be paranoid that they might lose out on some proprietary opportunity that would bring them an extra $3.95 to plonk on their fuzzy balance sheet. As far as they're concerned, there are no niches in the market.
Unfortunately, it seems obvious to everyone that Microsoft has no conception of goodwill. If it can't be seen to bring in immediate profits, it's considered worthless. Notice they never gave anything to the education community until it presented itself as a way to entrench their monopoly further? But people might actually start to like them if they treated developers and users like worthwhile partners instead of paranoid enemies. Taking some of these steps would change our perception of them, but it doesn't seem they consider that of much value.
Yes, but there is a difference between IE as code and IE as an interface to access the Internet. To the user, what matters is the interface.
For the most part, the interface is where products make their major differentiation. No one would have had a problem if Microsoft had provided merely an Internet access API; but they had to make it visible and call it part of the OS. The visible part really shouldn't be part of the OS, IMHO. Why not an activation point to initiate the browser interface of choice? "No, IE is part of the OS." Bullcrap. WININET is part of the OS, IE is a bag on the side of Windows.
I actually use Quicken without any of its Internet browsing/access; it could be removed for all I care. Microsoft can intertwine IE all they want and call it broken if all the features don't work, but it's a dubious choice.
The reason for all this confusion has to be that our definitions are all fuzzy. Microsoft seems to love fuzzifying things to allow its doublespeak. Of course removing IE will mean Windows isn't Windows, but then removing Solitaire also would mean the same thing in the same sense, even though nothing breaks.
Windows has become (has always been?) more than an OS in the strictest sense: a set of interfaces accessible to code which allows other code--including itself--to control the various parts of the computer. For sanity's sake, an architecture of items such as user identity and authorization, component and subsystem abstraction, and consistent user interface are provided to promote a convenient and reliable operation.
Obviously there are parts of Windows that, when removed, cause no problems--such as Solitaire. Some are required for normal user interaction, such as the GUI, but really aren't strictly necessary. (Other OSes work just fine without a GUI, thank you, and are in some cases, desirable.)
Microsoft clouds the issue by pretending that these components can't be modularized, but they can. How else would something as "vital" as IE be downloadable and updatable, or something as "deep" as DirectX be installed with retail games? They also cloud the issue by claiming that they have to ship a broken Windows to comply, but that is patently false. No one is talking about breaking Windows, but replacing Microsoft's components with different, working ones. Instead of IE, you have Netscape; instead of Media Player, you have RealPlayer.
Of course Microsoft's real issue is that they know this componentization will lead to readily substitutable parts, even of the OS itself. Such commoditization destroys their precious, precious, selfish cash cow because all the interfaces are defined for each module. Then they would actually have to compete on the merits, a situation that they have studiously made extremely difficult for anyone else to do. The monopoly would be destroyed.
This also brings up a difficult, separate issue: who defines the interfaces? There's the initial Microsoft-defined ones, but after componentization occurs, what next? There is a benefit to a centralized control I think, but everyone wants to be in control here. Design by committee is notoriously difficult and slow--OpenGL 2.0, anyone?
Another issue is, are we really ready to regulate what Windows as a product may or may not contain, and how it should be designed? Microsoft would have to make some effort to clean up its interfaces and design, as well as create the specification documentation necessary to comply with this request. They could do it, but they would cry about the trillions of dollars they would be losing in the process, only to commoditize Windows and see the selling price drop over time. Gosh, competition! But who is best to regulate this? John Ashcroft? The Microsoft Oversight Committee? Good questions, but really Microsoft has brought all this consternation on itself as it pushes every moral boundary it can find in the name of legalism.
But the idea that modularizing Windows destroys the common interface that we all benefit from is preposterous. How does Netscape break the IE interface? How does RealPlayer counter common look-and-feel? And how does making these downloadable and updatable, in the same way that DirectX is, cause problems for the end user? It only requires a fully published API, which Microsoft steadfastly refuses. Who cares which one you have, as long as it meets the specifications? Oh, it's that merit thing again.
It doesn't seem to me that the states want Microsoft's money. I don't see any compensation requests in any proposals. The real issue is that Microsoft makes people angry, mostly by its questionable borderline and over-the-borderline behavior. Then they put on their "who, me?" face, and complain about how everyone is unfairly against them. I'm not sure whether it's reasonable to allow the DOJ or other parties to regulate Windows, but since Microsoft won't control it's monopoly in a non-predatory fashion, whom else do you suggest?
Slashdot Mirror
Well I guess I should insert my own foot. I found the text in the article I misread it to read "in an article", not "in the article".
And just where did you find this article? We slashdot nerds can handle active weblinks, you know. Or at least a reference to a tree-killing publication or something.
I was making an unstated assumption, but I indeed miscalculated.
The old Intel 16-bit x86 architecture had 32 bits for addressing in a segment:offset format. However, 12 of those bits were redundant; each upper-word segment referred to a 16-byte memory line, so that A000:0010 addressed the same byte as A001:0000 (at 20-bit address A0010). In order to compare long pointers as equivalent, you had to first convert them to a canonical format.
I was presuming that any new 16-bit architecture would not have to be real-mode compliant in this way, so that you would still use segment:offset but then get 32 bits out of the address space, meaing the same as existing 32-bit architectures. Somehow the twisted calculation in my head came out as 64MB. I must have lost a few binary orders of magnitude on the floor somewhere.
Please forgive.
Eventually 64 bit machines will be common, that's all modern software will be written for, and then you won't be able to use a 32-bit machine if you want to because the desired software won't be available.
So, while it's not mandatory, I'd definitely say It's The Future. --dv
It's troll because it incites people like me to correct you. See the definition for troll.
We don't need no stinkin' software, firmware will do it for us.
They put up the copy of the story BECAUSE THE ORIGINAL LINK WAS SLASHDOTTED. So it's remarkably convenient rather than having to way two days until all the nerds stop viewing the story. The original server and ISP will probably thank you as well; no one is trying to "get one over on copyright" here.
So quitcherbitchin.
--dv
That they're more popular than Linux and Mac machines, and make a better dispersion vector?
I lament the loss of distinction between geek and nerd. Other posts here have hinted at it, but I want to shout it from the monitor tops!
Nerds are the socially inept, technically super-competent intelligent tinkerers of the information- and technology-focused world. Geeks are the socially repulsive, generally stupid chicken-head-biters (traditionally) or booger-eating undesirables (modern) of everyday life.
I don't mind being called a nerd, but I AM NOT A GEEK <Elephant-Man-Music/>. Please maintain the distinction in your everyday lives and help educate those stupid Hollywood people who couldn't get a technical term straight if their multi-million dollar budgets depended on it.
Remember, you are the first defense against misuse of techspeak!!!
It also seems a problem in all US Northern Seaboard cities (Boston, Philadelphia, etc.). Boston has some of the worst roads as well. And this doesn't include the multi-fold volume of traffic per street mile.
I will however give a respectful nod to Canadian infrastructure, that seems to be able to produce sturdy reliable long-lasting roads. I don't really know for sure though whether the same techniques here would just continue to rupture year after year (thus making the expense too great), or if they're just too expensive in the first place.
--dv
*Almost*all* the crosswalks in NYC sport buttons. Almost none of them work (I haven't actually tested most of them though), because you can tell that the time that it takes for a WALK to show doesn't change when you press the button or don't. (As I stated in a previous reply to this story,) almost all traffic lights in NYC are timed and don't vary based on traffic conditions, like other areas of the country. They may vary based on time of day and even day of week, but I do an awful lot of stopping for nobody at red lights when I drive at 2 AM.
--dv
The real reason is that almost all NYC traffic lights are on a timer anyway. Unlike most areas of the country that have on-demand lights that are sensitive to traffic and keep green for the major roadway, if you wait a minute the light will change anyway. So why interrupt the rare possible synchronized goodness on a Manhattan avenue for the impatient pedestrian?
The downside to this timer approach is that you often wait for nobody at red lights at 3am. Stooopid lazy NYC planners.
Either that or the trigger antennas that they would need to place under the roadway can't take the winter punishment.
--dv
Is BG really saying that Microsoft has invented Internet communication between software apps? This sounds to me like a sly twisting of the State Of The Art. Hmmm... TCP / IP is just moving bits, but
Part of the problem may be that I don't understand
Please clarify my fuddled brain, or translate Bill-speak for me.
Well, technically lying (the deliberate telling of falsehood) is a subclass of deception. Deception is deliberate, like lying, but can include categories like camouflage, altered photographs, withholding information, redirection of attention, and duplicate part numbers for merchandise with differing specifications (as long as it's deliberate).
Please gentlemen and gentlewomen, let's keep our categories of vice appropriately defined.
--dv
>> corollary: "Trustworthy Computing" is sheer bunk until it appears in the digital flesh.
>> corollary: Microsoft is more interested in PR spin than actual truth. (or is that a lemma?)
2. Never trust anything anybody else says about Microsoft until it has been demonstrated that there is no financial or political relationship between the speaking party and Microsoft.
>> How many "grassroots campaigns" and "testimonials" and "benchmark reports" and "white papers" by supposedly disinterested third parties has Microsoft been exposed to have influenced unfairly? Did you run out of digits to count on? Borrow a few friends, I'll wait. My, your little office is getting crowded!
3. Follow the money. If it doesn't bring in more revenue, Microsoft doesn't care. Nits in the OS (GOD I hate the shutdown being the first item on the start menu, e.g.)? Big deal, they don't have to change it and you can't do anything about it BECAUSE YOU CLICKED YES ON THE EULA.
I'm not bitter, I'm just squashed helplessly into the ground by an indifferent greedy corporation.
Sigh.
Telemarketing has been a fact, but recent regulations have improved. You can now have your phone number added to a database which all US telemarketers must check before calling you. If they call you when if you are in that database, or if they call back after you have explicitly requested that they not call you back, they can be fined $500 for each violation (or some such fee). Perhaps not many people know of this database, but it does work and several telemarketers have been successfully sued for their violations. I still stand by my statements that regulations don't have to be incomprehensible, nor hinder normal use. I am unfamiliar with the "screening services" you mention, but I don't think anyone has to buy these to accomplish a reduction in telemarketing calls.
Telemarketing is less prevalent than spam though, because there has to actually be a live person on the other end (usually) to make it really work. But I see your point that e-mail is a different issue. It is international in scope and forgible in content.
The phone regulations work because the infrastructure is there to support it. E-mail does not have this infrastructure: phone calls are traceable, and centrally controllable while e-mail is potentially UNtraceable and not centralized.
Then perhaps what we need is a better infrastructure? A series of "trusted" servers perhaps, with required configurations? Some overseeing body to reject a server deemed irresponsible? That would also mean a centralized location for complaints... a big plan but perhaps necessary.
Another idea is to go after those who benefit. At some point there is a name or URL to visit or write. If they aren't the spammers, then they can provide who is or be shut down anyway. I know this approach has been taken by some mail administrators, but won't work unless it's applied consistently.
This all sounds like turning e-mail into the phone company, but I don't have another workable solution right now. Hmmmm.... more ideas, anyone?
--dv
You sound like a spammer to me. :-)
Your solution does not solve the problem whereby Internet bandwidth is wasted. The mail still goes to the end-user's pickup point, where some user-defined rules reject it.
In addition, spam is a part of a technology/counter-technology process: you write a filter, then the spammer writes cleverer things to get around the filter. It is a Hard Problem to write a tool that correctly rejects the spam and correctly saves the non-spam. Obviously you don't have this tool to provide for us, so you handwave as though it already existed.
Yes, regulation will result in higher cost, but not necessarily in "incomprehensible rules," nor will it necessarily "hinder normal use." Fax rules are pretty clear, and work well. We have regulations for various services because we need them. Why else would our phone system be regulated? Because the Ma Bell is a dirty greedy company that wants desperately to cut corners and provide us with inadequate service in order to raise profits. So with e-mail; prevent its abuse so that we can have adequate service and an unnecessarily diminished infrastructure.
The real problem is that spam costs the spammer nothing; the real costs are borne by the receiver and his intermediaries. A similar thing happened with fax adverts, where people were getting pages and pages of junk, using up paper (expensive!) and preventing the real faxes from getting through because the whole roll was used up before the night was through (though the sender might have had to pay phone charges). Junk p-mail behaves better because the costs are borne by the sender; p-mail advertisers are remarkably efficient in targeting end-users, using bulk-mail rates, and so on.
Maybe ISPs should charge for number of recipients that a sender sends to, but even this seems a Hard Problem with remote distribution lists appearing as a single recipient. But it seems to me that until the sender starts bearing some costs for extra recipients, the spam problem will remain.
--dv
It does make very good sense to me to use comments in the place of source control where such is not readily available or is overkill. But the comment example you provide actually gives useful necessary information separate from the date/person comments. I'd want to know about the race condition in any case as a general comment. What I really mean, is the person and date information useful enough to be kept in the code? After a while they become obsolete; either the person leaves or years go by and the code remains. I've seen comments in code saying it was added four years prior, or some section was commented out by a person long forgotten. Having a point of contact for the section of code is useful, but it is better to have the text explain itself. Really though, I split hairs here as we are both much more in line than at odds with each other.
I will have to admit though that none of these can be thought of as hard rules; there has to be a balance to them all. We have to also take into account team dynamics and agreed-upon procedures. I don't think I've ever been involved with a project that didn't make some kind of non-perfect requirements on the participants; either there were some procedural hoops or we didn't have good source control or the existing code couldn't be rewritten or something along those lines. So these are all rules made to be broken as appropriate.
About marking changes, I would argue that the best place for that information would be source control. Source control will allow you to diff the two to see what version put the new code in or took it out, and also allows a change comment which describes the difference. Change comments require that you know the history of the code, which not all readers will have.
:-).
As for why code was inserted, that is always relevant information for comments
I really like your idea about writing the comments first, however. I sometimes use this approach but honestly I don't do it often enough except where I'm having a difficult time getting my brain around a project. Probably because I don't use it, I didn't think to put it in-- my poor discipline is showing through.
Your idea about required standards in coding is also excellent. I prefer to use that approach but I often find it unpalatable to my coworkers because, well, herding programmers is like herding cats (or is that nailing jelly to the wall), and I don't have the dictatorial authority. Or the project already has lots of existing code. Rarely do I get to start anything.
Your other comments I think I mentioned already, but I agree with them.
I'm sure I have more of these somewhere but these are off the top of my head. Besides, I'm in danger of violating my own "Keep comments brief" rule. If I think of more I'll post them later.
I agree that they are separate issues; but with enough specification they are interchangeable. Who knows if Microsoft's own specifications are precise enough, or even well-designed enough, to allow interchangeability. I wouldn't be surprised if a design requirement was to obfuscate internal structures merely to prevent easy interchangeability.
Really I don't think anyone would have had a problem if WININET was built into Windows, but the IE interface was sold separately and allowed anyone else to build similar items that plugged in appropriately, like HTML controls. After all, MS has made great big noise about how COM allows modular interchangeable components. But the fact that they gave it away for free and said it was a necessary part of windows is pure bullcrap-and-vomit-mixed-together.
Shared source isn't open source:
>> you can't touch it, you can only look at it
>> you can't produce something modified and redistribute it
>> not all necessary source is included
>> MS benefits because you find bugs, they get the money, and all you get is a warm fuzzy feeling
>> I don't think everyone can look at it, only those who sign an NDA
Some of these points I'm not completely sure of, but Shared Source benefits Microsoft more than the recipient. A typical Redmond setup.
1. Release all source for obsolete and no-longer-supported operating systems. Why can't we find DOS to run those machines that need it? Why should Windows 3.x still be proprietary? This type of open source would allow the curious to tinker and allow teaching without worrying about "can I copy this stuff for my students" stuff.
Though this could be a good public relations idea, I don't think Microsoft will ever do it, because too many skeletons are hidden in the codebase-- DR-DOS FUD, anyone? Anyone? It would also act counter their sacred-cow "all PCs must have a licensed OS or be declared as EVIL" stance.
2. Allow some of their prominent developers to work on and support useful open-source projects. The type of project would be the nooks and crannies that MS doesn't care about and that won't eat at their current market.
Again, I don't think they would ever do this, because MS developers don't have any real-life time anyway. They'd also be paranoid that they might lose out on some proprietary opportunity that would bring them an extra $3.95 to plonk on their fuzzy balance sheet. As far as they're concerned, there are no niches in the market.
Unfortunately, it seems obvious to everyone that Microsoft has no conception of goodwill. If it can't be seen to bring in immediate profits, it's considered worthless. Notice they never gave anything to the education community until it presented itself as a way to entrench their monopoly further? But people might actually start to like them if they treated developers and users like worthwhile partners instead of paranoid enemies. Taking some of these steps would change our perception of them, but it doesn't seem they consider that of much value.
Yes, but there is a difference between IE as code and IE as an interface to access the Internet. To the user, what matters is the interface.
For the most part, the interface is where products make their major differentiation. No one would have had a problem if Microsoft had provided merely an Internet access API; but they had to make it visible and call it part of the OS. The visible part really shouldn't be part of the OS, IMHO. Why not an activation point to initiate the browser interface of choice? "No, IE is part of the OS." Bullcrap. WININET is part of the OS, IE is a bag on the side of Windows.
I actually use Quicken without any of its Internet browsing/access; it could be removed for all I care. Microsoft can intertwine IE all they want and call it broken if all the features don't work, but it's a dubious choice.
The reason for all this confusion has to be that our definitions are all fuzzy. Microsoft seems to love fuzzifying things to allow its doublespeak. Of course removing IE will mean Windows isn't Windows, but then removing Solitaire also would mean the same thing in the same sense, even though nothing breaks.
Windows has become (has always been?) more than an OS in the strictest sense: a set of interfaces accessible to code which allows other code--including itself--to control the various parts of the computer. For sanity's sake, an architecture of items such as user identity and authorization, component and subsystem abstraction, and consistent user interface are provided to promote a convenient and reliable operation.
Obviously there are parts of Windows that, when removed, cause no problems--such as Solitaire. Some are required for normal user interaction, such as the GUI, but really aren't strictly necessary. (Other OSes work just fine without a GUI, thank you, and are in some cases, desirable.)
Microsoft clouds the issue by pretending that these components can't be modularized, but they can. How else would something as "vital" as IE be downloadable and updatable, or something as "deep" as DirectX be installed with retail games? They also cloud the issue by claiming that they have to ship a broken Windows to comply, but that is patently false. No one is talking about breaking Windows, but replacing Microsoft's components with different, working ones. Instead of IE, you have Netscape; instead of Media Player, you have RealPlayer.
Of course Microsoft's real issue is that they know this componentization will lead to readily substitutable parts, even of the OS itself. Such commoditization destroys their precious, precious, selfish cash cow because all the interfaces are defined for each module. Then they would actually have to compete on the merits, a situation that they have studiously made extremely difficult for anyone else to do. The monopoly would be destroyed.
This also brings up a difficult, separate issue: who defines the interfaces? There's the initial Microsoft-defined ones, but after componentization occurs, what next? There is a benefit to a centralized control I think, but everyone wants to be in control here. Design by committee is notoriously difficult and slow--OpenGL 2.0, anyone?
Another issue is, are we really ready to regulate what Windows as a product may or may not contain, and how it should be designed? Microsoft would have to make some effort to clean up its interfaces and design, as well as create the specification documentation necessary to comply with this request. They could do it, but they would cry about the trillions of dollars they would be losing in the process, only to commoditize Windows and see the selling price drop over time. Gosh, competition! But who is best to regulate this? John Ashcroft? The Microsoft Oversight Committee? Good questions, but really Microsoft has brought all this consternation on itself as it pushes every moral boundary it can find in the name of legalism.
But the idea that modularizing Windows destroys the common interface that we all benefit from is preposterous. How does Netscape break the IE interface? How does RealPlayer counter common look-and-feel? And how does making these downloadable and updatable, in the same way that DirectX is, cause problems for the end user? It only requires a fully published API, which Microsoft steadfastly refuses. Who cares which one you have, as long as it meets the specifications? Oh, it's that merit thing again.
It doesn't seem to me that the states want Microsoft's money. I don't see any compensation requests in any proposals. The real issue is that Microsoft makes people angry, mostly by its questionable borderline and over-the-borderline behavior. Then they put on their "who, me?" face, and complain about how everyone is unfairly against them. I'm not sure whether it's reasonable to allow the DOJ or other parties to regulate Windows, but since Microsoft won't control it's monopoly in a non-predatory fashion, whom else do you suggest?