Right, because you have to give all your copies of magazines back when your subscription ends, right?
What you're describing is how certain people *want* the subscription model to work, because it forces lockin (cancel your subscription and you lose all your music, or your files, or your computer, etc). It's actually more of a lease. You can most certainly create a subscription model that doesn't require DRM. Heck, what do you think those CD buyer club things are?
In theory, you're supposed to be able to have 911 access from a landline even if you don't have service, just like you can dial 911 from a cell even if you don't have an account (Womens shelters often as for donations of old cell phones for this reason). However, at least in some places, your landline phone is physically disconnected when you cancel your service and no dial tone == no 911.
I had Vonage over a year ago, and the limitations, and what you could do to address those limitations, of were spelled out in great detail all over the Vonage web site and in the various emails they sent you when you signed up.
Re:Local powerful CPU still good for grid
on
The PC Is Not Dead
·
· Score: 1
Places like Pixar leverage this by pulling unused PCs into the renderfarm, using standard distributed tools. The problem with your scenario is that it's wasteful - think about it. The most usefull part of the "cluster" that PC could be powering is the applications that are running on it! The problem is that administering a network of independent machines is hard. The answer is not, as the naive and stereotypically anal-retentive admin might say, "pull everything back to the server". The answer is more and better remote administration and security tools. In reality, most of these tools exist today. Admins, as a rule, don't leverage them properly.
They actually do. A big poster at a Best Buy advertising this: "We put our pants on one leg a time, just like anyone else... but ours are polyester". There were others with similiarly transparent attempts at creating "geek cred".
10 PCs that can run, say, Office will be cheaper than one big machine than can run 10 copies of Office (plus virtualization overhead, of course). You need far, far more server resources to run all your applications at a central point than if you distribute them to your workstations. Further, you need to engineer a lot more reliability into those resources, because if they go away *everyone* is down, rather than one user. Basically, you can view an office full of workers as being a big collection of parellel computations. There's no need to run them all at a single point when you can run them all in parallel insteaad.
The problem, basically, is that IT administrators suck. Address that issue (with better tools, more admins, better training, whatever) and that will address the problems with PCs in the office. All the problems that thin-client environments claim to address are administrative, rather than technical.
In my experience, software costs *more* in a thin client environment, because you still need per-user licenses and you ALSO need to license the server. The cost savings is in administration. There's zero benefit in any other area.
Administration is where it makes sense, but I still think thin client is a step backward. A full-powered workstation is *cheaper* than a thin client. It's stupid to waste all this computing power, only to channel more and more money into more and more powerfull app servers. Better admin tools (and actually, despite the lack of pre-rolled tools, Linux actually shines here) are what we need, not a fall back to dumb terminals. We've got incredibly cheap computing power that would have been unimaginable even 20 years ago, lets not waste it all - design ways to leverage to power of workstations while alleviating the administrative overhead.
Actually, yes it does. That, in fact, is *precisely* what copyright is for - it protects a specific implementation of a work, *not* the ideas represented by that work. That's business want software patents, which they can use to prevent work-alike re-writes. Now, in the specific case of monopoly you're correct, although for the wrong reasons - the "work" involved in monopoly is not the materials the game pieces are made of, but the art of the board. In something of a stretch, the specific board layouts are also considered "works". But you absolutely could create your own version of monopoly, with identical game mechanics, so long as you created all your own artwork and had a re-designed board.
The problem of course is who decides how secret something is and when it shouldn't be a secret anymore. The government (the current administration moreso than most, but not *much* more) has a definite "make it secret" reflex. It's shocking to me how little outcry various abuses of that have been (like a redacted FOIA on an internal audit, where the redacted sections were exposed, and were revealed to be the parts of the audit where the agency failed). Sadly, although unsuprisingly, both the populace and the government have forgetten who's supposed to be the servant.
There's a plugin somewhere that works as an ActiveX host. The short answer is that while it's complicated, it's not insurmountable. Exposing the control to the Mozilla JS engine might be tricky.
Visual Studio 2003 is *not* written in.NET, no matter how many times people claim that, and Mono works fine on the Mac. Windows.Forms doesn't but, contrary to belief, it's not the only GUI option you have under.NET either.
Now, even though the rest of your post was wrong, you are correct that claiming that Mono has more cross-platform support than Java is silly.
More or less, yeah. HTML 3.2 was still supposed to conform to SGML, remember. It's implicit in the fact that tags and attributes not defined by the standard are not forbidden - they're permitted but don't have defined behavior, except that unsupported tags are defined as a no-op. That's why there's the old technique of bracketing the code inside a SCRIPT tag with an HTML comment, if you remember. I didn't say it was a very good standard, it's not. But it *is* a "web standard".
Yes, but people aren't saying "Slashcodes HTML is written in a poor style thats hard to parse and should be updated", they're screaming about lack of compliance with web standards, as if XHTML Strict is the only web standard there is. Say what you really mean.
Well, there's no such thing as an invalid attributes or element in HTML 3.2 (the standard explicitly allows for attributes beyond the standard ones, although the validator tosses a warning). 3.2 doesn't require a character encoding, either. You're mistaking "conforms with a poor standard I don't approve of" with "doesn't conform with web standards". Which is not to say that updating Slashcode to deliver something a little more modern wouldn't be a good thing. But say what you mean instead of blathering about "web standards", which doesn't mean what you think it means.
Since 3 people all posted the same thing, I'm going to respond to the first and the last. The w3c validator is much stricter than the standard as written. Slashcode actually stands up quite well against the written standard. For example, closing LI tags are flagged by the validator but not required by the standard.
The w3c validator is quite a bit stricter than the standard as written. Compare Slashcodes HTML to the actual text of the standard and you'll find many fewer errors.
Well, what parts of CSS2? And how many browsers support CSS2? Whats the market penetration of those browsers? HTML+CSS is a piss-poor way of presenting anything and it's no wonder that there's so many inconsistent implementations. If the W3C had never gotten on it's goddamn semantic web kick, and everyone accepted that HTML was a rich-text format and not some ridiculous attempt at "semtantic markup" the web would be a much better place. If you really want to store your data as semantic markup, use XML (NOT XHTML!) and do a server-side transform to rich-text HTML, just like you'd do a transform to PDF.
Slashdot declares HTML version 3.2, and the w3c validator is actually much stricter than the written standard. For example, you don't need to close LI elements, as they are implicitly closed by the next LI element. Same with non-standard attributes and even tags - the spec explicity defines behavior for undefined attributes and tags, which is a no-op. It should be a warning that you may be relying on non-standard behavior, but the standard does not prohibit them. Even the missing table end tag may be permitted under the standard, although I'd have to do some digging to check. There's something about block level elements and implicit closing by a new block element that I'd have to get the exact wording on. It's why you don't need a close tag for P elements in HTML 3.2, for example.
But if I had a supervisor or co-worker who saw fit to lie to my face, I would have bigger issues with my job than the ownership of some code
Well, no, you wouldn't. You'd have exactly those problems. The lesson here is, sadly, never every trust your boss. Which is too bad. Especailly when it comes to IP, and even more especially if you're someone who's livelihood depends on IP, get *everything* in writing, notarized, signed by legal, etc, etc, etc.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
If you're getting segfaults when you cast in C++ you need to smack yourself. dynamic_cast is there for a reason.
Cast stone is actually a real thing, a method of casting using concrete. Apparently it dates back almost 1000 years, so it's certainly old enough to be the origin of "cast in stone". However, my understanding of the origins of the term are that it had to do with the final version of a mold for a bronze statue, with design versions being done in clay.
Oh, and it's "moot point" (no idea where the word moot comes from) and "hear, hear" (as in "we hear you". Or "preach it!").
Slashdot Mirror
What you're describing is how certain people *want* the subscription model to work, because it forces lockin (cancel your subscription and you lose all your music, or your files, or your computer, etc). It's actually more of a lease. You can most certainly create a subscription model that doesn't require DRM. Heck, what do you think those CD buyer club things are?
In theory, you're supposed to be able to have 911 access from a landline even if you don't have service, just like you can dial 911 from a cell even if you don't have an account (Womens shelters often as for donations of old cell phones for this reason). However, at least in some places, your landline phone is physically disconnected when you cancel your service and no dial tone == no 911.
I had Vonage over a year ago, and the limitations, and what you could do to address those limitations, of were spelled out in great detail all over the Vonage web site and in the various emails they sent you when you signed up.
Places like Pixar leverage this by pulling unused PCs into the renderfarm, using standard distributed tools. The problem with your scenario is that it's wasteful - think about it. The most usefull part of the "cluster" that PC could be powering is the applications that are running on it! The problem is that administering a network of independent machines is hard. The answer is not, as the naive and stereotypically anal-retentive admin might say, "pull everything back to the server". The answer is more and better remote administration and security tools. In reality, most of these tools exist today. Admins, as a rule, don't leverage them properly.
They actually do. A big poster at a Best Buy advertising this: "We put our pants on one leg a time, just like anyone else... but ours are polyester". There were others with similiarly transparent attempts at creating "geek cred".
The problem, basically, is that IT administrators suck. Address that issue (with better tools, more admins, better training, whatever) and that will address the problems with PCs in the office. All the problems that thin-client environments claim to address are administrative, rather than technical.
In my experience, software costs *more* in a thin client environment, because you still need per-user licenses and you ALSO need to license the server. The cost savings is in administration. There's zero benefit in any other area.
Administration is where it makes sense, but I still think thin client is a step backward. A full-powered workstation is *cheaper* than a thin client. It's stupid to waste all this computing power, only to channel more and more money into more and more powerfull app servers. Better admin tools (and actually, despite the lack of pre-rolled tools, Linux actually shines here) are what we need, not a fall back to dumb terminals. We've got incredibly cheap computing power that would have been unimaginable even 20 years ago, lets not waste it all - design ways to leverage to power of workstations while alleviating the administrative overhead.
Actually, yes it does. That, in fact, is *precisely* what copyright is for - it protects a specific implementation of a work, *not* the ideas represented by that work. That's business want software patents, which they can use to prevent work-alike re-writes. Now, in the specific case of monopoly you're correct, although for the wrong reasons - the "work" involved in monopoly is not the materials the game pieces are made of, but the art of the board. In something of a stretch, the specific board layouts are also considered "works". But you absolutely could create your own version of monopoly, with identical game mechanics, so long as you created all your own artwork and had a re-designed board.
The problem of course is who decides how secret something is and when it shouldn't be a secret anymore. The government (the current administration moreso than most, but not *much* more) has a definite "make it secret" reflex. It's shocking to me how little outcry various abuses of that have been (like a redacted FOIA on an internal audit, where the redacted sections were exposed, and were revealed to be the parts of the audit where the agency failed). Sadly, although unsuprisingly, both the populace and the government have forgetten who's supposed to be the servant.
There's a plugin somewhere that works as an ActiveX host. The short answer is that while it's complicated, it's not insurmountable. Exposing the control to the Mozilla JS engine might be tricky.
Sadly, this license is not GPL compatable, so this new client won't show up in Debian.
Now, even though the rest of your post was wrong, you are correct that claiming that Mono has more cross-platform support than Java is silly.
As I understand it, it's one day a week and Google owns the IP. It's basically like free play in kindergarden.
More or less, yeah. HTML 3.2 was still supposed to conform to SGML, remember. It's implicit in the fact that tags and attributes not defined by the standard are not forbidden - they're permitted but don't have defined behavior, except that unsupported tags are defined as a no-op. That's why there's the old technique of bracketing the code inside a SCRIPT tag with an HTML comment, if you remember. I didn't say it was a very good standard, it's not. But it *is* a "web standard".
Yes, but people aren't saying "Slashcodes HTML is written in a poor style thats hard to parse and should be updated", they're screaming about lack of compliance with web standards, as if XHTML Strict is the only web standard there is. Say what you really mean.
Well, there's no such thing as an invalid attributes or element in HTML 3.2 (the standard explicitly allows for attributes beyond the standard ones, although the validator tosses a warning). 3.2 doesn't require a character encoding, either. You're mistaking "conforms with a poor standard I don't approve of" with "doesn't conform with web standards". Which is not to say that updating Slashcode to deliver something a little more modern wouldn't be a good thing. But say what you mean instead of blathering about "web standards", which doesn't mean what you think it means.
Since 3 people all posted the same thing, I'm going to respond to the first and the last. The w3c validator is much stricter than the standard as written. Slashcode actually stands up quite well against the written standard. For example, closing LI tags are flagged by the validator but not required by the standard.
The w3c validator is quite a bit stricter than the standard as written. Compare Slashcodes HTML to the actual text of the standard and you'll find many fewer errors.
Slashdot actually adheres quite reasonably to HTML 3.2. You might not *like* that web standard, but it is one.
Well, what parts of CSS2? And how many browsers support CSS2? Whats the market penetration of those browsers? HTML+CSS is a piss-poor way of presenting anything and it's no wonder that there's so many inconsistent implementations. If the W3C had never gotten on it's goddamn semantic web kick, and everyone accepted that HTML was a rich-text format and not some ridiculous attempt at "semtantic markup" the web would be a much better place. If you really want to store your data as semantic markup, use XML (NOT XHTML!) and do a server-side transform to rich-text HTML, just like you'd do a transform to PDF.
Slashdot declares HTML version 3.2, and the w3c validator is actually much stricter than the written standard. For example, you don't need to close LI elements, as they are implicitly closed by the next LI element. Same with non-standard attributes and even tags - the spec explicity defines behavior for undefined attributes and tags, which is a no-op. It should be a warning that you may be relying on non-standard behavior, but the standard does not prohibit them. Even the missing table end tag may be permitted under the standard, although I'd have to do some digging to check. There's something about block level elements and implicit closing by a new block element that I'd have to get the exact wording on. It's why you don't need a close tag for P elements in HTML 3.2, for example.
Well, no, you wouldn't. You'd have exactly those problems. The lesson here is, sadly, never every trust your boss. Which is too bad. Especailly when it comes to IP, and even more especially if you're someone who's livelihood depends on IP, get *everything* in writing, notarized, signed by legal, etc, etc, etc.
If you're getting segfaults when you cast in C++ you need to smack yourself. dynamic_cast is there for a reason.
Oh, and it's "moot point" (no idea where the word moot comes from) and "hear, hear" (as in "we hear you". Or "preach it!").