Except, of course, that whole license crap is a load of horseshit. It's looks like a sale, it's treated as a sale, it's LISTED as a fucking sale in FCC documents, it's a sale. It's not a licenseing. There's no license. There's no signatures (EULA dialogs don't meet federal standards for electronic signatures by a long shot). There's no contract (there has to be consideration in contracts, and there's none in an EULA). If they want to license software, they need to do it right - and that means that every single person who buys software from you needs to be offered an agreement, agree to it, SIGN it (copies for both of you), and THEN, and only then, gets the software.
The commercial software industry is fucked up. It wants excemptions from responsibility that would be the envy of any other industry, while at the same time making it's own laws about the allowed use of it's products - with no chance for competition, because you're (supposedly) bound by the agreement AFTER you've paid! It's a travesty. At some point, there WILL be a shakedown and this sort of nonsense will either go away or be codified in real law - at which point we'll all be felons, and the bottom will drop out of the personal computer industry - because at that point we're essentially allowing anyone who sells software to write law, and you WILL start seeing things like EULAs that require you to give up your children.
Don't think that all the lawyers at MS don't know this, either. It's why they consistently shy away from cases involving EULAs, either winning them on other points or settling out of court. They KNOW that if push comes to shove, the concept of the EULA as a legally binding document can't stand.
Here's something to consider - there's not 1 single thing that makes it illegal for you to bypass an installer and just avoid an EULA entirely. Not even the DMCA - although you'd (probably) run afoul of it if you tried to distribute tools that did such a thing. Not that an installer is a copy protection device by any stretch of the imagination, but there you go.
Well, I don't feel like arguing the legal power of EULAs here - this has to do with the moral right of a company to do this sort of thing. And MS doesn't jack to do with WINE support - they don't even have to think about it. Anyone who is going to run any MS product under WINE isn't going to get any help from MS, and that's all they need to know. An attempt (legally enforcable or not) to prevent people from doing it is reprehensible, and there is NO justification for it whatsoever beyond an attempt to bind applications to Windows that don't need to be.
FYI, you can't get patches to VFP through windows update.
This is a very simple concept - MS has no obligation to people using WINE. None. Zero. Zilch. It doesn't matter that they can't get patches via Windows Update. They're running on an unsupported OS, and that means UNSUPPORTED. It's very simple. You think they're threatning people with legal action because they want to make sure they get support? I can't help but think you're being intentionally blind.
There are a LOT of things you can't do remotely, even with the resource tools. Try unloading an isapi plugin from IIS so you can install a new verion. Huge pain in the butt when you're developing. Inability to overwrite libraries or applications that're loaded in memory is a big weakness of Windows, imo - it's probably the biggest single cause of rebooting at installations (with 2k/XP, at long last, you can do almost everything else except install new low-level hardware drivers without a reboot).
No, it's not. Theoretically, an EULA is a legally binding document - you're saying it's reasonable for a company to be able to (legally) require you to use a specific OS, whether or not it's required from a technical standpoint (it's obviously not, in this case, since it works). That's absurd, especially when the company in question is an OS company. It's tied directly to all the old arguments about monopolies and abusive behavior. They're perfectly justified in refusing support to anyone who's trying to run it under a non-authorized system, but bringing legal force to bear on someone who is doing so, or even helping other people do so, is utterly ridiculous.
I'll clarify and explain that I was talking about in the context of the discussion, which is spatial orientation ability. Although my other point still holds, which is that gender generalizations are useless for evaluating individuals - they're usefull for generalizations and statistical analysis, and thats all.
Of course you CAN do all these things in other ways, with other languages. But when a feature (like variable scope) is made part of the language, rather than something you hack on with coding conventions, then you've got less chance for mistakes, and mistakes that are made are easier to catch.
This is a idiosynchonism (is that even a word?) of a particular set of languages, and it's a holdover from a past where RAM and cpu time were much more limited. More moden (OO) languages don't use seperate header & source files, using modular or namespace based scoping instead. C# and D (here) are examples.
It's ALWAYS stupider to make assumptions about an individual based on sexual or racial averages. The ability to give birth is a physical property, not a genetic tendency. If you're evaluating an individuals ability, say for a job interview, then evaluating them in any other context is both stupid and prejudicial.
As another poster mentioned: It's very true that there are statistical differences between men and women, but the standard deviation is larger than that difference. Meaning that it's ridiculous to form conclusions of ANY sort based on it. It's usefull as a statistical mean, and thats ALL it's usefull for.
Every case I know of that claims theres a genetically hardcoded disparity between either races or sexes in ANY sort of abstract ability have been rather thinly clad justifications for already formed opinions.
Simple enough. It's hammer.pound(), because hammers can pound things besides nails. It's not worked.useTool(), because we don't have a worker concept in this design. It's possible that you might need a really flexible design, and then you'd want worker.useTool(). Depending on your API, you might actually have nail.getPounded(), which would be called by hammer.pound(), although I suspect that'd be a case of over-design.
OOP should NOT be used to model the real world - that's an easy path to an overly complicated model. In this case, we're deciding that the hammer class is where (most of) the work gets implemented, and then we define things in terms of that hammer. We could have decided to implement everything in terms of the nail instead, and that might make sense for some problems.
I have no idea what the heck you're talking about. The seperation of header files and source files? It's true that C++ lacks interfaces, but an interface is basically the same as inheriting from an abstract base class. The whole point of an interface rather than ingeriting is that you're taking the API without the implementation, so of course there's duplication - you wouldn't be using an interface if you didn't want it.
I don't know about you, but I have tools that can do things like generate header files from source files and vice versa (skeletons only, of course) and browse the object model.
Go read the change logs of any OO toolkit, like Qt or wxWindows. Porting to a new platform is an obvious example. Optimizing a back end algorithm without changing the interface - you can do this in C or other non-OO languages too, of course, but OO lends itself to this kind of thing.
He's talking about wasted overhead of creating temporary objects on the stack, and this is actually a valid complaint. You don't need the overhead of object creation when you're making an integer. In many cases, you don't need it for a string, either, but you make it a std::string (or CString, or whatver) anyway, just for the sake of consistency and convenience. Being aware of it and enforcing discipline suffices to get rid of the problem, the same way you avoid buffer overflows in C.
Re-iterating my previous post - you're actually incorrect. OO is NOT inherently slower than non-OO, although in practice it often is. Inheritence has no run-time performance effect, unless it's virtual.
If your project is easily broken into modules, then it can probably gain from OO. Don't think that it'll magically make your code run better - think about it in terms of ease of management and training new engineers.
If your project is (while perhaps very large) a simple design, then what you gain might not be worth the effort and the re-training.
OO is a formalization of concepts that you probably already use. It's not just a buzzword. It's adding language level support for concepts that make it easier to engineer software - like modularity and code reuse.
Almost every non-trivial program design can be better implemented in OO - because of the ability to encapsulate things into modules.
Constructors & destructors are the biggest advantages you get from OO, and they help everything, including embedded processors. C++ code doesn't HAVE to be bloated.
It's true that creating lots of objects when you don't need to is wastefull, and that if you're needing to write really tight C++ code it's going to look alot like C code. It has nothing to do with being afraid to manage your own memory (sounds like a C programmer who's never really made an attempt at the switch to me) and everything to do with cleaner interfaces.
It's no easier to write "bad" code in C++ than in C. It is, depending on your libraries, often easier to write less efficent code, because you tend to
do things like create extraneous objects on the stack. That's a matter of awareness and coding discipline - just like it's easier in C to write buffer overflows.
Historically, Japan has been very UN-scientific - it's exposure to Western science and ways of thinking is very recent. In fact, generally speaking, Japan has innovated very little over it's entire history, generally assimilating it's technology from other, more dynamic cultures. It is, however, very, very, very good at doing that.
It's a bought bill by the cable providers, actually. It extends the already signifigant legal protection they have on cable service (theft of service or tresspass to chattel in any OTHER industry is a civil matter, it's criminal for cable...) to IP service over cable. The AUP now has the force of law, not just the threat of civil penalties or termination of services, behind it.
A nitpick - they actually don't have to "prove" it in any meaningful way. They simply have to prove a connection, which is as trivial as donating money to a charity which is itself suspected of supporting terrorism. Although one of the mechanisms they're using is the material witness laws, which actually aren't part of the Patriot act.
Jesus of Nazareth did not die so we could enjoy eggs and chocolate bunnies!
No, but he would have enjoyed eggs and chocolate bunnies.
You know what the big C in DMCA means, right? It stands for copyright. The DMCA, for all it's flaws, is limited to "measures controlling access to a copyrighted work". If, now that I've brought this to your attention (albeit in a public manner), you wish to correct your post, you should feel free to do so.
You have every right to piss on a flag in front of a VA vet and not get your assed kicked. Here's why: pissing on the flag is (arguably, but currently) a constitutionally protected right. Kicking someones ass is illegal.
Think for a second about the difference between legal consequences and social consequences. When you come up with an answer, you can then be allowed to rejoin adult conversations.
Actually, it does. Go read it. What part of "Congress shall make no law..." is unclear?
The fact that we've decided, as a nation to water it down, but haven't had the national balls to do it legally with an amendment doesn't really matter.
In my experience (SuSe 8, not 8.1, and SuSe of all the distros I've tried (Debian, Mandrake, Redhat has the best out-of-box X experience), KDE and Gnome both perform noticably worse than Windows XP on the same hardware - mostly in the resizing and creation of Windows.
As for XF86Config - I'm not saying that it needs to be a registry-like binary hive or anything. At the risk of sounding buzzwordy, XML might not be a bad choice (or something XML-like that's perhaps not as high overhead). As for hardware detection - it's currently not being handled by anything, either the OS or X. It's being done manually by the installer, or by special auto-detection applications. A driver should be able to inform X of the resolutions/refresh rates/colors/etc that it supports, rather than needing to edit a config file to tell X that.
I wouldn't be so quick to assume that. For one thing, it's tremendously difficult to draw a direct comparison between funds spent on advertising vrs. increased sales - you can show trends (and the trend is certainly there), but it'd be very difficult, if not impossible, to show a detailed cost-benefit analysis.
Companies sometimes still do things just because they think it's cool.
1) This isn't about XFree being fast for you. And if it performs as well as (say) Windows 2k or XP on modern hardware, then you've spent alot of time tweaking X, and probably your kernel. X should be decent out of the box, and it isn't. "Works good enough" isn't something that I personally like settling for.
2) Standardization is absolutely a point of X. I don't know how you can think otherwise. One of the biggest objections to this port is the possible breaking of the X standards.
3) There is no reason whatsoever that XF86Config needs to be the monster that it is. A logical hierarchy of settings would be a good first step. Alot of the crap in XF86Config is handled by drivers using a standardized interface in Windows - this is a reasonable model to copy. That would help eliminate the need for every distro that's trying to be user-friendly to write it's own hardware detection program.
Slashdot Mirror
The commercial software industry is fucked up. It wants excemptions from responsibility that would be the envy of any other industry, while at the same time making it's own laws about the allowed use of it's products - with no chance for competition, because you're (supposedly) bound by the agreement AFTER you've paid! It's a travesty. At some point, there WILL be a shakedown and this sort of nonsense will either go away or be codified in real law - at which point we'll all be felons, and the bottom will drop out of the personal computer industry - because at that point we're essentially allowing anyone who sells software to write law, and you WILL start seeing things like EULAs that require you to give up your children.
Don't think that all the lawyers at MS don't know this, either. It's why they consistently shy away from cases involving EULAs, either winning them on other points or settling out of court. They KNOW that if push comes to shove, the concept of the EULA as a legally binding document can't stand.
Here's something to consider - there's not 1 single thing that makes it illegal for you to bypass an installer and just avoid an EULA entirely. Not even the DMCA - although you'd (probably) run afoul of it if you tried to distribute tools that did such a thing. Not that an installer is a copy protection device by any stretch of the imagination, but there you go.
FYI, you can't get patches to VFP through windows update.
This is a very simple concept - MS has no obligation to people using WINE. None. Zero. Zilch. It doesn't matter that they can't get patches via Windows Update. They're running on an unsupported OS, and that means UNSUPPORTED. It's very simple. You think they're threatning people with legal action because they want to make sure they get support? I can't help but think you're being intentionally blind.
There are a LOT of things you can't do remotely, even with the resource tools. Try unloading an isapi plugin from IIS so you can install a new verion. Huge pain in the butt when you're developing. Inability to overwrite libraries or applications that're loaded in memory is a big weakness of Windows, imo - it's probably the biggest single cause of rebooting at installations (with 2k/XP, at long last, you can do almost everything else except install new low-level hardware drivers without a reboot).
No, it's not. Theoretically, an EULA is a legally binding document - you're saying it's reasonable for a company to be able to (legally) require you to use a specific OS, whether or not it's required from a technical standpoint (it's obviously not, in this case, since it works). That's absurd, especially when the company in question is an OS company. It's tied directly to all the old arguments about monopolies and abusive behavior. They're perfectly justified in refusing support to anyone who's trying to run it under a non-authorized system, but bringing legal force to bear on someone who is doing so, or even helping other people do so, is utterly ridiculous.
I'll clarify and explain that I was talking about in the context of the discussion, which is spatial orientation ability. Although my other point still holds, which is that gender generalizations are useless for evaluating individuals - they're usefull for generalizations and statistical analysis, and thats all.
Of course you CAN do all these things in other ways, with other languages. But when a feature (like variable scope) is made part of the language, rather than something you hack on with coding conventions, then you've got less chance for mistakes, and mistakes that are made are easier to catch.
This is a idiosynchonism (is that even a word?) of a particular set of languages, and it's a holdover from a past where RAM and cpu time were much more limited. More moden (OO) languages don't use seperate header & source files, using modular or namespace based scoping instead. C# and D (here) are examples.
As another poster mentioned: It's very true that there are statistical differences between men and women, but the standard deviation is larger than that difference. Meaning that it's ridiculous to form conclusions of ANY sort based on it. It's usefull as a statistical mean, and thats ALL it's usefull for.
Every case I know of that claims theres a genetically hardcoded disparity between either races or sexes in ANY sort of abstract ability have been rather thinly clad justifications for already formed opinions.
OOP should NOT be used to model the real world - that's an easy path to an overly complicated model. In this case, we're deciding that the hammer class is where (most of) the work gets implemented, and then we define things in terms of that hammer. We could have decided to implement everything in terms of the nail instead, and that might make sense for some problems.
I don't know about you, but I have tools that can do things like generate header files from source files and vice versa (skeletons only, of course) and browse the object model.
Go read the change logs of any OO toolkit, like Qt or wxWindows. Porting to a new platform is an obvious example. Optimizing a back end algorithm without changing the interface - you can do this in C or other non-OO languages too, of course, but OO lends itself to this kind of thing.
He's talking about wasted overhead of creating temporary objects on the stack, and this is actually a valid complaint. You don't need the overhead of object creation when you're making an integer. In many cases, you don't need it for a string, either, but you make it a std::string (or CString, or whatver) anyway, just for the sake of consistency and convenience. Being aware of it and enforcing discipline suffices to get rid of the problem, the same way you avoid buffer overflows in C.
If your project is easily broken into modules, then it can probably gain from OO. Don't think that it'll magically make your code run better - think about it in terms of ease of management and training new engineers.
If your project is (while perhaps very large) a simple design, then what you gain might not be worth the effort and the re-training.
OO is a formalization of concepts that you probably already use. It's not just a buzzword. It's adding language level support for concepts that make it easier to engineer software - like modularity and code reuse.
Constructors & destructors are the biggest advantages you get from OO, and they help everything, including embedded processors. C++ code doesn't HAVE to be bloated.
It's true that creating lots of objects when you don't need to is wastefull, and that if you're needing to write really tight C++ code it's going to look alot like C code. It has nothing to do with being afraid to manage your own memory (sounds like a C programmer who's never really made an attempt at the switch to me) and everything to do with cleaner interfaces.
It's no easier to write "bad" code in C++ than in C. It is, depending on your libraries, often easier to write less efficent code, because you tend to do things like create extraneous objects on the stack. That's a matter of awareness and coding discipline - just like it's easier in C to write buffer overflows.
Historically, Japan has been very UN-scientific - it's exposure to Western science and ways of thinking is very recent. In fact, generally speaking, Japan has innovated very little over it's entire history, generally assimilating it's technology from other, more dynamic cultures. It is, however, very, very, very good at doing that.
It's a bought bill by the cable providers, actually. It extends the already signifigant legal protection they have on cable service (theft of service or tresspass to chattel in any OTHER industry is a civil matter, it's criminal for cable...) to IP service over cable. The AUP now has the force of law, not just the threat of civil penalties or termination of services, behind it.
Jesus of Nazareth did not die so we could enjoy eggs and chocolate bunnies!
No, but he would have enjoyed eggs and chocolate bunnies.
All (worthwhile) operating systems let you open files that don't exist. Printing them usually isn't very usefull, though :P
This is a correct application of the DMCA.
You know what the big C in DMCA means, right? It stands for copyright. The DMCA, for all it's flaws, is limited to "measures controlling access to a copyrighted work". If, now that I've brought this to your attention (albeit in a public manner), you wish to correct your post, you should feel free to do so.
Think for a second about the difference between legal consequences and social consequences. When you come up with an answer, you can then be allowed to rejoin adult conversations.
The fact that we've decided, as a nation to water it down, but haven't had the national balls to do it legally with an amendment doesn't really matter.
Resposible action by the corporation who sold the university this product could have saved the university from a rash of fraud.
As for XF86Config - I'm not saying that it needs to be a registry-like binary hive or anything. At the risk of sounding buzzwordy, XML might not be a bad choice (or something XML-like that's perhaps not as high overhead). As for hardware detection - it's currently not being handled by anything, either the OS or X. It's being done manually by the installer, or by special auto-detection applications. A driver should be able to inform X of the resolutions/refresh rates/colors/etc that it supports, rather than needing to edit a config file to tell X that.
Companies sometimes still do things just because they think it's cool.
1) This isn't about XFree being fast for you. And if it performs as well as (say) Windows 2k or XP on modern hardware, then you've spent alot of time tweaking X, and probably your kernel. X should be decent out of the box, and it isn't. "Works good enough" isn't something that I personally like settling for.
2) Standardization is absolutely a point of X. I don't know how you can think otherwise. One of the biggest objections to this port is the possible breaking of the X standards.
3) There is no reason whatsoever that XF86Config needs to be the monster that it is. A logical hierarchy of settings would be a good first step. Alot of the crap in XF86Config is handled by drivers using a standardized interface in Windows - this is a reasonable model to copy. That would help eliminate the need for every distro that's trying to be user-friendly to write it's own hardware detection program.