There's more to life than an abstract security model.
Well, its not abstract if it is a short-minded design from the 70's and has caused real concrete problems at least for a decade and a half, and other designs/solutions are available, is it?
Virtual machines are cheap these days, don't let untrusted users (or processes) onto your important server in the first place.
They are also not suitable for every workload. They offer no tamper-proofing, the only thing they guarantee is separation of concerns. So lets say you'll use a shared store, with a poorly-chosen (you will only realize this later) user privilege scheme that allows an attacker to wipe out your data. Sure, backups. Now imagine how long does it take to recover out 30TB of data from your backup structure?
If you insist on OS timesharing and full security, well, you're fooling yourself IMHO.
It has nothing to do with timesharing, but separation of concerns. I assume you don't have eg. a single VM for each apache process, and a load balancer in front of it - but that's what you're suggesting. Having eg. mail stuff separated from the crappy php cms is a problem that was solved at least almost decade and a half ago in FreeBSD, and in the remaining Unixes you could always use (buggy) chroot techniques. The problem is, that if someone attacks your server and TAMPERS your data, months may pass before you realize it. And then most (all?) of your backups are tainted. How did a VM helped with that? Right.
Of course VMS could do it, but try to find one now
Still doesn't change the fact that the UNIX security model is broken for modern applications. Its not all bad - Windows has a acl/permission system eons ahead of the traditional Unix, and its not better because of it. But VMs add nothing to the mix - unless you consider application sandboxing "VM's". In that case, have a look at capiscum (FreeBSD) and systrace (OpenBSD).
Yeah, I should have also pointed out that having/spreading dogmas is also bad. So using the 'always' word is also bad. And in modern x86/amd64 assembly, they are not only gotos, but they can also be if's. I suggest people should waste their time understanding how the system works instead of repeating never-old dogmas like "goto's are always bad" - specially when spewed as an universal truth.
Instead, you should ask: why, in 2014, where we have a diversity of programming languages never seen before, people still spread old dogmas? Some languages don't even have goto's; others depend on it directly.
Following that line of thought, that is probably the margin they have when they are manufacturing some of those $5-a-pop chips, right? Top-of-the-line processors are expensive, because of market pressures (aka "people will pay for them"), but also because of defect ratios and ROI of the manufacturing process. Building/upgrading factories is expensive. Traditionally, speciallized processors and old lines are way cheaper - so cheap, that they prefer to license the core design to someone else instead of building it themselves. Go and see how many variations of 8031/32, 8051/52 you have today - probably more than one hundred. I would bet you have more 8051 microcontrollers running *today* than the whole sum of their desktop chips, including the low power, embedded/hardened lines.
I'm reading this and laughing. I've read the same kind of statement when they're using 300nm tech, 95nm tech, 65nm tech, and so on and so forth. Their public roadmap has 5nm tech around 2019-2022 (http://en.wikipedia.org/wiki/5_nanometer). And as x86 inheritance slowly fades away, they can actually produce way smaller chips without backwards compatibility if the market demands it (very few applications run 1978 instructions nowadays, same goes for all that 16-bit protected mode wazoo).
Did you read TFA? The article was about remarks made by a guy that apparently was gatering the data for the autobiography. The whole article IS about Assange as a person, not WikiLeaks or whatever. If you don't find that interesting, well, neither do I, but it doesn't change the fact that it is NOT an article about WikiLeaks, its about Assange. Live with it.
I will whistle to my modem a tune that will trigger a buffer overflow that will execute a disk write of a new file with the contents of what I whistle next. And that file resides in CRT storage. If 1950 don't call first and ask for its mumbo-jumbo back.
Almost all "smart" IDEs do this. In addition to that, in PHP you're actually making both the IDE and the piss-poor-excuse-of-a-reflection-engine that PHP has happy:)
And that's the real issue: Programmers who do not know what "makefiles" are, how dependencies are being tracked, what "compilation units" or "object files" are, they are completely lost when the linker stops with some cryptic error messages telling about some "PIC incompatible symbol" or alike.
That has nothing to do with IDE usage by itself. Usually when you have an external dependency problem, a modern IDE will probably warn you of it - a specialized text editor won't. That's the difference between editing a bunch of files or having a proper project management infrastructure (I know, some editors do offer project management capabilities, but you get my point).
And while (many years ago) I've actually built custom linkers and had good knowledge of the internals of the COFF format, I would probably stare dumb at messages a modern linker would produce.
Not really, no. Having eg. a system that allows a diff view of two separate revisions of a file you're working on, and in an environment that also manages your project and does static analysis of the code, and highlights obvious typing mistakes (unclosed brackets; missing comas; code conformity; cyclomatic complexity, etc) and performs syntax highlighting and autocomplete is a good step to stop wasting your time fixing obvious and stupid stuff, stop wasting the code reviewer's time telling you to follow protocol, and thus creating a leaner development environment. The hability to rename a function and fix it in all the files that use it, on that *specific* project, with a couple of clicks is something you do get used to, and sometimes is not that easy to do it via command line - eg. when you use docblocks to typehint indirect references to the function, that will get properly fixed automatically on an IDE.
Offhand, yes, you are a less effective programmer if you rely on the IDE. I've seen many "programmers" that get completely lost if the IDE doesn't autocomplete everything for them.
That is a broad statement. Autocomplete is awesome when you're getting your hands into an existing codebase, and quickly need to be productive. It is also awesome when you have medium to big projects (between 500K lines, hundreds of classes/interfaces/whatever, and several million, thousands of classes/interfaces/whatever). I've seen many programmers completely lost at debugging *because* they were using a debugger - they wasted time identifying specific problems in their routines, while the whole approach was unsuitable - they would usually realize it after fixing the routine the first time, instead of looking at their code and trying to understand how could/would fail. Not all languages are equally suited for it, but those that fit the pattern (usually OOP stuff), works well.
My personal reason to use an IDE is syntax highlighting, project management features, and multi file navigation (it is common to have between 40 and 100 files open). Autocomplete is awesome, but it is a cherry on top of the cake. I could probably work without a full-blown IDE, but it wouldn't be the same thing.
Depends on the language; The direct equivalent of goto in assembly is 'jmp'; if you add the plethora of if/switch conditions most languages support, you have a list of very specialized 'gotos' that will plague your compiled/interpreted code, regardless of the starting language;)
Spell/grammar checking is an awful example. If you misspel a word, the novel will still be finished. A computer program will not - will fail (either silently or noisy) or won't compile at all. So code completion is akin to having shortcuts to predefined phrases and complex words, not spellchecking.
When I did some C# code, I'd actually use SharpDevelop (the UI designer has (had?) some horrible bugs) because I wasn't able to adjust to the VS workflow.
Also, Europe did not have similar regulations, they may have had tougher regulations but they were the wrong regulations. Australian banks had limits about how much they could lend vs how much they had in assets as well as rules on how much they had to keep in liquid assets (again relative to how much they could lend) which made the conditions that created the sub prime crisis in the US and Europe impossible to have in Australia.
This is pretty standard in EU. The crisis tightened the ratios, but they existed before, and AFAIK were quite different from the US. Keep in mind, Iceland (the actual EU country that is associated with unregulated banks, has roughly 300.000 habitants, and a PIB lower than many/most of the Fortune500 companies).
If you don't understand this, you have no idea how the banking regulations in Australia work.
Well, I don't, but you seem to not know how EU regulations work. And since I live in EU (lived in 2 countries, actually), and my current country is still interventioned by IMF, people are well aware of what is going on.
Well, it is if he uses any kind of modern system. There are very few "completely free" computer platforms out there, and even those may run some proprietary programmable logic. Even modern CPUs run internal microcode.
For me that's working for free for somebody and that's not fair.
So if a company makes available under BSD license a library that was internally developed, developers don't need to be paid? That is new.
GPL mandates that if they distribute the improved binaries they have to share the improved source code.
Well, tecnically, no. They need to make the improved source code available under request to whom they distribute the binaries to. Not everyone. And since nowadays the tendency to run software is, well, hosted or via remote desktop or similar technology, since you're not distributing binaries, you don't need to make the source available. So if you develop a GPL library I want to build the stack of my shiny new SAAS startup, there is nothing you can do about it. The startup is the end user, it can modify it as it seems fit - and as long as it doesn't distribute the binaries, no one can ask for the code. Welcome to 2014.
One of the most ambigious words out there is "freedom."
Not everything is politics and philosophy. Its not about freedom (at least not anymore) - and it was never about freedom as RMS describes it. Its about software. Modern computers require very complex electronics and assembly process, it is not possible anymore to build a "modern" system from scratch in your garage with a soldering iron and some ICs. Computers are obiquous and software makes them tick. Most of that software is not GPL. Talking about freedom in software does not make sense, because software is a recipe - it makes a specific set of machinery "tick". It is not about freedom; it is about openness. In my perspective, having a RMS-abiding compiler means shit in terms of "freedom" to me - at least while most of the electronic equipment I use is designed with closed-source ASICs and runs closed-source firmware (including microcode in modern CPUs).
But then, I work as a programmer. If I want to share a piece of code with the community, it is my choice which license to choose - not RMS. I have the freedom of choosing the license I find most appropriate - and most of the times will be BSD, not GPL. Because I value openness, not bittery politics.
I was at Novell at the time during which the protocol basis for the commercial Internet was being decided. Novell was attempting to swing a deal with AT&T to get them to deploy a commercial network topology based on SPX/IPX; at the same time, Microsoft was attempting to get AT&T and Sprint, and whoever else they could get on board, to deploy a commercial network based on NetBIOS/NetBEUI.
It has been some time since I worked with both IPX and NetBEUI, but AFAIK they are single-segment protocols based on broadcast. You cannot build (easily) a network of a thousand nodes with it. Most "useful" implementations of both in relatively large networks are done over TCP/IP.
Also, TCP/IP would guarantee at least some compatibility with competing systems, eg Microsoft and IBM (IBM was probably one of the earlier adopters of TCP/IP for business environments, and this had effect on the rest of the market).
. Any contribution to a BSD codebase needs to be evaluated carefully because it means that the code is immediately licensed to your competitors without restriction and they can embrace-extend-extinguish you right out of your market if you are not very careful.
So what you're saying is that GPL prevents this? How? Please explain how a developer submitting a patch or a feature to a BSD-licensed project automatically gives your competition the hability of taking over your business?
GPL is much safer, in that case competitors can only use the code if they in turn publish and license back their own modifications
No it isn't, you. GPL clearly states that you are REQUIRED to make source code available upon request for your CUSTOMERS if they received a binary - not for everyone. That explicitly excludes most of the software, startups you see popping around, because most of the products are SAAS. I can use GPL software to build the closest system I can think of, and as long as I don't send binaries to customers (eg. they interact with it via browser/RDP/VNC/carrier pidgeons) I don't need to provide ANY source code.
I would start looking for a new job, these idiots will probably run the company into the ground in short order.
I would suggest you don't make strong assumptions of things you don't understand. In most companies I worked (related to software dev), GPL libraries were generically forbidden.
Slashdot Mirror
I do prefer the Windows model to the UNIX one. How do you disable the compiler toolchain on a modern system from specific users?
There's more to life than an abstract security model.
Well, its not abstract if it is a short-minded design from the 70's and has caused real concrete problems at least for a decade and a half, and other designs/solutions are available, is it?
Virtual machines are cheap these days, don't let untrusted users (or processes) onto your important server in the first place.
They are also not suitable for every workload. They offer no tamper-proofing, the only thing they guarantee is separation of concerns. So lets say you'll use a shared store, with a poorly-chosen (you will only realize this later) user privilege scheme that allows an attacker to wipe out your data. Sure, backups. Now imagine how long does it take to recover out 30TB of data from your backup structure?
If you insist on OS timesharing and full security, well, you're fooling yourself IMHO.
It has nothing to do with timesharing, but separation of concerns. I assume you don't have eg. a single VM for each apache process, and a load balancer in front of it - but that's what you're suggesting. Having eg. mail stuff separated from the crappy php cms is a problem that was solved at least almost decade and a half ago in FreeBSD, and in the remaining Unixes you could always use (buggy) chroot techniques. The problem is, that if someone attacks your server and TAMPERS your data, months may pass before you realize it. And then most (all?) of your backups are tainted. How did a VM helped with that? Right.
Of course VMS could do it, but try to find one now
Still doesn't change the fact that the UNIX security model is broken for modern applications. Its not all bad - Windows has a acl/permission system eons ahead of the traditional Unix, and its not better because of it. But VMs add nothing to the mix - unless you consider application sandboxing "VM's". In that case, have a look at capiscum (FreeBSD) and systrace (OpenBSD).
Yeah, I should have also pointed out that having/spreading dogmas is also bad. So using the 'always' word is also bad. And in modern x86/amd64 assembly, they are not only gotos, but they can also be if's. I suggest people should waste their time understanding how the system works instead of repeating never-old dogmas like "goto's are always bad" - specially when spewed as an universal truth.
Instead, you should ask: why, in 2014, where we have a diversity of programming languages never seen before, people still spread old dogmas? Some languages don't even have goto's; others depend on it directly.
Intel enjoys 60%+ margins on everything it sells
Following that line of thought, that is probably the margin they have when they are manufacturing some of those $5-a-pop chips, right? Top-of-the-line processors are expensive, because of market pressures (aka "people will pay for them"), but also because of defect ratios and ROI of the manufacturing process. Building/upgrading factories is expensive. Traditionally, speciallized processors and old lines are way cheaper - so cheap, that they prefer to license the core design to someone else instead of building it themselves. Go and see how many variations of 8031/32, 8051/52 you have today - probably more than one hundred. I would bet you have more 8051 microcontrollers running *today* than the whole sum of their desktop chips, including the low power, embedded/hardened lines.
I'm reading this and laughing. I've read the same kind of statement when they're using 300nm tech, 95nm tech, 65nm tech, and so on and so forth. Their public roadmap has 5nm tech around 2019-2022 (http://en.wikipedia.org/wiki/5_nanometer). And as x86 inheritance slowly fades away, they can actually produce way smaller chips without backwards compatibility if the market demands it (very few applications run 1978 instructions nowadays, same goes for all that 16-bit protected mode wazoo).
Did you read TFA? The article was about remarks made by a guy that apparently was gatering the data for the autobiography. The whole article IS about Assange as a person, not WikiLeaks or whatever. If you don't find that interesting, well, neither do I, but it doesn't change the fact that it is NOT an article about WikiLeaks, its about Assange. Live with it.
And reads/writes files using CR/LF line termination and does not detect encoding.
I will whistle to my modem a tune that will trigger a buffer overflow that will execute a disk write of a new file with the contents of what I whistle next. And that file resides in CRT storage. If 1950 don't call first and ask for its mumbo-jumbo back.
Almost all "smart" IDEs do this. In addition to that, in PHP you're actually making both the IDE and the piss-poor-excuse-of-a-reflection-engine that PHP has happy :)
And that's the real issue: Programmers who do not know what "makefiles" are, how dependencies are being tracked, what "compilation units" or "object files" are, they are completely lost when the linker stops with some cryptic error messages telling about some "PIC incompatible symbol" or alike.
That has nothing to do with IDE usage by itself. Usually when you have an external dependency problem, a modern IDE will probably warn you of it - a specialized text editor won't. That's the difference between editing a bunch of files or having a proper project management infrastructure (I know, some editors do offer project management capabilities, but you get my point).
And while (many years ago) I've actually built custom linkers and had good knowledge of the internals of the COFF format, I would probably stare dumb at messages a modern linker would produce.
Relying on an IDE does make you a bad programmer
Not really, no. Having eg. a system that allows a diff view of two separate revisions of a file you're working on, and in an environment that also manages your project and does static analysis of the code, and highlights obvious typing mistakes (unclosed brackets; missing comas; code conformity; cyclomatic complexity, etc) and performs syntax highlighting and autocomplete is a good step to stop wasting your time fixing obvious and stupid stuff, stop wasting the code reviewer's time telling you to follow protocol, and thus creating a leaner development environment. The hability to rename a function and fix it in all the files that use it, on that *specific* project, with a couple of clicks is something you do get used to, and sometimes is not that easy to do it via command line - eg. when you use docblocks to typehint indirect references to the function, that will get properly fixed automatically on an IDE.
Its "assembly". And if you don't program in hexadecimal, you're using the pussy build infrastructure (mnemonics + compiler)
You'te a pussy. If you don't know 90% of the mnemonics by heart, you're not an assembly programmer :D
Offhand, yes, you are a less effective programmer if you rely on the IDE. I've seen many "programmers" that get completely lost if the IDE doesn't autocomplete everything for them.
That is a broad statement. Autocomplete is awesome when you're getting your hands into an existing codebase, and quickly need to be productive. It is also awesome when you have medium to big projects (between 500K lines, hundreds of classes/interfaces/whatever, and several million, thousands of classes/interfaces/whatever). I've seen many programmers completely lost at debugging *because* they were using a debugger - they wasted time identifying specific problems in their routines, while the whole approach was unsuitable - they would usually realize it after fixing the routine the first time, instead of looking at their code and trying to understand how could/would fail. Not all languages are equally suited for it, but those that fit the pattern (usually OOP stuff), works well.
My personal reason to use an IDE is syntax highlighting, project management features, and multi file navigation (it is common to have between 40 and 100 files open). Autocomplete is awesome, but it is a cherry on top of the cake. I could probably work without a full-blown IDE, but it wouldn't be the same thing.
Depends on the language; The direct equivalent of goto in assembly is 'jmp'; if you add the plethora of if/switch conditions most languages support, you have a list of very specialized 'gotos' that will plague your compiled/interpreted code, regardless of the starting language ;)
Spell/grammar checking is an awful example. If you misspel a word, the novel will still be finished. A computer program will not - will fail (either silently or noisy) or won't compile at all. So code completion is akin to having shortcuts to predefined phrases and complex words, not spellchecking.
When I did some C# code, I'd actually use SharpDevelop (the UI designer has (had?) some horrible bugs) because I wasn't able to adjust to the VS workflow.
Well, an autobiography is about the messenger, not necessarily the message.
Also, Europe did not have similar regulations, they may have had tougher regulations but they were the wrong regulations. Australian banks had limits about how much they could lend vs how much they had in assets as well as rules on how much they had to keep in liquid assets (again relative to how much they could lend) which made the conditions that created the sub prime crisis in the US and Europe impossible to have in Australia.
This is pretty standard in EU. The crisis tightened the ratios, but they existed before, and AFAIK were quite different from the US. Keep in mind, Iceland (the actual EU country that is associated with unregulated banks, has roughly 300.000 habitants, and a PIB lower than many/most of the Fortune500 companies).
If you don't understand this, you have no idea how the banking regulations in Australia work.
Well, I don't, but you seem to not know how EU regulations work. And since I live in EU (lived in 2 countries, actually), and my current country is still interventioned by IMF, people are well aware of what is going on.
Well, it is if he uses any kind of modern system. There are very few "completely free" computer platforms out there, and even those may run some proprietary programmable logic. Even modern CPUs run internal microcode.
For me that's working for free for somebody and that's not fair.
So if a company makes available under BSD license a library that was internally developed, developers don't need to be paid? That is new.
GPL mandates that if they distribute the improved binaries they have to share the improved source code.
Well, tecnically, no. They need to make the improved source code available under request to whom they distribute the binaries to. Not everyone. And since nowadays the tendency to run software is, well, hosted or via remote desktop or similar technology, since you're not distributing binaries, you don't need to make the source available. So if you develop a GPL library I want to build the stack of my shiny new SAAS startup, there is nothing you can do about it. The startup is the end user, it can modify it as it seems fit - and as long as it doesn't distribute the binaries, no one can ask for the code. Welcome to 2014.
One of the most ambigious words out there is "freedom."
Not everything is politics and philosophy. Its not about freedom (at least not anymore) - and it was never about freedom as RMS describes it. Its about software. Modern computers require very complex electronics and assembly process, it is not possible anymore to build a "modern" system from scratch in your garage with a soldering iron and some ICs. Computers are obiquous and software makes them tick. Most of that software is not GPL. Talking about freedom in software does not make sense, because software is a recipe - it makes a specific set of machinery "tick". It is not about freedom; it is about openness. In my perspective, having a RMS-abiding compiler means shit in terms of "freedom" to me - at least while most of the electronic equipment I use is designed with closed-source ASICs and runs closed-source firmware (including microcode in modern CPUs).
But then, I work as a programmer. If I want to share a piece of code with the community, it is my choice which license to choose - not RMS. I have the freedom of choosing the license I find most appropriate - and most of the times will be BSD, not GPL. Because I value openness, not bittery politics.
I was at Novell at the time during which the protocol basis for the commercial Internet was being decided. Novell was attempting to swing a deal with AT&T to get them to deploy a commercial network topology based on SPX/IPX; at the same time, Microsoft was attempting to get AT&T and Sprint, and whoever else they could get on board, to deploy a commercial network based on NetBIOS/NetBEUI.
It has been some time since I worked with both IPX and NetBEUI, but AFAIK they are single-segment protocols based on broadcast. You cannot build (easily) a network of a thousand nodes with it. Most "useful" implementations of both in relatively large networks are done over TCP/IP.
Also, TCP/IP would guarantee at least some compatibility with competing systems, eg Microsoft and IBM (IBM was probably one of the earlier adopters of TCP/IP for business environments, and this had effect on the rest of the market).
. Any contribution to a BSD codebase needs to be evaluated carefully because it means that the code is immediately licensed to your competitors without restriction and they can embrace-extend-extinguish you right out of your market if you are not very careful.
So what you're saying is that GPL prevents this? How? Please explain how a developer submitting a patch or a feature to a BSD-licensed project automatically gives your competition the hability of taking over your business?
GPL is much safer, in that case competitors can only use the code if they in turn publish and license back their own modifications
No it isn't, you. GPL clearly states that you are REQUIRED to make source code available upon request for your CUSTOMERS if they received a binary - not for everyone. That explicitly excludes most of the software, startups you see popping around, because most of the products are SAAS. I can use GPL software to build the closest system I can think of, and as long as I don't send binaries to customers (eg. they interact with it via browser/RDP/VNC/carrier pidgeons) I don't need to provide ANY source code.
I would start looking for a new job, these idiots will probably run the company into the ground in short order.
I would suggest you don't make strong assumptions of things you don't understand. In most companies I worked (related to software dev), GPL libraries were generically forbidden.
now?