That completely breaks the OSS model, though. That is: Sometimes, I see a project I like, but it needs a little work. If it's a tiny patch, I'll just do it all locally and send it in. But if my patch is rejected, or it's likely to be a bigger contribution, I'll create a public fork -- easy to do with something like Github -- and publish my changes there.
This also has the nice side effect of simplifying the problem of finding a new maintainer, for a smaller project -- you've already got at least one fork, probably several that might even be sharing patches, so if the original developer goes AWOL, the project is still alive.
All of these work whether I'm doing purely open source stuff, or whether I'm working on a proprietary project and contributing back.
If it's MIT, BSD, GPL, etc, all of this is possible. If I've had to license it commercially, then I can no longer share my changes -- we're now back to the bottleneck of the original creator, in this case, of exactly one person. And adding money to the equation makes it even less likely that these changes will make it back in.
In fact, I'll give an example: extjs was under a more permissive license. It switched to GPL, and tried to claim that the GPL applied to the server, and not just to the JavaScript client. Although we had paid for a commercial license before the GPL switch, we dropped that thing in a matter of weeks -- we just didn't need the uncertainty of a framework tightly under the control of an asshole. Instead, we use jQuery, which is dual-licensed under MIT and GPL, isn't going anywhere, and ended up being closer to what we needed anyway.
And while I don't know of any patches we've sent back to core, we did publish one or two extjs plugins, and there was a fair chance of publishing jQuery stuff.
They have, at the 4.0 launch, declared it was a developper release.
The rest of the world has a word for "developer release", and that word is "Alpha". Releasing it as a.0 release, and even using the word "stable", was misleading at best.
At the same time, the reason they gave for releasing it as.0, rather than as an Alpha or a Beta, is that they wanted users. Not enough people are willing to play with a Beta, apparently. So they were deliberately trying to con users into helping them bugtest a release -- a very Microsoft-like move.
Because sometimes, you have to. Better always ship then don't.
In the commercial world, that almost makes sense.
In open source, it really doesn't. Those who want bleeding edge will upgrade. Those who don't, shouldn't have to.
Kind of good news about DNF, though, if that's actually happening. I'm still a bit skeptical -- but then, it has happened before, with Prey.
Re:Sometimes you don't have physical access
on
R.I.P. FTP
·
· Score: 1
But in a lot of cases where SSH would appear useful, you don't have convenient physical access to the machine. Say you're renting a virtual dedicated server from Go Daddy
That's true, and a good point. Although so is your footnote:
Replace with another hosting provider.
Yes, you should.
So, a decent hosting provider would give you that information, or at least some sort of AJAX console, over HTTPS. That means you now only have to worry about guys like VeriSign (or your OS provider) screwing you over.
I suppose it depends how you count. They released a 4.0 that wasn't ready. They knew precisely what message they were sending, and are to this day trying to talk their way out of it.
Allthough it's not the DNF that we were 'promised' with insane interactivity, it is going to be released I think.
That's totally Kubuntu and not KDE4. They are a little 'understaffed' so can't really blame them
The bluetooth thing was a known bug, and they released it anyway. I do blame them for that. Why the hell didn't they delay the release?
Re:Authentication goes both ways.
on
R.I.P. FTP
·
· Score: 1
But how can you be sure that your first connection was without a MITM?
Usually, because I'm actually physically right next to the machine. If I can't touch my switch, who can I trust?
In general, I'm working with probability. The fact that I've never had the "somebody nasty" message unexpectedly (that is, when I didn't just reformat or replace a machine), even when I move the same laptop from home, to work, to the airport, and back home, means it would take a truly massive network of people intercepting my packets at every turn, or I'd have at least detected it at some point.
Agreed KDE4 isn't as good as KDE 3.5.x yet. Every release there's more stuff that gets added. On the Long run it will beat everything out there though...
In other words, it's a bit like Windows Eight. I hear it'll be awesome.
I mean, at least it's not like Duke Nukem Forever, yet, but even so... I'm not talking about the little things, like being able to customize keystrokes for browsing around in Okular.
No, I'm talking about stuff like, in one release, my mouse stopped working, and in another, my Internet stopped working.
That's unacceptable.
Re:Breaking out of chroot for a non root user
on
R.I.P. FTP
·
· Score: 1
Of course, if you're smashing the stack, I'm going to trust the kernel over the FTP server any day.
So does using capslock, and being condescending towards someone for using a curse word.
But I don't suppose I should be wasting time with someone who would so easily dismiss an entire human being over one word. Even one "outburst", if you like.
Thanks. You really changed my life. I have a whole new outlook on things.
Really? Anger management?
No, it does make me angry that you are telling people that more secure software does not matter. You are making the problem worse. Hopefully that "fuck you" got your attention.
But if you really want to make it about anger management... I didn't use capslock. I didn't even use bold or italic. You're the one who opened with "ALL THAT CRAP MEANS NOTHING!"
All versions of Ubuntu have all Ubuntu packages available for install. Kubuntu Jaunty comes with a KDE4 Widget for controlling NetworkManager.
Problem is, that widget doesn't work.
So, I installed the GNOME NetworkManager applet, as a workaround. It was one of several suggested workarounds -- another being to install wicd.
So yes, it still fails, just not as much as you suggest. It's the same thing I did when Kubuntu Intrepid just fucking dropped Bluetooth support, rather than delay the release -- this was a known bug at the time -- so for quite awhile, the only real solution was to use the GNOME bluetooth applet, or go without a mouse.
I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer.... So, I assumed it made no difference whether I used FTP or SFTP.
But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted
Same goes for keyloggers, by the way. You can look at everything I type and hope you get a password, or you can just intercept FTP, where you know exactly where the password is being sent.
Not that we shouldn't protect against keyloggers, but why would you make it easy?
FTP vulnerable? No more then your home phone line or cell phone.
Not true -- while eavesdropping is probably easier with a phone conversation, man-in-the-middle attacks are much harder. If you said something, I know it was you who said it, because it sounds like you -- whereas with FTP, the server doesn't know if I uploaded the file, or someone in the middle uploaded the file, or someone who stole my password uploaded the file.
You can get a silent VNC session going.... Hell just track the next time they go to amazon.com or any onther online site. Who gives a rats ass about SSL when you are seeing them type in their info?!
Because you have to 0wn me first.
If you don't bother with SSL, then there's no way the user could be careful enough or savvy enough -- the next time they order something from a wireless hotspot, someone else's laptop will automatically pick out their credit card number.
If you do, they suddenly have to not only compromise your machine, but actively watch for you to hit amazon.com, or write a much more complex program that hooks into IE (but what if you're not using IE?) and watch for amazon.com, or search through pages and pages of keylogs.
The problem is and always will be PEOPLE. One they have control of the physical machine all bets are off for ANY security measure.
Both very true. But until the person or the physical machine is compromised, all of these other things mean a good deal more than "nothing".
It sounds very much like you're suggesting that we ignore security and encryption, because it's all futile anyway -- you certainly haven't offered a better approach. Well, you know what? Fuck you and your defeatist attitude. The rest of us will be working to actually make things better.
Re:Authentication goes both ways.
on
R.I.P. FTP
·
· Score: 1
I like that this is an option.
Of course, I'll be honest -- I still often say "screw it" and just connect, rather than trying to transfer the key ahead of time, verify the fingerprint, etc. But then, I only connect from my laptop, and I intuitively know which machines I've already connected to, and which will give me the security prompt. So, generally, once I've connected once without a MITM, every connection from then on is secure.
Until FTP can let me use a keypair instead of a password, I'll stick with OpenSSH public key authentication.
Never mind that ssh only requires a single port to be open...
Of course, it depends on your goals, but there's also the fact that I wouldn't pay for a server that I didn't already have some sort of shell access to. Since I already have ssh access (I'm assuming we're not even considering telnet), I already have scp and probably sftp.
First: It's not just "shitty software". It can be very useful for things like installation. I always like the Gentoo Linux approach -- format the disk yourself, mount it, untar one tarball, and chroot for the rest of the installation.
Second, every single security "problem" with chroot is based on the root user breaking out. Non-root users cannot break out of a chroot'ed environment. It therefore does add some additional security.
And finally:
If you're just depending on the authors of your ftp daemon to protect you then your an idiot.
If you don't see the difference between explicitly allowing any user to run any command on your system via ssh, and the possibility that a bug in your FTP software might lead to the same problem, you're an idiot.
How is this relevant? Kubuntu Hardy worked. I would assume that Kubuntu Jaunty would have a newer kernel version.
But just for fun, when I run nm-applet -- that's right, the GNOME applet -- it works. It's only when I run the KDE4 NetworkManager Widget that it doesn't.
And, it's only with the wireless network I have set up at home, which I've given a random hex key. WPA networks with passphrases work, just hex keys don't. And WEP networks certainly work fine. Of course, the way in which they work is fairly unintuitive -- in order to choose a network other than the default one, I have to go configure them, change priorities, etc, because just clicking on a wireless network will assume I'm setting up a new one every time.
Krunner and Plasma crash? I've been running KDE4 since 4.0 and have only encountered crashes whith 4.0-4.1
Good for you. I can fairly reliably make either krunner or plasma crash by toggling compositing a few times. Depending on how I do it, I can also make compositing go so slowly that just dragging a window around can freeze the window manager for 30 seconds at a time. This is KDE 4.2.
The KDE people tell me this is all Kubuntu's fault, and I could believe that. Certainly, there's blame to share. I just wanted to question the claim that Kubuntu, specifically, is any better than Win7.
Licensing Gecko -- is it out of the question for them to just go open source? And certainly Webkit proves you're wrong, by its very existence -- Apple adopted KHTML and started developing for it. As long as Apple continues shipping Safari, I don't see development stopping, but even in some imaginary world where Apple stopped caring, Microsoft could simply adopt the code themselves.
There is no technical or real business reason not to do it that way.
The real reason is that they'd have to admit what a colossal failure IE was, and that they'd have that much less possibility for lock-in.
Any application with more than 1 thread, can use more than one processor unless specifically told otherwise.
Any well-designed application.
Any application using threads necessarily has some sort of synchronization. Without thinking carefully about that, you could easily lock yourself to one or two cores. Even with careful planning, most applications don't make it easy to fully utilize all cores.
A non-blocking call implies multi-threaded design, genius.
It really doesn't. Maybe a similar design to a multithreaded app, but more accurately an event model, not a thread model. It's cooperative multitasking, which means it won't hit multiple processors, and generally won't have anywhere near the same kind of concurrency issues.
I suppose you could make the argument that the OS is doing the threading for you, or that it's a kind of green threads, but at that point, it's both a semantic argument, and it's losing any semblance of meaning of "threaded".
Slashdot Mirror
That completely breaks the OSS model, though. That is: Sometimes, I see a project I like, but it needs a little work. If it's a tiny patch, I'll just do it all locally and send it in. But if my patch is rejected, or it's likely to be a bigger contribution, I'll create a public fork -- easy to do with something like Github -- and publish my changes there.
This also has the nice side effect of simplifying the problem of finding a new maintainer, for a smaller project -- you've already got at least one fork, probably several that might even be sharing patches, so if the original developer goes AWOL, the project is still alive.
All of these work whether I'm doing purely open source stuff, or whether I'm working on a proprietary project and contributing back.
If it's MIT, BSD, GPL, etc, all of this is possible. If I've had to license it commercially, then I can no longer share my changes -- we're now back to the bottleneck of the original creator, in this case, of exactly one person. And adding money to the equation makes it even less likely that these changes will make it back in.
In fact, I'll give an example: extjs was under a more permissive license. It switched to GPL, and tried to claim that the GPL applied to the server, and not just to the JavaScript client. Although we had paid for a commercial license before the GPL switch, we dropped that thing in a matter of weeks -- we just didn't need the uncertainty of a framework tightly under the control of an asshole. Instead, we use jQuery, which is dual-licensed under MIT and GPL, isn't going anywhere, and ended up being closer to what we needed anyway.
And while I don't know of any patches we've sent back to core, we did publish one or two extjs plugins, and there was a fair chance of publishing jQuery stuff.
On the other hand, that also makes it harder for indie artists...
They have, at the 4.0 launch, declared it was a developper release.
The rest of the world has a word for "developer release", and that word is "Alpha". Releasing it as a .0 release, and even using the word "stable", was misleading at best.
At the same time, the reason they gave for releasing it as .0, rather than as an Alpha or a Beta, is that they wanted users. Not enough people are willing to play with a Beta, apparently. So they were deliberately trying to con users into helping them bugtest a release -- a very Microsoft-like move.
Because sometimes, you have to. Better always ship then don't.
In the commercial world, that almost makes sense.
In open source, it really doesn't. Those who want bleeding edge will upgrade. Those who don't, shouldn't have to.
Kind of good news about DNF, though, if that's actually happening. I'm still a bit skeptical -- but then, it has happened before, with Prey.
But in a lot of cases where SSH would appear useful, you don't have convenient physical access to the machine. Say you're renting a virtual dedicated server from Go Daddy
That's true, and a good point. Although so is your footnote:
Replace with another hosting provider.
Yes, you should.
So, a decent hosting provider would give you that information, or at least some sort of AJAX console, over HTTPS. That means you now only have to worry about guys like VeriSign (or your OS provider) screwing you over.
KDE actually delivers what it promises
I suppose it depends how you count. They released a 4.0 that wasn't ready. They knew precisely what message they were sending, and are to this day trying to talk their way out of it.
Allthough it's not the DNF that we were 'promised' with insane interactivity, it is going to be released I think.
Are you in denial? They fired the DNF team.
That's totally Kubuntu and not KDE4. They are a little 'understaffed' so can't really blame them
The bluetooth thing was a known bug, and they released it anyway. I do blame them for that. Why the hell didn't they delay the release?
But how can you be sure that your first connection was without a MITM?
Usually, because I'm actually physically right next to the machine. If I can't touch my switch, who can I trust?
In general, I'm working with probability. The fact that I've never had the "somebody nasty" message unexpectedly (that is, when I didn't just reformat or replace a machine), even when I move the same laptop from home, to work, to the airport, and back home, means it would take a truly massive network of people intercepting my packets at every turn, or I'd have at least detected it at some point.
Not anymore, though I do still have it.
Agreed KDE4 isn't as good as KDE 3.5.x yet. Every release there's more stuff that gets added. On the Long run it will beat everything out there though...
In other words, it's a bit like Windows Eight. I hear it'll be awesome.
I mean, at least it's not like Duke Nukem Forever, yet, but even so... I'm not talking about the little things, like being able to customize keystrokes for browsing around in Okular.
No, I'm talking about stuff like, in one release, my mouse stopped working, and in another, my Internet stopped working.
That's unacceptable.
Of course, if you're smashing the stack, I'm going to trust the kernel over the FTP server any day.
So does using capslock, and being condescending towards someone for using a curse word.
But I don't suppose I should be wasting time with someone who would so easily dismiss an entire human being over one word. Even one "outburst", if you like.
Thanks. You really changed my life. I have a whole new outlook on things.
Really? Anger management?
No, it does make me angry that you are telling people that more secure software does not matter. You are making the problem worse. Hopefully that "fuck you" got your attention.
But if you really want to make it about anger management... I didn't use capslock. I didn't even use bold or italic. You're the one who opened with "ALL THAT CRAP MEANS NOTHING!"
No, that isn't what I said.
All versions of Ubuntu have all Ubuntu packages available for install. Kubuntu Jaunty comes with a KDE4 Widget for controlling NetworkManager.
Problem is, that widget doesn't work.
So, I installed the GNOME NetworkManager applet, as a workaround. It was one of several suggested workarounds -- another being to install wicd.
So yes, it still fails, just not as much as you suggest. It's the same thing I did when Kubuntu Intrepid just fucking dropped Bluetooth support, rather than delay the release -- this was a known bug at the time -- so for quite awhile, the only real solution was to use the GNOME bluetooth applet, or go without a mouse.
From TFA:
I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer.... So, I assumed it made no difference whether I used FTP or SFTP.
But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted
Same goes for keyloggers, by the way. You can look at everything I type and hope you get a password, or you can just intercept FTP, where you know exactly where the password is being sent.
Not that we shouldn't protect against keyloggers, but why would you make it easy?
FTP vulnerable? No more then your home phone line or cell phone.
Not true -- while eavesdropping is probably easier with a phone conversation, man-in-the-middle attacks are much harder. If you said something, I know it was you who said it, because it sounds like you -- whereas with FTP, the server doesn't know if I uploaded the file, or someone in the middle uploaded the file, or someone who stole my password uploaded the file.
You can get a silent VNC session going.... Hell just track the next time they go to amazon.com or any onther online site. Who gives a rats ass about SSL when you are seeing them type in their info?!
Because you have to 0wn me first.
If you don't bother with SSL, then there's no way the user could be careful enough or savvy enough -- the next time they order something from a wireless hotspot, someone else's laptop will automatically pick out their credit card number.
If you do, they suddenly have to not only compromise your machine, but actively watch for you to hit amazon.com, or write a much more complex program that hooks into IE (but what if you're not using IE?) and watch for amazon.com, or search through pages and pages of keylogs.
The problem is and always will be PEOPLE. One they have control of the physical machine all bets are off for ANY security measure.
Both very true. But until the person or the physical machine is compromised, all of these other things mean a good deal more than "nothing".
It sounds very much like you're suggesting that we ignore security and encryption, because it's all futile anyway -- you certainly haven't offered a better approach. Well, you know what? Fuck you and your defeatist attitude. The rest of us will be working to actually make things better.
I like that this is an option.
Of course, I'll be honest -- I still often say "screw it" and just connect, rather than trying to transfer the key ahead of time, verify the fingerprint, etc. But then, I only connect from my laptop, and I intuitively know which machines I've already connected to, and which will give me the security prompt. So, generally, once I've connected once without a MITM, every connection from then on is secure.
Until FTP can let me use a keypair instead of a password, I'll stick with OpenSSH public key authentication.
Never mind that ssh only requires a single port to be open...
Of course, it depends on your goals, but there's also the fact that I wouldn't pay for a server that I didn't already have some sort of shell access to. Since I already have ssh access (I'm assuming we're not even considering telnet), I already have scp and probably sftp.
First: It's not just "shitty software". It can be very useful for things like installation. I always like the Gentoo Linux approach -- format the disk yourself, mount it, untar one tarball, and chroot for the rest of the installation.
Second, every single security "problem" with chroot is based on the root user breaking out. Non-root users cannot break out of a chroot'ed environment. It therefore does add some additional security.
And finally:
If you're just depending on the authors of your ftp daemon to protect you then your an idiot.
If you don't see the difference between explicitly allowing any user to run any command on your system via ssh, and the possibility that a bug in your FTP software might lead to the same problem, you're an idiot.
Have tried a distro with a newer kernel version?
How is this relevant? Kubuntu Hardy worked. I would assume that Kubuntu Jaunty would have a newer kernel version.
But just for fun, when I run nm-applet -- that's right, the GNOME applet -- it works. It's only when I run the KDE4 NetworkManager Widget that it doesn't.
And, it's only with the wireless network I have set up at home, which I've given a random hex key. WPA networks with passphrases work, just hex keys don't. And WEP networks certainly work fine. Of course, the way in which they work is fairly unintuitive -- in order to choose a network other than the default one, I have to go configure them, change priorities, etc, because just clicking on a wireless network will assume I'm setting up a new one every time.
Krunner and Plasma crash? I've been running KDE4 since 4.0 and have only encountered crashes whith 4.0-4.1
Good for you. I can fairly reliably make either krunner or plasma crash by toggling compositing a few times. Depending on how I do it, I can also make compositing go so slowly that just dragging a window around can freeze the window manager for 30 seconds at a time. This is KDE 4.2.
The KDE people tell me this is all Kubuntu's fault, and I could believe that. Certainly, there's blame to share. I just wanted to question the claim that Kubuntu, specifically, is any better than Win7.
Ubuntu is unabashedly and unequivocally built around gnome.
Kubuntu is a separate enough project that it should work -- and did work very well, with KDE 3.5.
complaining about kubuntu not performing properly
I was replying directly to someone who was using Kubuntu as an example of what's so great about Win7.
you should get a linux distro built around KDE.
Know of any good Debian-based ones? It's been a long time since I tried, but I remember intensely disliking RPM.
Oh, you mean, random shit that used to work, doesn't anymore?
Why can't I connect to my wireless network at home?
Why does krunner randomly crash? Or Plasma?
On second thought, maybe you're right. It's things like this that are the reason I left Windows in the first place. Maybe it's time to go back.
Boot to ramdisk... Depending on how big your image is and how much ram you've got.
In what way is that better than booting to ramfs? Then, if you have a local disk, map it as swap. Done.
I'd assume they're still working on Vista.
I don't see how either of these are true.
Licensing Gecko -- is it out of the question for them to just go open source? And certainly Webkit proves you're wrong, by its very existence -- Apple adopted KHTML and started developing for it. As long as Apple continues shipping Safari, I don't see development stopping, but even in some imaginary world where Apple stopped caring, Microsoft could simply adopt the code themselves.
There is no technical or real business reason not to do it that way.
The real reason is that they'd have to admit what a colossal failure IE was, and that they'd have that much less possibility for lock-in.
Let's see...
On Linux, it's in the package manager. And it's likely to be far, far less than 200 megs worth of dependencies.
On Windows, Java is maybe, what, 30 megs? 50 megs?
And while .NET is huge, "worth your time"? It's right there in Microsoft Update, and it ships with Vista. You are getting your updates, right?
Even if your statement was true, if it was a good note taking program... I'm on fiber. 200 megs is nothing.
We also know that it's by MAC, which is a step forward from services which try to "opt-out" via cookie.
But I agree with grcumb -- not even close to enough. This kind of bullshit needs to be opt-in, if it's done at all.
Any application with more than 1 thread, can use more than one processor unless specifically told otherwise.
Any well-designed application.
Any application using threads necessarily has some sort of synchronization. Without thinking carefully about that, you could easily lock yourself to one or two cores. Even with careful planning, most applications don't make it easy to fully utilize all cores.
A non-blocking call implies multi-threaded design, genius.
It really doesn't. Maybe a similar design to a multithreaded app, but more accurately an event model, not a thread model. It's cooperative multitasking, which means it won't hit multiple processors, and generally won't have anywhere near the same kind of concurrency issues.
I suppose you could make the argument that the OS is doing the threading for you, or that it's a kind of green threads, but at that point, it's both a semantic argument, and it's losing any semblance of meaning of "threaded".