Even if they stop offering it, people still got binaries that are GPL'd. They still have a right to get the source; the license doesn't stop taking effect when the company stops distributing the binaries, the license is perpetual. Hence you can't remove the GPL from your work and sue people using the latest GPL'd version under the GPL.
The courts would likely simply grant an injunction if this ever went to court, but the point is that the GPL requires them to provide source, even if they stop distributing it.
That is patently false. You still have to distribute source if you distribute binaries, patched or not. Conveying binaries means you must also provide source (through one of several ways). Just saying "we use unmodified Linux 3.0.4" is not enough, either.
Ah, yes, I must not know what I'm talking about. Except that's not the case here. I've directly migrated quite a few moderate sized projects from VB6 to VB.NET. Bullshit on no tool converting properly. Granted, the code needs a decent amount of touch up after the fact, but it could be much worse. Moreover, just because you can convert X to Y doesn't make X the same as Y. I've worked with C# 1.2, 2.0, and 3.0. (Alright, you caught me. I've never worked with LINQ. My bad...) I've only slightly worked with VB.NET past aforementioned conversions. I sure as hell don't know everything about them, but I sure as hell know enough to know that C# and VB.NET are not more similar than VB6 and VB.NET. Just because something's running on the same underlying framework doesn't make them the same. I don't hear you arguing that C and C++ are the same, because they both (can) run on the same systems (pick your favorite).
So please, don't make straw man arguments and make a real argument besides "YOU HAVE NO EXPERIENCE LOL", and certainly not if you really have no idea how much experience someone has.
That's true, but sharing the same libraries doesn't mean too much. You could make the argument that Python and Perl can share libraries (so long as they're written in C, they could be exactly the same for both as well; interfaces could be written the same for both easily so that utilizing the library would be the same for both, although that's not always the case for C# and VB.NET). My point was more towards the syntax differences, not the libraries. Also, VB.NET has its own runtime library that runs on.NET as well (see http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.aspx), which is certainly not shared with C#.
Also, there's no way that VB.NET is closer to C# than VB6, except for automagically working with everything.NET. And even then, the syntax differences are too big to ignore. Look at all the code snippets on MSDN; they're wildly different between VB.NET and C# quite a few times. Look at the VB6 to VB.NET migrator, it's extremely trivial (only really converting everything to use.NET).
The brilliant part is that you don't even need a Trusting Trust attack for this. Since no one has access to anything except what the compiler spits out, you can't verify the compiler in any way. Granted, when you disassemble it (.NET makes it too easy), you should be able to notice the nasty things. Unless you compiled your disassembler with said compiler... But my point is that the compiler doesn't have to silently sabotage itself, because no one can get to it. It could, of course, silently sabotage other compilers and debugging tools.
That's like saying that Python and Perl are only superficially different. (Both can run on the Parrot VM, too.) They have wildly different syntaxes. The only thing they really have in common is the.NET stuff, which only means they interoperate easily and share the same pros/cons that are inherited from.NET. C# looks nothing like VB6, VB.NET (quite intentionally) looks damn near identical to VB6.
I agree 100%. I'm a huge distcc fanboi, but outsourcing compiling of code scares the shit out of me. I'd expect to see a security vulnerability where faulty code was somehow delivered to you. It's a backdoor that you run yourself, as you expect the compiler to return, you know, a compiled version of what you gave it. Nasty things in 3... 2... 1...
No no, you're thinking C#. Which is not in any way to be confused with C3. Which is not at all a typo that completely slipped through... Nothing to see here. Move along./s
VB6 is dead, but VB.NET is still alive and kicking (sadly) both as a transitional language from VB6 and as a language for new projects, but IIRC Microsoft suggested C# and avoiding VB.NET where possible.
Still could be some dumbass with sudo, either set to use the same (weak) password, or they were logging in directly as root (which I sure hope not, but see above about fixing stupid).
If you have weak passwords, no OS is going to help you. The only thing that helps you there is something like DenyHosts or fail2ban. Not even OpenBSD prevents stupid.
At least you don't need anybody to approve your app on Windows or WinPhone as far as i know.
WP7 still checks over apps that are submitted, but they're nowhere near as strict as Apple. It's basic "nothing that's illegal/carriers don't like etc.", AFAIK.
SIM cards never store video. Ever. No matter what network you're on. The most they store are text messages and/or contacts. But in all fairness, that doesn't change the fact that Sprint doesn't have SIM cards...
It's entirely possible that Comcast/Verizon block port 25 unless you specifically request otherwise, as they both have smart hosts to forward mail that comes from their network. I had to call Verizon and ask for them to unblock port 80 inbound on a business-class connection.
It's also possible to get business-class Internet without a static IP, in which case they shouldn't be trying to run their own mail server...
Slashdot Mirror
Even if they stop offering it, people still got binaries that are GPL'd. They still have a right to get the source; the license doesn't stop taking effect when the company stops distributing the binaries, the license is perpetual. Hence you can't remove the GPL from your work and sue people using the latest GPL'd version under the GPL. The courts would likely simply grant an injunction if this ever went to court, but the point is that the GPL requires them to provide source, even if they stop distributing it.
That is patently false. You still have to distribute source if you distribute binaries, patched or not. Conveying binaries means you must also provide source (through one of several ways). Just saying "we use unmodified Linux 3.0.4" is not enough, either.
Ah, yes, I must not know what I'm talking about. Except that's not the case here. I've directly migrated quite a few moderate sized projects from VB6 to VB.NET. Bullshit on no tool converting properly. Granted, the code needs a decent amount of touch up after the fact, but it could be much worse. Moreover, just because you can convert X to Y doesn't make X the same as Y. I've worked with C# 1.2, 2.0, and 3.0. (Alright, you caught me. I've never worked with LINQ. My bad...) I've only slightly worked with VB.NET past aforementioned conversions. I sure as hell don't know everything about them, but I sure as hell know enough to know that C# and VB.NET are not more similar than VB6 and VB.NET. Just because something's running on the same underlying framework doesn't make them the same. I don't hear you arguing that C and C++ are the same, because they both (can) run on the same systems (pick your favorite).
So please, don't make straw man arguments and make a real argument besides "YOU HAVE NO EXPERIENCE LOL", and certainly not if you really have no idea how much experience someone has.
That's true, but sharing the same libraries doesn't mean too much. You could make the argument that Python and Perl can share libraries (so long as they're written in C, they could be exactly the same for both as well; interfaces could be written the same for both easily so that utilizing the library would be the same for both, although that's not always the case for C# and VB.NET). My point was more towards the syntax differences, not the libraries. Also, VB.NET has its own runtime library that runs on .NET as well (see http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.aspx), which is certainly not shared with C#.
.NET. And even then, the syntax differences are too big to ignore. Look at all the code snippets on MSDN; they're wildly different between VB.NET and C# quite a few times. Look at the VB6 to VB.NET migrator, it's extremely trivial (only really converting everything to use .NET).
Also, there's no way that VB.NET is closer to C# than VB6, except for automagically working with everything
The brilliant part is that you don't even need a Trusting Trust attack for this. Since no one has access to anything except what the compiler spits out, you can't verify the compiler in any way. Granted, when you disassemble it (.NET makes it too easy), you should be able to notice the nasty things. Unless you compiled your disassembler with said compiler... But my point is that the compiler doesn't have to silently sabotage itself, because no one can get to it. It could, of course, silently sabotage other compilers and debugging tools.
That's like saying that Python and Perl are only superficially different. (Both can run on the Parrot VM, too.) They have wildly different syntaxes. The only thing they really have in common is the .NET stuff, which only means they interoperate easily and share the same pros/cons that are inherited from .NET. C# looks nothing like VB6, VB.NET (quite intentionally) looks damn near identical to VB6.
I agree 100%. I'm a huge distcc fanboi, but outsourcing compiling of code scares the shit out of me. I'd expect to see a security vulnerability where faulty code was somehow delivered to you. It's a backdoor that you run yourself, as you expect the compiler to return, you know, a compiled version of what you gave it. Nasty things in 3... 2... 1...
No no, you're thinking C#. Which is not in any way to be confused with C3. Which is not at all a typo that completely slipped through... Nothing to see here. Move along. /s
VB6 is dead, but VB.NET is still alive and kicking (sadly) both as a transitional language from VB6 and as a language for new projects, but IIRC Microsoft suggested C# and avoiding VB.NET where possible.
Still could be some dumbass with sudo, either set to use the same (weak) password, or they were logging in directly as root (which I sure hope not, but see above about fixing stupid).
If you have weak passwords, no OS is going to help you. The only thing that helps you there is something like DenyHosts or fail2ban. Not even OpenBSD prevents stupid.
WP7 still checks over apps that are submitted, but they're nowhere near as strict as Apple. It's basic "nothing that's illegal/carriers don't like etc.", AFAIK.
They don't count what people see. From the review guidelines:
As in, what people see doesn't count as published by law enforcement agencies.
SIM cards never store video. Ever. No matter what network you're on. The most they store are text messages and/or contacts. But in all fairness, that doesn't change the fact that Sprint doesn't have SIM cards...
It's entirely possible that Comcast/Verizon block port 25 unless you specifically request otherwise, as they both have smart hosts to forward mail that comes from their network. I had to call Verizon and ask for them to unblock port 80 inbound on a business-class connection.
It's also possible to get business-class Internet without a static IP, in which case they shouldn't be trying to run their own mail server...
From TFS: "We have high-speed business connections through Verizon and Comcast." So I'd say business.