As for needing to explain why, you are wrong. I will recommend software based on the license. You cannot respond to me by asking: 'what are you talking about?'
It's not that GPL is the victim of incompatibilities. GPL had a hand in causing these. The philosophy of the BSD/MIT licenses is to give freely. The philosophy of GPL/CDDL is take freely, and give to your friends. Generosity vs. selfishness.
I haven't taken the time to read the GPL, but I generally know what it is about. I have read the MIT and BSD licenses. In the same way, I don't care what the ingredients for some processed food product are or why they are there: there are too many.
Native support for ZFS is a good reason to choose FreeBSD over Linux. You can make even your root partition ZFS. The reason ZFS is not in the Linux kernel is due to licensing, though.
I hate the GPL... so much. I don't mind recommending people use FreeNAS because of the licensing. From now on, I'll tell people to use FreeBSD (or OpenBSD if they are awesome).
Also, I have something of a Javascript benchmark, my email obfuscater. Seamonkey 1 required me to click continue on the 'slow javascript' popup something like three times. Seamonkey 2: zero times.
The Javascript is much faster over the 1.x series. For instance, loading slashdot.org no longer brings up the dialog 'the javascript on this page is too convoluted and is taking too long. we're going to make you click okay just for the hell of it'.
Hopefully it doesn't crash as much as Seamonkey 1.x. I never figured out what was causing the crashes, possibly the gcc version I was using or maybe Flash. In any case, I will gladly make Seamonkey my backup browser to Chrome (goodbye, Firefox, I won't miss you).
Boost... is the basis for the threading capabilities in the forthcoming revision of the C++ standard.
It's probably the other way around, see the Boost thread documentation. In any case, it's much easier than using pthreads' C API, and I think the feature set is approximately the same as pthreads.
For this reason, computers are equipped with a layer of software called the operating system, whose job is to manage all these devices and provide user programs with a simpler interface to the hardware.
Most computer users have had some experience with an operating system, but it is difficult to pin down precisely what an operating system is. Part of the problem is that the operating systems perform two basically unrelated functions, extending the machine and managing resources...
-Chapter one, Modern Operating Systems 2nd ed, Andrew Tanenbaum
What's so convoluted about it? It manages resources (memory, devices, CPU) and provides protection (resource sharing, virtual memory). That's what an OS is. Take even an introductory course in operating systems and they'll tell you that. With macrokernels like Linux or BSD, the OS is the kernel. It extends out to libc to a very small degree, because libc provides the system call interface. printf() at some point may invoke the read() system call, but it is not a part of the OS. With an exokernel like Aegis (being the first of its kind), the OS is Aegis + ExOS (the library operating system).
You're thinking of what's more properly termed a distribution, and you can make the case that GNU should be a part of the distribution name. I would never make that case, but that's beside my point: macrokernel==OS.
Yeah, I remember GNU Hurd. Jokes aside, much of what GNU provides is extra (like bison), not to say it isn't helpful. GNU's also harmful to Unix portability: look at the GNU man page for rm and tell me what recursive option will also work in OpenBSD. It's also less free than a BSD alternative (as in freedom to do whatever you want with it, i.e. freedom).
For macrokernels, the OS is the kernel. At most, you can say that the functions in libc like wait() or stat() are part of the OS, but that's it (and it isn't saying much, those functions are a thin interface to the real system calls). For systems with exokernels, the OS is the union of the kernel and the library OS. I don't know much about microkernels, but the kernel is only a part of the OS. An OS' job is to manage resources and provide protection to processes. GNU doesn't do this.
I went to a school that had the most (or 2nd most) days in the school year in the entire state of MN. There were plenty of idiots there.
Also, where's the money going to come from? Teachers already aren't paid enough (so they say). They'll surely demand more. It looks like another one of Obama's hair-brained schemes that will only serve to dig us further into this money hole.
That is a good point, but you can only do a small fraction of the damage. Rather than your spam overtaking thousands, it may only take over a handful. I cannot refute your second point. What it is, though, is the process is creating a security hole by bypassing the precautions provided by the OS. My main point is only that security-through-obscurity (in other words: a lie) is different from just being insecure.
Tagging doesn't work for me anymore, so I picked the post with the most use of the word 'obscurity'.
This is not security through obscurity (STO). STO can always be exploited when you know how the algorithm works. Address space randomization cannot be exploited (immediately). You still have to start the executable maybe hundreds of times before the exploit works. This is easy if it's some short piece of code you've crafted yourself, but with real applications, it's not so simple.
Imagine a hack where you send some exploit to somebody over IM. If it doesn't work, the IM client *will* crash as it tried to execute some random portion of memory. How are you going to try your exploit at a different address now?
I don't really know what's going on, and the people at SANS don't seem to know, either. My best guess is that the code they showed was somewhere in the kernel (?) and address NULL is okay to use there (?).
The segmentation fault you're seeing is not because you dereferenced NULL, but because NULL wasn't in any of the pages. If NULL were in any of the pages, and sk were at offset 8, then tun->sk would resolve to (NULL + 8). The kernel has a different view of memory than user space; I'm just not sure what that is.
I don't think it could possibly crash more than Seamonkey (I hated Phoenix, and I carry a grudge) does for me. It seems none of the devs ever thought to see if their code works with gcc-4.0. Or if they did, they threw their hands up in the air and gave up. It used to be a rarity with Seamonkey, but lately, the browser just freezes up after I look at 'so much' stuff.
Good for you. I also hate nVidia's Linux drivers. So much so, I will never get nVidia again. I am the unlucky owner of the GeForce Go 6200, which nVidia completely neglects. In Linux, it's impossible to suspend/switch-to-console/kill X/unload the module. In Windows, there is no Vista driver at all, and the only XP drivers that work are old and unstable.
At this point, I would gladly take a slower Intel chip over nVidia.
Slashdot Mirror
As for needing to explain why, you are wrong. I will recommend software based on the license. You cannot respond to me by asking: 'what are you talking about?'
It's not that GPL is the victim of incompatibilities. GPL had a hand in causing these. The philosophy of the BSD/MIT licenses is to give freely. The philosophy of GPL/CDDL is take freely, and give to your friends. Generosity vs. selfishness.
I haven't taken the time to read the GPL, but I generally know what it is about. I have read the MIT and BSD licenses. In the same way, I don't care what the ingredients for some processed food product are or why they are there: there are too many.
??? I do not promote GPL. I promote BSD. There is no reason for me to have to now defend my claim that I dislike the GPL.
I could probably find out, but I'll just take a guess: that FAT filesystems appear in the Linux kernel because they were reverse-engineered.
Native support for ZFS is a good reason to choose FreeBSD over Linux. You can make even your root partition ZFS. The reason ZFS is not in the Linux kernel is due to licensing, though.
I hate the GPL ... so much. I don't mind recommending people use FreeNAS because of the licensing. From now on, I'll tell people to use FreeBSD (or OpenBSD if they are awesome).
Don't ask why I'm looking at such an old story. I love OpenBSD!
They want you to buy the discs, I think.
Also, I have something of a Javascript benchmark, my email obfuscater. Seamonkey 1 required me to click continue on the 'slow javascript' popup something like three times. Seamonkey 2: zero times.
The Javascript is much faster over the 1.x series. For instance, loading slashdot.org no longer brings up the dialog 'the javascript on this page is too convoluted and is taking too long. we're going to make you click okay just for the hell of it'.
Hopefully it doesn't crash as much as Seamonkey 1.x. I never figured out what was causing the crashes, possibly the gcc version I was using or maybe Flash. In any case, I will gladly make Seamonkey my backup browser to Chrome (goodbye, Firefox, I won't miss you).
Boost ... is the basis for the threading capabilities in the forthcoming revision of the C++ standard.
It's probably the other way around, see the Boost thread documentation. In any case, it's much easier than using pthreads' C API, and I think the feature set is approximately the same as pthreads.
I will remember that for next time :). A microkernel might be kind of cool, but I will never use a GPL3 OS.
For this reason, computers are equipped with a layer of software called the operating system, whose job is to manage all these devices and provide user programs with a simpler interface to the hardware.
Most computer users have had some experience with an operating system, but it is difficult to pin down precisely what an operating system is. Part of the problem is that the operating systems perform two basically unrelated functions, extending the machine and managing resources...
-Chapter one, Modern Operating Systems 2nd ed, Andrew Tanenbaum
Well, me and Andrew Tanenbaum anyway.
What's so convoluted about it? It manages resources (memory, devices, CPU) and provides protection (resource sharing, virtual memory). That's what an OS is. Take even an introductory course in operating systems and they'll tell you that. With macrokernels like Linux or BSD, the OS is the kernel. It extends out to libc to a very small degree, because libc provides the system call interface. printf() at some point may invoke the read() system call, but it is not a part of the OS. With an exokernel like Aegis (being the first of its kind), the OS is Aegis + ExOS (the library operating system).
You're thinking of what's more properly termed a distribution, and you can make the case that GNU should be a part of the distribution name. I would never make that case, but that's beside my point: macrokernel==OS.
Yeah, I remember GNU Hurd. Jokes aside, much of what GNU provides is extra (like bison), not to say it isn't helpful. GNU's also harmful to Unix portability: look at the GNU man page for rm and tell me what recursive option will also work in OpenBSD. It's also less free than a BSD alternative (as in freedom to do whatever you want with it, i.e. freedom).
For macrokernels, the OS is the kernel. At most, you can say that the functions in libc like wait() or stat() are part of the OS, but that's it (and it isn't saying much, those functions are a thin interface to the real system calls). For systems with exokernels, the OS is the union of the kernel and the library OS. I don't know much about microkernels, but the kernel is only a part of the OS. An OS' job is to manage resources and provide protection to processes. GNU doesn't do this.
You son of a bitch. I use vi, KDE, Gentoo, and K&R.
I went to a school that had the most (or 2nd most) days in the school year in the entire state of MN. There were plenty of idiots there.
Also, where's the money going to come from? Teachers already aren't paid enough (so they say). They'll surely demand more. It looks like another one of Obama's hair-brained schemes that will only serve to dig us further into this money hole.
That is a good point, but you can only do a small fraction of the damage. Rather than your spam overtaking thousands, it may only take over a handful. I cannot refute your second point. What it is, though, is the process is creating a security hole by bypassing the precautions provided by the OS. My main point is only that security-through-obscurity (in other words: a lie) is different from just being insecure.
Tagging doesn't work for me anymore, so I picked the post with the most use of the word 'obscurity'.
This is not security through obscurity (STO). STO can always be exploited when you know how the algorithm works. Address space randomization cannot be exploited (immediately). You still have to start the executable maybe hundreds of times before the exploit works. This is easy if it's some short piece of code you've crafted yourself, but with real applications, it's not so simple.
Imagine a hack where you send some exploit to somebody over IM. If it doesn't work, the IM client *will* crash as it tried to execute some random portion of memory. How are you going to try your exploit at a different address now?
whoops: *(NULL + 8)
I don't really know what's going on, and the people at SANS don't seem to know, either. My best guess is that the code they showed was somewhere in the kernel (?) and address NULL is okay to use there (?).
The segmentation fault you're seeing is not because you dereferenced NULL, but because NULL wasn't in any of the pages. If NULL were in any of the pages, and sk were at offset 8, then tun->sk would resolve to (NULL + 8). The kernel has a different view of memory than user space; I'm just not sure what that is.
He got off easy. Just think of how much money he would owe if he had been downloading music. And I'm sure he got paid well with his spam business.
I don't think it could possibly crash more than Seamonkey (I hated Phoenix, and I carry a grudge) does for me. It seems none of the devs ever thought to see if their code works with gcc-4.0. Or if they did, they threw their hands up in the air and gave up. It used to be a rarity with Seamonkey, but lately, the browser just freezes up after I look at 'so much' stuff.
If the MD5 is different, you shouldn't use it.
Good for you. I also hate nVidia's Linux drivers. So much so, I will never get nVidia again. I am the unlucky owner of the GeForce Go 6200, which nVidia completely neglects. In Linux, it's impossible to suspend/switch-to-console/kill X/unload the module. In Windows, there is no Vista driver at all, and the only XP drivers that work are old and unstable.
At this point, I would gladly take a slower Intel chip over nVidia.
Well, communists actually call it GNU/Linux.
Exactly what I thought. I've seen a bunch of them too, since my Mazda dealer doubled as a Maserati dealer.