Every time you decide to redistribute GPL program that you bought or obtained from someone who paid for patent license you need to include per-unit costs in your price (and pay it to a patent owner). If the said per-unit cost was non-zero, you cannot redistribute the program for free, but actually GPL does not mandate you to redistribute software for free; it allows to include whatever costs you take for redistributing it (this time it means patent costs).
GPL doesn't mean you have to make software available for free to everyone. You just sell it with sources included, if your clients decide to redistribute without paying fees, they will get sued by original patent holder.
Future generations will look at our software with shock and envy: "they had general purpose computers that anyone was free to program for? Even write a new OS for it? What a Wild West".
There's no problem in paying for individual health care insurance in the U.S., although it's not cheap since the insurers have no guarantee that you'll stay with them (or at least they pretend that's the reason for jacking up the costs). Whether you're self-employed or have a job in a larger company, the costs of health insurance still aren't trivial. $15k per year is a ballpark figure for a family.
And that's precisely why OP said that American system was "closer to slavery"... Polish system is not like this - as illogical as it is, here you pay smaller (actually, fixed) sum if you are self-employed. So much smaller that it makes people quit salaried jobs and become "self-employed" contractors with their previous employer. In States, the employer is king... in Poland, not so much. Of course, there are other ramifications of this as well (e.g. ZUS is nearly bankrupt).
Well, I guess that's not what GP meant. In Poland, it IS feasible for a person to pay for his/her own health care insurance (e.g. if they are self-employed they do exactly that). In States, as far as I know, you have much tougher luck getting insured if you aren't part of a larger group of people.
Also, in Poland they don't check for pre-existing conditions and exempt those. You may be very well terminally ill and ZUS will still insure you. In States that's not like that AFAIK.
OpenGL doesn't seem to suck at all, but the support does vary broadly.
OpenGL has multiple flaws which are well documented on the net. The core API is too high level, while at the same time its extension model pushes the burden of supporting incompatible hardware to application developers. Its internal state can be changed at unpredictable times and the API remains essentially single-threaded as far as a single context is concerned. It is getting better in recent versions, but we will have to support older profiles for a long time, given the fact that only proprietary drivers implement OpenGL 3.0+ on Linux.
I would certainly prefer to program for DirectX if it were a cross-platform (well, cross-vendor) API.
Seconded. I feel that people who use Linux not even for gaming, but for anything graphics-related, are a tiny minority. Available API (de facto standard: OpenGL + SDL) sucks, drivers suck (except for NVidia, who gets blamed for being binary), development tools suck (see TFA about OpenGL debugger), distributing binaries is problematic.
Desktop integration isn't there ("standard" SDL will not help you detect multiple monitors), when your app crashes you are left with broken screen. Just allocating too much (overcommit by a few GB) memory can make your Linux desktop unresponsive enough so you have to SSH to it from another machine and kill the offending process.
Now compare it to Windows where TDR allows you to survive even a driver crash! There's A LOT of work needed if Linux is to become a good desktop, and the majority of it is not about fancy UI. It's about getting a solid graphics stack, good support for debugging, good tools built on top of that. Frankly speaking, I'm not sure that community can provide that. This requires unification of will on a large scale, and community tends to produce loosely-knit patchwork of locally optimal solutions.
In my opinion both high and low level languages will remain relevant for the foreseeable future, especially given that Murphy's law does not work any more, at least regarding the performance. Current renaissance of native languages is probably related to ever-increasing complexity of software built from too many pieces, which makes it harder to reliably control program behavior and introduces multiple points of failure.
As things developed in those languages being a pain, I've never had that experience at all. I just like being able to use the software on any platform I want.
Well... try running a Java program on Raspberry Pi or a.NET 4.0 program under Linux... Granted, those are exotic examples, but generally my experience with Java/Python programs under Windows is troublesome (since I'm not a Java/Python developer I don't have up-to-date runtimes and tend to run into rough edges), and the same applies to.NET programs under Linux.
Anyway, I agree that we better stop here before we go deeper into discussion of each other's anecdotal evidence.
The higher-level methodologies and massive standard library mean simpler code reusing more parts, meaning less potential errors and less code to get used to coming into a project.
All that happiness stops when you you need to control that "black box" because of some kind of hard requirement (memory or time).
There were a lot of game developers who added higher level scripts (incl. Python) as extensions back in PC times... When industry moved to consoles or console-likes devices where extensibility is not needed by an average user, that turned out to be a really bad decision. You get hard-to-debug code that happily allocates memory dynamically, cannot be forced to per-frame time budget of 33 (or even 16) ms and can "magically break" in so many ways. That is why Unreal Engine 4 will be pure C++ and Frostbite (Battlefield engine) has always been pure C++.
Also, every time when I have to deal with higher level program (Java, Python or whatever) as an end user, that is a pain. They never look like a robust software and often simply getting them to run is a problem (install this and that, make sure that JRE version is within A and B, etc).
What I described isn't short-term thinking - it's just utilizing the resources effectively. Yes, bad programmers can write bad scripts that are hard to maintain, but that isn't specific to scripts. A good programmer can use a high-level language for the valuable tool it is.
Higher level languages are designed to facilitate short-term thinking and they introduce a lot of implicit assumptions - done by their designers and not you - about behavior of your program.
Certainly, they have advantages, but they are mental equivalent of moving your factories to China.
Checking each malloc for NULL is probably not worth it either, but being explicit about design limitations of your program and not letting it run until it runs out of memory is certainly more robust engineering. Of course you need to optimize !/$ ration first.
Regarding your "make it work, make it work well, make it work fast" order, it certainly makes sense but it is not the universal truth and there are industries where different order makes more sense. E.g. game development - players (even console ones) can tolerate occasional bugs (even as hard ones as crashes), but selling an ugly (or slow) game is much harder than selling a buggy one.
It's also all too easy to find programmers who don't recognize the value of not giving a damn in situations where it truly doesn't matter. If I can save a ton of cost by using a higher level language and having no-effort cross-platform compatibility, better maintainability and faster development, then it's often very worthwhile.
While life proves you correct on many occasions, I don't like short term thinking, which gets us in trouble in the software field and elsewhere else. Also, I don't think that 10-line "duct tape" scripts are easier to maintain in the long run (i.e. if they need to be maintained at all - and not rewritten from scratch), see init vs systemd case for instance.
Also, nowadays it's hard to find programmers who truly realize that memory is not an unlimited resource. Academia supplies pokemons who can only do higher level programming and cannot be bothered with "hardware specific details" like these.
I don't feel any "astounding progress", in my humble opinion user experience of doing things in browser didn't change much since Java applets day: it's still slow, unresponsive and unreliable interface and it loses with native clients each time there exists one. Perhaps some progress has been achieved throughout the years, but it's unobvious for me how Javascript's source-levelness has had anything to do with that. If Microsoft weren't so Java-averse (and if the rest of industry weren't so Microsoft-averse) we could have had something better.
Source-level runtime looks like a temporary scenario. It implies the need for a compiler on the client, unpredictable and hard to debug behavior of the same code, limits complexity of the program. I realize that Javascript is the standard now, but I don't see any inherent advantage of it, apart of being a "least common denominator" not owned by any one single vendor.
And BTW, I heard that Facebook is thinking about some kind of bytecode on client side.
Won't client-side runtime "compilation" limit the complexity of software which is going to be written, similarly how GLSL run-time compiled shaders lost (on PC) versus offline-compiled HLSL? Not to mention problems with keeping your source code to yourself.
These are two aspects where bytecode (or native) runtime would be certainly better. I don't see benefits of source level runtime... it's no easier to audit sources security-wise than to audit VM and it can break in so many more ways.
You'd be surprised to learn how many people play split-screen - Xbox360 exclusive games like Gears of War support that precisely because the population is significant. Probably that works for getting your girlfriend/wife to play games, or maybe its "father and son" scenario, who knows.
They do send money, but that's usually less than they spend locally. And no, most don't plan on leaving. Your grandparents didn't plan on returning back to their home country, did they? Nothing changed since then.
Can't say anything about Indians, but I don't know of a single Russian who went to work to America with the intent to return back. They all are applying for permanent residency.
1) I doubt that H-1B workers want to return to their country:) Maybe some do, but that is probably a minority. It would have been easier for them to get employed by an American company in their own country - that would have given them 60-70% of American wage without the additional hassles.
2) US workers could also relocate to cheaper places where they would be able to retire on their few month savings;-) I don't think that you can find such a place on Earth these days, though.
Without H-1B, more American works would be shipped overseas. What do you prefer: to have Indians working in Silicon Valley or to have Silicon Valley relocated to India?
Still, even putting aside possible deterrent effect on wannabe hackers and script kiddies who, in my opinion, come from "normal people" (but I don't want to argue about this minor point), I don't see how "security through obscurity" is a "laughable concept" as OP asserted. Provided that you aren't developing underlying tech from scratch but consulting/employing experts in the field, a "smoke screen" around your tech is going to strengthen your security, not weaken it.
Also, STO allows you to more easily employ steganography where applicable.
Actually, why is Security Through Obscurity laughable? Don't underestimate people's psychology. If we don't know how the thing works, we usually have better opinion about its guts than they actually deserve;) (yeah, this also works in favor of proprietary software). Moreover, if you used publicly available algorithm Foo, but disguised it so it's not obvious that it was Foo, that provides you with an additional layer of protection in case some basic flaw in Foo's design is discovered.
Also, hiding your technology costs your enemy more effort (money, time, etc) to just evaluate whether it's worth attacking you.
There were some studies on how well people solve math tasks and it was found important for people to know that the task given was at all solvable in the first place; without that a priori knowledge a lot of people gave up after the first few hours. So why provide the people (and thus, the enemy) with unnecessary knowledge?
Microsoft jumps on the bandwagon and follows Google and Mozilla in downplaying software versions. I bet they will be releasing new Windows often, very often... until people stop paying attentions to incremental differences and distinction between web-based services and locally run software is lost - which is already happening.
Slashdot Mirror
Every time you decide to redistribute GPL program that you bought or obtained from someone who paid for patent license you need to include per-unit costs in your price (and pay it to a patent owner). If the said per-unit cost was non-zero, you cannot redistribute the program for free, but actually GPL does not mandate you to redistribute software for free; it allows to include whatever costs you take for redistributing it (this time it means patent costs).
GPL doesn't mean you have to make software available for free to everyone. You just sell it with sources included, if your clients decide to redistribute without paying fees, they will get sued by original patent holder.
Future generations will look at our software with shock and envy: "they had general purpose computers that anyone was free to program for? Even write a new OS for it? What a Wild West".
There's no problem in paying for individual health care insurance in the U.S., although it's not cheap since the insurers have no guarantee that you'll stay with them (or at least they pretend that's the reason for jacking up the costs). Whether you're self-employed or have a job in a larger company, the costs of health insurance still aren't trivial. $15k per year is a ballpark figure for a family.
And that's precisely why OP said that American system was "closer to slavery"... Polish system is not like this - as illogical as it is, here you pay smaller (actually, fixed) sum if you are self-employed. So much smaller that it makes people quit salaried jobs and become "self-employed" contractors with their previous employer. In States, the employer is king... in Poland, not so much. Of course, there are other ramifications of this as well (e.g. ZUS is nearly bankrupt).
Well, I guess that's not what GP meant. In Poland, it IS feasible for a person to pay for his/her own health care insurance (e.g. if they are self-employed they do exactly that). In States, as far as I know, you have much tougher luck getting insured if you aren't part of a larger group of people.
Also, in Poland they don't check for pre-existing conditions and exempt those. You may be very well terminally ill and ZUS will still insure you. In States that's not like that AFAIK.
But where would you prefer to live, in sterile and artificial Germany or the USA? (Hint: I'm not an American).
OpenGL doesn't seem to suck at all, but the support does vary broadly.
OpenGL has multiple flaws which are well documented on the net. The core API is too high level, while at the same time its extension model pushes the burden of supporting incompatible hardware to application developers. Its internal state can be changed at unpredictable times and the API remains essentially single-threaded as far as a single context is concerned. It is getting better in recent versions, but we will have to support older profiles for a long time, given the fact that only proprietary drivers implement OpenGL 3.0+ on Linux.
I would certainly prefer to program for DirectX if it were a cross-platform (well, cross-vendor) API.
Seconded. I feel that people who use Linux not even for gaming, but for anything graphics-related, are a tiny minority. Available API (de facto standard: OpenGL + SDL) sucks, drivers suck (except for NVidia, who gets blamed for being binary), development tools suck (see TFA about OpenGL debugger), distributing binaries is problematic.
Desktop integration isn't there ("standard" SDL will not help you detect multiple monitors), when your app crashes you are left with broken screen. Just allocating too much (overcommit by a few GB) memory can make your Linux desktop unresponsive enough so you have to SSH to it from another machine and kill the offending process.
Now compare it to Windows where TDR allows you to survive even a driver crash! There's A LOT of work needed if Linux is to become a good desktop, and the majority of it is not about fancy UI. It's about getting a solid graphics stack, good support for debugging, good tools built on top of that. Frankly speaking, I'm not sure that community can provide that. This requires unification of will on a large scale, and community tends to produce loosely-knit patchwork of locally optimal solutions.
In my opinion both high and low level languages will remain relevant for the foreseeable future, especially given that Murphy's law does not work any more, at least regarding the performance. Current renaissance of native languages is probably related to ever-increasing complexity of software built from too many pieces, which makes it harder to reliably control program behavior and introduces multiple points of failure.
As things developed in those languages being a pain, I've never had that experience at all. I just like being able to use the software on any platform I want.
Well... try running a Java program on Raspberry Pi or a .NET 4.0 program under Linux... Granted, those are exotic examples, but generally my experience with Java/Python programs under Windows is troublesome (since I'm not a Java/Python developer I don't have up-to-date runtimes and tend to run into rough edges), and the same applies to .NET programs under Linux.
Anyway, I agree that we better stop here before we go deeper into discussion of each other's anecdotal evidence.
P.S. Compilers are still less efficient than humans (PDF) (because of their genericity, TANSTAAFL).
The higher-level methodologies and massive standard library mean simpler code reusing more parts, meaning less potential errors and less code to get used to coming into a project.
All that happiness stops when you you need to control that "black box" because of some kind of hard requirement (memory or time).
There were a lot of game developers who added higher level scripts (incl. Python) as extensions back in PC times... When industry moved to consoles or console-likes devices where extensibility is not needed by an average user, that turned out to be a really bad decision. You get hard-to-debug code that happily allocates memory dynamically, cannot be forced to per-frame time budget of 33 (or even 16) ms and can "magically break" in so many ways. That is why Unreal Engine 4 will be pure C++ and Frostbite (Battlefield engine) has always been pure C++.
Also, every time when I have to deal with higher level program (Java, Python or whatever) as an end user, that is a pain. They never look like a robust software and often simply getting them to run is a problem (install this and that, make sure that JRE version is within A and B, etc).
What I described isn't short-term thinking - it's just utilizing the resources effectively. Yes, bad programmers can write bad scripts that are hard to maintain, but that isn't specific to scripts. A good programmer can use a high-level language for the valuable tool it is.
Higher level languages are designed to facilitate short-term thinking and they introduce a lot of implicit assumptions - done by their designers and not you - about behavior of your program.
Certainly, they have advantages, but they are mental equivalent of moving your factories to China.
Checking each malloc for NULL is probably not worth it either, but being explicit about design limitations of your program and not letting it run until it runs out of memory is certainly more robust engineering. Of course you need to optimize !/$ ration first.
Regarding your "make it work, make it work well, make it work fast" order, it certainly makes sense but it is not the universal truth and there are industries where different order makes more sense. E.g. game development - players (even console ones) can tolerate occasional bugs (even as hard ones as crashes), but selling an ugly (or slow) game is much harder than selling a buggy one.
It's also all too easy to find programmers who don't recognize the value of not giving a damn in situations where it truly doesn't matter. If I can save a ton of cost by using a higher level language and having no-effort cross-platform compatibility, better maintainability and faster development, then it's often very worthwhile.
While life proves you correct on many occasions, I don't like short term thinking, which gets us in trouble in the software field and elsewhere else. Also, I don't think that 10-line "duct tape" scripts are easier to maintain in the long run (i.e. if they need to be maintained at all - and not rewritten from scratch), see init vs systemd case for instance.
Also, nowadays it's hard to find programmers who truly realize that memory is not an unlimited resource. Academia supplies pokemons who can only do higher level programming and cannot be bothered with "hardware specific details" like these.
I don't feel any "astounding progress", in my humble opinion user experience of doing things in browser didn't change much since Java applets day: it's still slow, unresponsive and unreliable interface and it loses with native clients each time there exists one. Perhaps some progress has been achieved throughout the years, but it's unobvious for me how Javascript's source-levelness has had anything to do with that. If Microsoft weren't so Java-averse (and if the rest of industry weren't so Microsoft-averse) we could have had something better.
Source-level runtime looks like a temporary scenario. It implies the need for a compiler on the client, unpredictable and hard to debug behavior of the same code, limits complexity of the program. I realize that Javascript is the standard now, but I don't see any inherent advantage of it, apart of being a "least common denominator" not owned by any one single vendor.
And BTW, I heard that Facebook is thinking about some kind of bytecode on client side.
Won't client-side runtime "compilation" limit the complexity of software which is going to be written, similarly how GLSL run-time compiled shaders lost (on PC) versus offline-compiled HLSL? Not to mention problems with keeping your source code to yourself.
These are two aspects where bytecode (or native) runtime would be certainly better. I don't see benefits of source level runtime... it's no easier to audit sources security-wise than to audit VM and it can break in so many more ways.
You'd be surprised to learn how many people play split-screen - Xbox360 exclusive games like Gears of War support that precisely because the population is significant. Probably that works for getting your girlfriend/wife to play games, or maybe its "father and son" scenario, who knows.
They do send money, but that's usually less than they spend locally. And no, most don't plan on leaving. Your grandparents didn't plan on returning back to their home country, did they? Nothing changed since then.
Can't say anything about Indians, but I don't know of a single Russian who went to work to America with the intent to return back. They all are applying for permanent residency.
1) I doubt that H-1B workers want to return to their country :) Maybe some do, but that is probably a minority. It would have been easier for them to get employed by an American company in their own country - that would have given them 60-70% of American wage without the additional hassles.
;-) I don't think that you can find such a place on Earth these days, though.
2) US workers could also relocate to cheaper places where they would be able to retire on their few month savings
The higher level language you use, the less effort it took you to master it. No wonder that Java developers aren't the top earners.
Without H-1B, more American works would be shipped overseas. What do you prefer: to have Indians working in Silicon Valley or to have Silicon Valley relocated to India?
Still, even putting aside possible deterrent effect on wannabe hackers and script kiddies who, in my opinion, come from "normal people" (but I don't want to argue about this minor point), I don't see how "security through obscurity" is a "laughable concept" as OP asserted. Provided that you aren't developing underlying tech from scratch but consulting/employing experts in the field, a "smoke screen" around your tech is going to strengthen your security, not weaken it.
Also, STO allows you to more easily employ steganography where applicable.
Ok, you are saying that being obscure changes nothing for governments, but may deter normal people... so the net result is still a plus?
Actually, why is Security Through Obscurity laughable? Don't underestimate people's psychology. If we don't know how the thing works, we usually have better opinion about its guts than they actually deserve ;) (yeah, this also works in favor of proprietary software). Moreover, if you used publicly available algorithm Foo, but disguised it so it's not obvious that it was Foo, that provides you with an additional layer of protection in case some basic flaw in Foo's design is discovered.
Also, hiding your technology costs your enemy more effort (money, time, etc) to just evaluate whether it's worth attacking you.
There were some studies on how well people solve math tasks and it was found important for people to know that the task given was at all solvable in the first place; without that a priori knowledge a lot of people gave up after the first few hours. So why provide the people (and thus, the enemy) with unnecessary knowledge?
Microsoft jumps on the bandwagon and follows Google and Mozilla in downplaying software versions. I bet they will be releasing new Windows often, very often... until people stop paying attentions to incremental differences and distinction between web-based services and locally run software is lost - which is already happening.