That's why you have 1% of the market and 1 million developers, instead of 90% of the market and 10 million developers.
If someone in your "world" would have bothered to code a Visual Basic clone, a good enough IDE/glue language for OO.org that actually worked and a RDBMS with basic features like triggers, relational integrity and stored procedures back in 2000 the world would be very different today. But alas, you don't have these "problems".
BTW, you're also insulting a few hundred thousand Python, Perl and Ruby developers. Way to go.
You're just another Slashbot spreading FUD. I realize "OMFG TEH API DOCS THEY SUX AND M$ RUINED MY LIFE" bullshit goes a long way around here, but at least don't be surprised when someone calls you on it. There are a lot of things wrong with MSDN, but you picked the wrong one to bitch over.
Obviously, since you are so quick to pronouce this suit bullshit before it has even been heard, based on a single news article
We've been here before, haven't we? In all cases the lawsuits were groundless. Yet the companies (and those of us indeirectly affected) got screwed.
Yes I am. "I have a list but I don't want to bother posting it." Bullshit.
- Contractors were not allowed to participate in "team building events", which unfortunately were never clearly defined and often included discussions about the project(s). As a result, I sometimes wasn't sure if I was allowed to attend an offsite meeting because the company was catering it.
- Contractors were not allowed to participate in "personal events" or some such, which included the occasional 30-minute employee birthday with cake, soda and whatnot. When asked by someone half-joking if we could still "have cake" the woman explaining all this to us (who wasn't an employee of the company) got very serious and replied "absolutely not, sorry". This was theretofore known as the "no cake" rule.
- Related to the above, I was not allowed to give even a simple birthday or "thank you" card to an employee that I had been working closely with for a year.
- Contractors were not allowed to attend lunch meetings outside the company grounds unless our consulting firm agreed to be billed for the meal. Needless to say I stopped going to those.
- Contractors were not allowed to stay after hours unless an employee was present. This got dropped pretty quickly since employees tended to disappear at 4:00 PM and we couldn't do shit because half the time we were catching up from lost time dealing with them during the day.
- Contractors were not allowed to interact directly with internal IT clients (the users). This also went to hell quickly because we were the only ones that knew how things worked.
- Some employees started to make arbitrary distinctions between "badges". Which is to say, for some reason they'd have to talk to the project manager about something instead of coming to us directly. This was not a rule, but it was a result of the rules.
- Contractors were moved to different cubicles that were not directly next to employee cubes. This went to hell quickly as well.
- Contractors were told to "tone it down" in regards to things like harmless practical jokes (cube redesign and so on).
All this in an environment within a company that was incredibly permissive, relaxed and fun to work in. Eventually the "rules" were dropped and no manager enforced them in any way. But that took about a year.
Your move.
Fuck you.
No. I have worked as a temp in the chemical industries, however
Bullshit, I don't believe you. You're full of "hot air".
I've been subject to the same scam
That's just too fucking bad, isn't it?
You are not free to enter into an illegal contract
Like I said, don't fucking sign it. It's not rocket science, after all.
No, the losing defendants are. If they had no cause of action, the plaintiffs wouldn't file.
Yes, of course. How could I think otherwise? I mean, it's not like I've ever heard of bullshit lawsuits before.
Of course not. You haven't got the goods. This is just hot air.
LOL, are you saying I'm making this shit up? You're quite the piece of work. I suppose I could safely assume you've never been in that situation, correct? Silly me, I've only been a consultant for close to 10 years. I must be full of "hot air".
No shit. They knew what was up. Your presence was a threat from management. "We don't really need permanent employees."
Ah. Let me guess - you used to be an employee and got shafted by a company, who then hired a temp (or consultant if we're talking above burger flipping or bubble wrapping) in your place, correct?
In any case, since you seem to be so ignorant as to how this whole thing works, please don't assume I was in a situation where I was a "threat" to anyone or being "used" in that fashion. Consulting is a win-win relationship when done right - the company gets skills that they don't possess in-house and don't care to make an investment in, and I make some money helping them use technology. Is this much over your head yet?
What's the fuss?
Not only are you stupid, you're also devoid of self-respect and honesty. Some of us actually enjoy doing a good job and earning our money while we're at it.
Not if the contract is used to get around labor laws, you aren't
Don't fucking sign it then. This is still a free country, after all.
BTW, I'm sorry a consultant abused you when you were a babe. We do have some bad apples in the bunch.
I've been writing Win32 code for 10 years and I've never seen "other flags" used there. And STACK_SIZE_PARAM_IS_A_RESERVATION is rarely used because it's safer to just set the stack reserve in the app's image header, though that is supported under WinXP/2003. You usually use CREATE_SUSPENDED, and even that is rare.
These stupid fuckers are screwing all the other people in this country who make their living as temps, or more importantly, as in-place consultants.
I remember the fallout from the AOL/Microsoft temp lawsuits. Companies started to restrict the ways a consultant could interact with their employees and dramatically restricted the things you could and could not do in your day to day dealings with everyone inside the company, therefore making it difficult to do your job.
Some of the restrictions and "rules" were down right retarded. I won't even bother mentioning them. The relationships with permanent employees (often in the same friggin' project) were strained and sometimes became akward. "Relationship advisors" were brought in to explain to us why we couldn't do this-or-the-other. I could care less about the "let's hold hands and sing Kumbaya" crap, but LET ME DO MY JOB FERSSAKES. You're effin' paying for it anyway.
These assholes should be counter-sued by HP and taken to pound-me-in-the-ass federal prison for this frivolous bullshit. YOU'RE A CONTRACT WORKER FOR THE LOVE OF ZOD!! What part of that do they not understand? But noooo, HP is going to settle for nine gazillion dollars and those of us who can deal with reality will be fucked for another four years until this fades from the memory of managers everywhere.
I can see how this is valuable in the case of lost cards that are found by some enterprising soul, but isn't the majority of credit card fraud comitted through phone/internet these days? And considering that you are normally liable for about $0 these days (depending on your issuer), isn't this just too much hassle for the return?
ROFL, don't get your panties all in a bunch. I don't "think" that, I know. That's the baseline support policy, that's how it works. If you have a premier support agreement and/or a TAM contact in your regional office I suggest you give them a call and ask them. Maybe that will lessen the pressure in your skull, who knows.
Ok, you want more Windows apps that use custom widgets?
Congratulations, you just made my point. Are these 7 applications supposed to be a significant cross-section of the actual Windows application base, or am I missing something?
The point for me isn't that on Windows they don't need to load extra libraries, it's the fact that it's so inconsistent (and often really ugly).
This has nothing to do with the issue at hand. If I choose to ship a crappy app that does '1337' skinning, that's my problem. It does not confirm or invalidate the fact that I still have a standard to which I could have coded it.
looks far more consistent than a relatively equivalent Windows experience
The problem with Linux is that there is no standard. I cannot code a simple app and expect that it will work on every distro, unless I write a pure X deal, which will look like shit. OTOH, with Windows I can code to the lowest common denominator and still get decent functionality because I'm using a standard. Both the OS itself has a set of native widgets that have changed very little in 12 years and are fully backwards compatible, and the Common Controls 4.0 (Windows 95) and higher are also guaranteed to be there and be fully backwards compatible. Can you say the same thing about your current Linux distro? Of course not. With Linux I have to ship GTK, Qt or beg that the user makes sure he has Athena or Lesstif or [whatever] installed and then cross my fingers. Further, widget libraries often have breaking changes between major versions. AbiWord is one of the major applications that has been broken by changes in the GTK API, and that's just one example.
Now, shipping GTK or whatever is not a big deal. But the fact remains that the Linux GUI 'experience' - as you call it - is fragmented, inconsistent and generally hard to support from a development POV.
You just made a completely random and unsupported claim
Really now. I don't know why this is "so hard to grasp". If it works on XP and is less than 8 years old that means it goes into Longhorn and it is supported on it. Do you have any idea how many VB6 apps are out there? That tinfoil hat of yours must be darn tight for you to suspect the VB6 runtime will cease to function or will be unsupported or removed on/from the next version of the OS. Perhaps you'd like to substantiate your claim?
Microsoft is under no obligation to make it work
Which is the flaw in your argument. They are obligated to make it work as much as they are obligated to make everything else that is less than 8 years old (or at their discretion, older) work. Again, if you have some bit of information that contradicts that I'd like to see it.
and you can repeat this post, replacing 'Longhorn' with 'Thing after Longhorn' then 'XP' with 'Longhorn'.
That's nice, but I'm talking about the Longhorn timeframe and MSFT's baseline/extended support policy for things that are considered part of the core Windows library stack. I have no idea what comes after that, nor do I care.
Just because Microsoft keeps VB working on XP for the next 7+ years doesn't mean it will ever work in Longhorn
Right. See, here's the thing: the VB runtime ships with XP. It's considered part of the core OS install. There are parts of the OS itself that require it (for example, the spyware thing they bought from Giant), and so it needs to follow the 5+3 rule the same way everything else does. That means that VB6 apps will run on Longhorn, just as VB3 apps run on XP today. Your calculator example is a bit retarded because it's not a system component, but an accessory. Does that makes sense?
Next time, take a moment to inform yourself before you call someone "stupid", because it makes you look... well, stupid.
The article mentioned "WS-Security" - but I have no idea what that is
That's probably your problem. It's a standard used with SOAP message exchanges. It provides authentication, integrity and confidentiality (nee encryption and a few other things).
As long as you trust the.NET framework (as far as its ability to protect you from, say, buffer overflows) then the WSS implementation for Indigo should be safe enough to use. It would be no different from anything written with JNI, for example.
There are NO pointers to worry about and all low level stuff is handled by the windows VBRUN.DLL's. This makes VB applications MORE secure than any other application, because it is physically impossible to get buffer overruns (the cause of 98% of all security problems)
This is a little disingenious. VB is a safe platform, not necessarily a secure one. IOW, your argument about pointers is true only in the sense that pointers can be dangerous for your code, because it's easier to screw them up. So the integrity of your code is ensured to a certain extent.
The VB runtime however is another matter. I'm not saying it has exploitable vulnerabilities, but OTOH I can't say it doesn't because applications written with VB are rarely exposed to the world and are rarely in a situation where they can be attacked the same way you have opportunities to attack, say, Perl or Java apps.
Slashdot Mirror
Slashdot, we have a winner.
You managed to avoid insulting and harrassing the interviewee (is that a word?) like you've done in the past. Very good.
problems we don't have in the Free Software world
That's why you have 1% of the market and 1 million developers, instead of 90% of the market and 10 million developers.
If someone in your "world" would have bothered to code a Visual Basic clone, a good enough IDE/glue language for OO.org that actually worked and a RDBMS with basic features like triggers, relational integrity and stored procedures back in 2000 the world would be very different today. But alas, you don't have these "problems".
BTW, you're also insulting a few hundred thousand Python, Perl and Ruby developers. Way to go.
You're just another Slashbot spreading FUD. I realize "OMFG TEH API DOCS THEY SUX AND M$ RUINED MY LIFE" bullshit goes a long way around here, but at least don't be surprised when someone calls you on it. There are a lot of things wrong with MSDN, but you picked the wrong one to bitch over.
We've been here before, haven't we? In all cases the lawsuits were groundless. Yet the companies (and those of us indeirectly affected) got screwed.
Yes I am. "I have a list but I don't want to bother posting it." Bullshit.
- Contractors were not allowed to participate in "team building events", which unfortunately were never clearly defined and often included discussions about the project(s). As a result, I sometimes wasn't sure if I was allowed to attend an offsite meeting because the company was catering it.
- Contractors were not allowed to participate in "personal events" or some such, which included the occasional 30-minute employee birthday with cake, soda and whatnot. When asked by someone half-joking if we could still "have cake" the woman explaining all this to us (who wasn't an employee of the company) got very serious and replied "absolutely not, sorry". This was theretofore known as the "no cake" rule.
- Related to the above, I was not allowed to give even a simple birthday or "thank you" card to an employee that I had been working closely with for a year.
- Contractors were not allowed to attend lunch meetings outside the company grounds unless our consulting firm agreed to be billed for the meal. Needless to say I stopped going to those.
- Contractors were not allowed to stay after hours unless an employee was present. This got dropped pretty quickly since employees tended to disappear at 4:00 PM and we couldn't do shit because half the time we were catching up from lost time dealing with them during the day.
- Contractors were not allowed to interact directly with internal IT clients (the users). This also went to hell quickly because we were the only ones that knew how things worked.
- Some employees started to make arbitrary distinctions between "badges". Which is to say, for some reason they'd have to talk to the project manager about something instead of coming to us directly. This was not a rule, but it was a result of the rules.
- Contractors were moved to different cubicles that were not directly next to employee cubes. This went to hell quickly as well.
- Contractors were told to "tone it down" in regards to things like harmless practical jokes (cube redesign and so on).
All this in an environment within a company that was incredibly permissive, relaxed and fun to work in. Eventually the "rules" were dropped and no manager enforced them in any way. But that took about a year.
Your move.
Fuck you.
No. I have worked as a temp in the chemical industries, however
Bullshit, I don't believe you. You're full of "hot air".
I've been subject to the same scam
That's just too fucking bad, isn't it?
You are not free to enter into an illegal contract
Like I said, don't fucking sign it. It's not rocket science, after all.
Press 1 + A + COIN RETURN for more options, including misc keygens and ketchup.
Yes, of course. How could I think otherwise? I mean, it's not like I've ever heard of bullshit lawsuits before.
Of course not. You haven't got the goods. This is just hot air.
LOL, are you saying I'm making this shit up? You're quite the piece of work. I suppose I could safely assume you've never been in that situation, correct? Silly me, I've only been a consultant for close to 10 years. I must be full of "hot air".
No shit. They knew what was up. Your presence was a threat from management. "We don't really need permanent employees."
Ah. Let me guess - you used to be an employee and got shafted by a company, who then hired a temp (or consultant if we're talking above burger flipping or bubble wrapping) in your place, correct?
In any case, since you seem to be so ignorant as to how this whole thing works, please don't assume I was in a situation where I was a "threat" to anyone or being "used" in that fashion. Consulting is a win-win relationship when done right - the company gets skills that they don't possess in-house and don't care to make an investment in, and I make some money helping them use technology. Is this much over your head yet?
What's the fuss?
Not only are you stupid, you're also devoid of self-respect and honesty. Some of us actually enjoy doing a good job and earning our money while we're at it.
Not if the contract is used to get around labor laws, you aren't
Don't fucking sign it then. This is still a free country, after all.
BTW, I'm sorry a consultant abused you when you were a babe. We do have some bad apples in the bunch.
That makes a lot of sense, yes. Hey, I knew a company in the 80s that had a bunch of Tandys! You're right!
Jeez.
What other flags have you seen used?
What part of this did you not understand? What's the parameter that is not documented?
I remember the fallout from the AOL/Microsoft temp lawsuits. Companies started to restrict the ways a consultant could interact with their employees and dramatically restricted the things you could and could not do in your day to day dealings with everyone inside the company, therefore making it difficult to do your job.
Some of the restrictions and "rules" were down right retarded. I won't even bother mentioning them. The relationships with permanent employees (often in the same friggin' project) were strained and sometimes became akward. "Relationship advisors" were brought in to explain to us why we couldn't do this-or-the-other. I could care less about the "let's hold hands and sing Kumbaya" crap, but LET ME DO MY JOB FERSSAKES. You're effin' paying for it anyway.
These assholes should be counter-sued by HP and taken to pound-me-in-the-ass federal prison for this frivolous bullshit. YOU'RE A CONTRACT WORKER FOR THE LOVE OF ZOD!! What part of that do they not understand? But noooo, HP is going to settle for nine gazillion dollars and those of us who can deal with reality will be fucked for another four years until this fades from the memory of managers everywhere.
Cripes these things piss me off.
[ouch]
OK, but that's not what it says in the article submission. That's the point.
I can see how this is valuable in the case of lost cards that are found by some enterprising soul, but isn't the majority of credit card fraud comitted through phone/internet these days? And considering that you are normally liable for about $0 these days (depending on your issuer), isn't this just too much hassle for the return?
Kudos to the submitter, propz unlimited and all that.
But that doesn't mean I think it's useless or flawed.
Ever code against Kerberos? Complicated as hell, yet an industry standard OS-agnostic solution for domain authentication.
As far as not trusting Microsoft, well, that's your prerogative.
ROFL, don't get your panties all in a bunch. I don't "think" that, I know. That's the baseline support policy, that's how it works. If you have a premier support agreement and/or a TAM contact in your regional office I suggest you give them a call and ask them. Maybe that will lessen the pressure in your skull, who knows.
I guess they can expect a nastygram from Stallman any day now.
Congratulations, you just made my point. Are these 7 applications supposed to be a significant cross-section of the actual Windows application base, or am I missing something?
The point for me isn't that on Windows they don't need to load extra libraries, it's the fact that it's so inconsistent (and often really ugly).
This has nothing to do with the issue at hand. If I choose to ship a crappy app that does '1337' skinning, that's my problem. It does not confirm or invalidate the fact that I still have a standard to which I could have coded it.
looks far more consistent than a relatively equivalent Windows experience
The problem with Linux is that there is no standard. I cannot code a simple app and expect that it will work on every distro, unless I write a pure X deal, which will look like shit. OTOH, with Windows I can code to the lowest common denominator and still get decent functionality because I'm using a standard. Both the OS itself has a set of native widgets that have changed very little in 12 years and are fully backwards compatible, and the Common Controls 4.0 (Windows 95) and higher are also guaranteed to be there and be fully backwards compatible. Can you say the same thing about your current Linux distro? Of course not. With Linux I have to ship GTK, Qt or beg that the user makes sure he has Athena or Lesstif or [whatever] installed and then cross my fingers. Further, widget libraries often have breaking changes between major versions. AbiWord is one of the major applications that has been broken by changes in the GTK API, and that's just one example.
Now, shipping GTK or whatever is not a big deal. But the fact remains that the Linux GUI 'experience' - as you call it - is fragmented, inconsistent and generally hard to support from a development POV.
Please let it be Monica Bellucci, please. A Wonder Woman with an italian accent is really not that big a deal, right? C'mon. Please. Please?
Really now. I don't know why this is "so hard to grasp". If it works on XP and is less than 8 years old that means it goes into Longhorn and it is supported on it. Do you have any idea how many VB6 apps are out there? That tinfoil hat of yours must be darn tight for you to suspect the VB6 runtime will cease to function or will be unsupported or removed on/from the next version of the OS. Perhaps you'd like to substantiate your claim?
Microsoft is under no obligation to make it work
Which is the flaw in your argument. They are obligated to make it work as much as they are obligated to make everything else that is less than 8 years old (or at their discretion, older) work. Again, if you have some bit of information that contradicts that I'd like to see it.
and you can repeat this post, replacing 'Longhorn' with 'Thing after Longhorn' then 'XP' with 'Longhorn'.
That's nice, but I'm talking about the Longhorn timeframe and MSFT's baseline/extended support policy for things that are considered part of the core Windows library stack. I have no idea what comes after that, nor do I care.
No... no, I'm pretty sure I'm not.
Just because Microsoft keeps VB working on XP for the next 7+ years doesn't mean it will ever work in Longhorn
Right. See, here's the thing: the VB runtime ships with XP. It's considered part of the core OS install. There are parts of the OS itself that require it (for example, the spyware thing they bought from Giant), and so it needs to follow the 5+3 rule the same way everything else does. That means that VB6 apps will run on Longhorn, just as VB3 apps run on XP today. Your calculator example is a bit retarded because it's not a system component, but an accessory. Does that makes sense?
Next time, take a moment to inform yourself before you call someone "stupid", because it makes you look... well, stupid.
That's probably your problem. It's a standard used with SOAP message exchanges. It provides authentication, integrity and confidentiality (nee encryption and a few other things).
As long as you trust the .NET framework (as far as its ability to protect you from, say, buffer overflows) then the WSS implementation for Indigo should be safe enough to use. It would be no different from anything written with JNI, for example.
This is a little disingenious. VB is a safe platform, not necessarily a secure one. IOW, your argument about pointers is true only in the sense that pointers can be dangerous for your code, because it's easier to screw them up. So the integrity of your code is ensured to a certain extent.
The VB runtime however is another matter. I'm not saying it has exploitable vulnerabilities, but OTOH I can't say it doesn't because applications written with VB are rarely exposed to the world and are rarely in a situation where they can be attacked the same way you have opportunities to attack, say, Perl or Java apps.